[FFmpeg-devel] [PATCH 2/2] ffmpeg: Set default output format for cuvid hwaccel

[wm4]

On Sun, 18 Jun 2017 16:27:30 -0700
Philip Langdale <philipl at overt.org> wrote:

> The cuvid hwaccel is weird because it's not a real hwaccel. This
> means that requesting the hwaccel by itself does nothing as the
> right decoder and encoder have to be request to take advantage of
> it.
> 
> On the other hand, requesting the cuvid decoder or nvenc encoder
> will always be hardware accelerated because that's inherently
> what they are.
> 
> The end result is that '-hwaccel cuvid' really ends up being an
> option that requests the use of a shared context that allows full
> hardware transcoding without copying frames back-and-forth to/from
> system memory.
> 
> This differs from 'real' hwaccels, which plug into the existing
> decoders (and encoders?). In this case, the default format is
> controlled by the decoder/encoder and not the presence of the hwaccel.
> So, for example, with vaapi, the hardware will decode the video but
> it will be automatically converted to a software format in system
> memory unless the output format is explicitly set to the native
> hardware one.
> 
> Switching cuvid to be a generic hwaccel brings this later behaviour
> to cuvid; specifying the hwaccel by itself without an output format
> does exactly nothing - the decoder and encoder continue to define
> their own contexts and frames pass through system memory.
> 
> More importantly, this changes the behaviour of command lines that
> used to do full transcoding - a new argument must be added to
> specify the output format.
> 
> To avoid breaking this compatibility, one possible solution is to
> allow an hwaccel to indicate that its default output format is its
> native hardware format, and that is what is implemented in this
> change.
> 
> We believe that the qsv hwaccel also has the same pre-generic
> behaviour and could also be a candidate for this.
> 
> Signed-off-by: Philip Langdale <philipl at overt.org>

I still think all hwaccels should show the same behavior. It's just a
confusing subtle difference, and might even think that there's
something "better" about cuda/qsv over dxva.

>      { "vdpau", hwaccel_decode_init, HWACCEL_VDPAU, AV_PIX_FMT_VDPAU,
> -      AV_HWDEVICE_TYPE_VDPAU },
> +      AV_HWDEVICE_TYPE_VDPAU, 0 },

Using designated initializers would probably be a good idea here.