[FFmpeg-devel] [PATCH] Add CUDA function cuDeviceGetAttribute

Philip Langdale philipl at overt.org
Fri Nov 2 05:38:48 EET 2018

On Thu, 1 Nov 2018 23:48:03 +0000
Soft Works <softworkz at hotmail.com> wrote:

> In this context, I wonder if there is some explanation somewhere
> about the differences between the cuvid and nvdec codec
> implementations.
> I understand the ffmpeg side where cuvid is a full codec and nvdec is 
> implemented as hwaccel. 

This is correct. It's the same decoder being used, but 'cuviddec' uses
the full nvidia parser, which then drives the decoder. As such, it's a
full codec. nvdec is an hwaccel that plugs into the ffmpeg decoders.
> What adds to the confusion is that the hwaccel is called 'cuda'.

The hwaccels are officially called 'cuvid' and 'nvdec'. As a
convenience, we alias 'cuda' to 'nvdec'. The confusion is that the HW
pix_fmt and hwcontext are called 'cuda' because these are generic and
used by both decoders (and the various cuda based filters).

> What I'm wondering now is what difference all this makes at the side
> of the GPU acceleration, doesn't this end up being just the same?
> Why do we have that dual implementation?

We have two primarily because cuviddec was written first, as it's
relatively easy to build a working full codec around the nvidia library
and it supports all the formats largely automatically. Writing an
hwaccel is a bit more work, including the very tedious exercise of
mapping all the properties across when describing a frame for the
decoder. But it was eventually done.

Now, cuviddec has somewhat limited value. It allows you to take
advantage of the nvidia deinterlacer, which does rate doubling. This
can't be used in nvdec because an hwaccel can't change the frame rate.
It may be more performant in certain situations. But apart from those
two things, you should use nvdec. The ffmpeg parsers and decoders are
generally more capable than the nvidia ones, and particularly for HDR
content, the nvidia ones have problems.

I've made an attempt to bridge the deinterlacing gap by writing a
yadif_cuda deinterlacer as you've probably seen on the list, but I
suspect cuviddec will stick around just because it might be a useful
option for some people.


More information about the ffmpeg-devel mailing list