从 NVIDIA® Fermi™ 一代开始，英伟达GPU包含一个视频解码器引擎（本文中简称NVDEC），它提供全硬件加速解码视频的能力。NVDEC能解码许多码流格式： H.264, HEVC (H.265), VP8, VP9, MPEG-1, MPEG-2, MPEG-4 and VC-1. NVDEC运行完全独立于计算/图像引擎。

英伟达提供编程NVDEC的软件API和库。这套软件API，以下称为NVDECODE API，它使开发者能访问NVDEC的解码特性，并且能让NVDEC与GPU上的其它引擎交互。

NVDEC解码压缩的视频流，然后复制解码后的YUV帧到显存，因此CUDA可以后续处理位于显存中的YUV帧。对于大多数流行的输出视频格式，NVDECODE API 也提供一些常用的CUDA优化的后处理，比如缩放、裁剪、宽高比转换、反交错和色彩空间转换。

解码后的视频帧可以传递给显示器播放，直接传给NVENC进行高性能视频转码，用于GPU加速的推理，通过CUDA或者基于CPU后续处理。

NVDECODE API 支持的解码格式如下： ‣ MPEG-1, ‣ MPEG-2, ‣ MPEG4, ‣ VC-1, ‣ H.264 (AVCHD) (8 bit), ‣ H.265 (HEVC) (8bit, 10 bit and 12 bit), ‣ VP8, ‣ VP9(8bit, 10 bit and 12 bit), ‣ Hybrid (CUDA + CPU) JPEG

下表展示每种GPU架构支持的解码格式和视频解码能力。

[1] 只支持 GP104, Turing 和 GA100 [2] GP10x GPUs 支持 VP9 10-bit 和 12-bit 解码

解码管道包含三个主要的组件：解封装器，视频解析器，视频解码器。每个组件互不依赖因此能独立使用。NVDECODE API提供英伟达视频解析器和英伟达视频解码器API。英伟达视频解析器是一个纯软件组件，用户可以用自己的插件替换（比如ffmpeg解析器）。 使用NVDECODE API 解码视频的步骤大致如下：

所有的 NVDECODE APIs 声明在两个头文件中： cuviddec.h 和 nvcuvid.h。这些头文件存放在Video Codec SDK中的 …\Samples\NvCodec\NvDecoder 目录下。 NVIDIA Video Codec SDK 中的示例静态加载库函数，在源文件中包含cuviddec.h 和nvcuvid.h ，SDK包中包含静态库文件。windows 动态库nvcuvid.dll 包含在windows显卡驱动中，linux 动态库libnvcuvid.so 则包含在linux显卡驱动中。

填充好 CUVIDPARSERPARAMS结构体后，通过调用 cuvidCreateVideoParser() 可以创建解析器对象。这个结构体应该填充好以下关于需要解码的流的信息。

CodecType ：必须取值于 enum cudaVideoCodec，指示解码的类型，比如 H.264, HEVC, VP9等

ulMaxNumDecodeSurfaces：这是解析器的解码图片缓存的表面数量。这个值在解析器初始化时可能不知道，在创建解析器对象时可以预先设置成1. 应用必须向驱动注册一个回调函数 pfnSequenceCallback，当解析器遇到第一个序列头或者这个序列发生了任何变化时会回调这个函数。这个回调函数通过参数CUVIDEOFORMAT::min_num_decode_surfaces报告为了正确解码，解析器的解码图片缓存需要的最小的表面数量。如果想更新CUVIDPARSERPARAMS::ulMaxNumDecodeSurfaces，这个序列回调函数可能返回这个值给解析器，如果这个值大于1，解析器可以使用这个值重新设置CUVIDPARSERPARAMS::ulMaxNumDecodeSurfaces。因此，为了内存分配优化，解码器对象创建时使用的缓存数量，应该使用： CUVIDDECODECREATEINFO::ulNumDecodeSurfaces = CUVIDPARSERPARAMS::ulMaxNumDecodeSurfaces.

ulMaxDisplayDelay：调用显示回调函数延迟。0代表没有延迟

pfnSequenceCallback ： 应用必须注册一个回调函数序列改变的情况。当解析器初始化序列头或者视频格式改变时，触发这个回调函数。序列回调函数的返回值由驱动程序解释如下：

pfnDecodePicture ： 当一帧的码流数据准备好时，解析器触发这个回调函数。对于奇偶场的图片，因为两个场组成一帧，每一次显示回调会有两次解码回调。这个回调函数的返回值解释如下：

pfnDisplayPicture ： 当一帧按显示顺序准备就绪时，解析器调用这个函数。返回值同上。

从解封装器中提取的数据包使用cuvidParseVideoData()函数传递给解析器，与此同时，当序列发生改变或者一帧画面已准备好解码或显示时，解析器触发创建解析器对象时注册的回调函数。

解码后数据通过一个CUVIDPICPARAMS里的图片索引绑定，它由解析器提供。这个图片索引后续用于将解码帧映射到CUDA内存。

用户需要调用 cuvidDestroyVideoParser()函数销毁解析器对象以及释放所有分配的资源。

如表1所示，不同的GPU包含不同的能力. 因此，为了确保你的应用能在所有的GPU硬件上运行，很有必要查询硬件能力，然后根据所需的能力是否满足进行合适的操作。

API cuvidGetDecoderCaps() 让用户能够查询底层硬件视频的解码能力。进行调用的线程应该有一个有效的CUDA上下文与之绑定。

客户端在调用 cuvidGetDecoderCaps() 之前应该填充以下参数。

‣ eCodecType: Codec type (H.264, HEVC, VP9, JPEG etc.) ‣ eChromaFormat: 4:2:0, 4:4:4, etc. ‣ nBitDepthMinus8: 0 for 8-bit, 2 for 10-bit, 4 for 12-bit

当cuvidGetDecoderCaps() 调用后，底层驱动填充CUVIDDECODECAPS的剩余字段，显示对于查询的能力的支持情况。

示例：

在创建解码器示例之前，用户需要一个有效的CUDA上下文，它将在整个解码过程中使用。

在填充CUVIDDECODECREATEINFO结构体后，通过调用cuvidCreateDecoder()创建解码器实例。CUVIDDECODECREATEINFO应该填充以下关于需要解码的流的信息：

cuvidCreateDecoder()使用解码器句柄填充CUvideodecoder，在整个解码器会话期间，该句柄应该一直保留。该句柄需要被其它 NVDECODE API调用传递。

用户可以指定CUVIDDECODECREATEINFO中的下列参数控制最终输出：

示例：

在解封装和解析之后，客户端可以将一帧或一场数据传递给硬件解码器解码，步骤如下：

用户需要通过调用cuvidMapVideoFrame()函数获取输出表面的CUDA设备指针和pitch大小，输出表面保存经过解码和后处理的帧。

cuvidDecodePicture()指导NVDEC硬件引擎开始解码帧/场.。然而，cuvidMapVideoFrame()调用成功意味着解码过程完成，而且解码后的格式转换成了CUVIDDECODECREATEINFO::OutputFormat中指定的yuv格式。

API cuvidMapVideoFrame()使用解码表面索引作为输入，将它映射到一个有效的输出表面，对解码帧进行后处理然后拷贝到输出表面，返回CUDA设备指针和输出表面关联的pitch.

上文的cuvidMapVideoFrame()操作以下称为mapping.

在用户处理完帧后，必须调用cuvidUnmapVideoFrame()使得输出表面再次可用。

如果在cuvidMapVideoFrame()之后，用户调用 cuvidUnmapVideoFrame()持续失败， cuvidMapVideoFrame()最终也会失败，最多CUVIDDECODECREATEINFO::ulNumOutputSurfaces数量的帧可以被映射。

cuvidMapVideoFrame()是一个阻塞式调用，它等待解码完成。如果cuvidMapVideoFrame()和cuvidDecodePicture()在同一个cpu线程调用，它会阻塞cuvidDecodePicture()。建议用户使用生产者-消费者队列，解码线程作为生产者，映射线程作为消费者。解码线程在显示回调函数中添加图片索引到队列，并且从回调函数迅速返回继续进行解码后面的帧。另一方面，映射线程监测队列，一旦有数据，使用nPicIdx作为图片索引调用cuvidMapVideoFrame(…)。解码线程必须确保避免用于存放解码后的输出的解码图片缓存，在被映射线程消费并释放之前被重复使用。

示例：

在大多数使用场景下，NVDEC会成为性能瓶颈，如果驱动里的NVDEC 等待队列满了，cuvidDecodePicture()会卡住。

解码开始后， 可以随时调用cuvidGetDecodeStatus()查询帧的解码状态。底层驱动填充解码状态到CUVIDGETDECODESTATUS::*pDecodeStatus。

NVDECODEAPI目前报告以下状态：

在码流分辨率发生改变或者修改后处理参数，API cuvidReconfigureDecoder()可以直接重新配置解码器，而不需要销毁解码器实例再重新创建。

以下是使用cuvidReconfigureDecoder()的步骤：

用户应该调用cuvidDestroyDecoder()销毁解码器会话，并且释放所以分配的解码器资源。

英伟达GPU上的NVDEC引擎是一个专用的硬件块，它解码支持的视频码流格式。一个典型视频解码应用大致包含以下几步：

这些步骤中，解封装和解析不带硬件加速因此超出了本文范围. 解封装可以使用第三方组件比如ffmpeg，它支持许多视频格式。SDK中的示例使用ffmpeg解封装。同样的，解码后处理可以使用用户自定义的CUDA核。进一步处理后的视频帧可以送往显示引擎显示。

为了有效的管道操作，NVDEC驱动内部维护了一个4帧的队列。请注意，这个队列并不意味着解码延迟，一旦有帧进入队列，解码立即开始，只要队列未满，应用就可以排队帧。

对于高性能和低延迟的视频解码应用，确保 PCIE 链接宽度设置为最大的有效值，PCIE 链接宽度的当前值可以通过运行'nvidia-smi -q'.命令获取，它可以在系统的BIOS设置中配置。

在码流分辨率或者后处理参数经常改变的使用场景中，推荐使用cuvidReconfigureDecoder()，而不是先销毁再重新创建解码器。

为了优化视频内存使用，以下步骤应该被遵守：

保证CUVIDDECODECREATEINFO::ulNumDecodeSurfaces = CUVIDEOFORMAT:: min_num_decode_surfaces，它是在正确解码的情况下，驱动分配最小的最小解码表面。如果解码性能下降，可以适当增大`CUVIDDECODECREATEINFO::ulNumDecodeSurfaces

CUVIDDECODECREATEINFO::ulNumOutputSurfaces应该在经过平衡吞吐量和内存消耗的测试后选择合适的值。

CUVIDDECODECREATEINFO::DeinterlaceMode应该设置为cudaVideoDeinterlaceMode_Weave或 cudaVideoDeinterlaceMode_Bob.对于交错模式，使用cudaVideoDeinterlaceMode_Adaptive会提过质量但是会增大内存消耗，使用cudaVideoDeinterlaceMode_Weave或cudaVideoDeinterlaceMode_Bob.则相反

解码多路视频流时，推荐分配最小数量的CUDA上下然后在不同的会话间共享，这有利于节省创建CUDA上下文的内存支出。

如果预先知道码流只包含I帧 CUVIDDECODECREATEINFO::ulIntraDecodeOnly应该设置为1，这个特性只支持HEVC, H.264 和 VP9。然而如果这个标志位打开，但是码流中包含P帧或B帧，解码可能失败。

SDK中示例用于演示各种API的功能，但可能没有全部优化，因此开发者应该确保他们的应该是精心设计的，在解封装、解析，解码各个阶段，以有效的方式结构化，以达到预期的性能和内存消耗。