被称为“多媒体技术领域的瑞士军刀”，FFmpeg拥有广泛的应用基础。不过，当（实时）处理海量视频时，需要借助各种方法提升效率。比如，短视频平台Revvel将视频转码服务迁移到AWS Lambda和S3上，节省了大量费用和运维成本，并且将时长2小时的视频转码从4-6小时缩短到不到10分钟。本文将纵览FFmpeg的硬件加速方案，涉及各主流硬件方案和操作系统。感谢英特尔资深软件开发工程师赵军的投稿。
文 / 赵军
多媒体应用程序是典型的资源密集型应用，因此优化多媒体应用程序至关重要，这也是使用视频处理专用硬件加速的初衷。作为回报，这允许整个系统更加有效地运行（以达到最佳性能）。 但是为了支持硬件加速，软件开发厂商面临着各种挑战：一个是存在潜在的系统性能风险问题；此外，软件开发商一直也因为要面对各种硬件架构的复杂性而苦苦挣扎，并需要维护不同的代码路径来支持不同的架构和不同的方案。优化这类代码，耗时费力。想想你可能需要面对不同的操作系统，诸如Linux，Windows，macOS，Android，iOS，ChromeOS；需要面对不同的硬件厂商，诸如Intel，NVIDIA，AMD，ARM，TI, Broadcom……，因此，提供一个通用且完整的跨平台，跨硬件厂商的多媒体硬件加速方案显得价值非凡。
专用视频加速硬件可以使得解码，编码或过滤（Filter）等操作更快完成且使用更少的其他资源（特别是CPU），但可能会存在额外的限制，而这些限制在仅使用软件CODEC时一般不存在。在PC平台上，视频硬件通常集成到GPU（来自AMD，Intel或NVIDIA）中，而在移动SoC类型的平台上，它通常是独立的IP核（存在着许多不同的供应商）。硬件解码器一般生成与软件解码器相同的输出，但使用更少的Power和CPU来完成解码。另外，各种硬件支持的Feature也各不相同。对于具有多种不同Profile的复杂的CODEC，硬件解码器很少实现全部功能（例如，对于H.264，硬件解码器往往只支持8bit的YUV 4：2：0）。
许多硬件解码器的一个共同特点是能够输出硬件Surface，而该Surface可以被其他组件进一步使用（使用独立显卡时，这意味着硬件Surface在GPU的存储器中，而非系统内存） ，对于播放（Playback）的场景，避免了渲染输出之前的Copy操作；在某些情况下，它也可以与支持硬件Surface输入的编码器一起使用，以避免在转码（transcode）情况下进行任何Copy操作。另外，通常认为硬件编码器的输出比x264等优秀软件编码器质量差一些，但速度通常更快，且不会占用太多的CPU资源。也就是说，他们需要更高的比特率来使输出相同的视觉感知质量，或者他们以相同的比特率以更低的视觉感知质量输出。具有解码和/或编码能力的系统还可以提供其他相关过滤（Filter）功能，比如常见的缩放（scale）和去隔行（deinterlace）；其他后处理（postprocessing）功能可能取决于系统。
FFmpeg所支持的硬件加速方案，粗略以各OS厂商和Chip厂商特定方案以及行业联盟定义的标准来分为3类；其中，OS涉及Windows，Linux，macOS，Android；Chip厂商的特定方案涉及到Intel，AMD，Nvidia等；而行业标准则着重OpenMAX与OpenCL ；这只是一个粗略的分类，很多时候，这几者之间纵横交错，联系繁杂，之间的关系并非像列出的3类这般泾渭分明；这从另一个侧面也印证了硬件加速方案的复杂性。就像我们熟知的大部分事情一样，各种API或解决方案一面在不断的进化同时，它们也背负着过去的历史，后面的分析中也可以或多或少的窥知其变迁的痕迹。
1.基于OS的硬件加速方案
Windows：Direct3D 9 DXVA2 /Direct3D 11 Video API/DirectShow /Media Foundation
大多数用于Windows 上的多媒体应用程序都基于Microsoft DirectShow 或Microsoft Media Foundation（MF）框架API，用他们去支持处理媒体文件的各种操作；而Microsoft DirectShow Plug in和Microsoft Foundation Transforms（MFT）均集成了Microsoft DirectX 视频加速（DXVA）2.0，允许调用标准 DXVA 2.0 接口直接操作GPU去offload Video的负载（workload）。
DirectX视频加速（DXVA）是一个API和以及需要一个对应的DDI实现，它被用作硬件加速视频处理。软件CODEC和软件视频处理器可以使用DXVA将某些CPU密集型操作卸载到GPU。例如，软件解码器可以将逆离散余弦变换（iDCT）卸载到GPU。 在DXVA中，一些解码操作由图形硬件驱动程序实现，这组功能被称为加速器（ accelerator）；其他解码操作由用户模式应用软件实现，称为主机解码器或软件解码器。通常情况下，加速器使用GPU来加速某些操作。无论何时加速器执行解码操作，主机解码器都必须将包含执行操作所需信息的加速器缓冲区传送给加速器缓冲区。
DXVA 2 API需要Windows Vista或更高版本。为了后向兼容，Windows Vista仍支持DXVA 1 API（Windows提供了一个仿真层，可在API和DDI的版本之间进行转换；另外，由于 DAVX 1现在存在的价值基本上是后向兼容，所以我们略过它，文章中的DXVA，大多数情况下指的实际上是 DAVA2）。为了使用 DXVA功能，基本上只能根据需要选择使用DirectShow或者Media Foundation；另外，需要注意的是，DXVA/DXVA2/DXVA-HD只定义了解码加速，后处理加速，并未定义编码加速，如果想从Windows层面加速编码的话，只能选择Media Foundation或者特定Chip厂商的编码加速实现。现在，FFmpeg只支持了DXVA2的硬件加速解码，DXVA-HD加速的后处理和基于Media Foundation硬件加速的编码并未支持（在DirectShow时代，Windows上的编码支持需要使用FSDK）。
下图展示了基于Media Foundation媒体框架下，支持硬件加速的转码情况下的Pipeline：
注意，由于微软的多媒体框架的进化，实际上，现在存在两种接口去支持硬件加速，分别是：Direct3D 9 DXVA2 与 Direct3D 11 Video API; 前者我们应该使用IDirect3DDeviceManager9 接口作为加速设备句柄, 而后者则使用ID3D11Device 接口。
对于Direct3D 9 DXVA2的接口，基本解码步骤如下：
Open a handle to the Direct3D 9 device.
Find a DXVA decoder configuration.
Allocate uncompressed Buffers.
Decode frames.
而对于Direct3D 11 Video API 接口，基本解码步骤如下：
Open a handle to the Direct3D 11 device.
Find a decoder configuration.
Allocate uncompressed buffers.
Decode frames.
在微软网站上，上述两种情况都有很好的描述，参考链接在：https://msdn.microsoft.com/en-us/library/windows/desktop/cc307941(v=vs.85).aspx。
从上面可以看到，实际上，FFmpeg基于Windows上的硬件加速，只有解码部分，且只使用了Media Foundation媒体框架，只是同时支持了两种设备绑定接口，分别是Direct3D 9 DXVA2 与 Direct3D 11 Video API。
Linux：VDPAU/VAAPI/V4L2 M2M
Linux上的硬件加速接口，经历了一个漫长的演化过程，期间也是各种力量的角力，下面的漫画非常形象的展示了有关接口的演化与各种力量的角力。
最终的结果是VDPAU（https://http.download.nvidia.com/XFree86/vdpau/doxygen/html/index.html）与VAAPI（https://github.com/intel/libva）共存这样一个现状，而这两个API其后的力量，则分别是支持VDPAU的Nvidia和支持VA-API的Intel，另一个熟悉的Chip厂商AMD，实际上同时提供过基于VDPAU和VA-API的支持，真是为难了他。另外，对照VDPAU与VA-API可知，VDPAU仅定义了解码部分的硬件加速，缺少了编码部分的加速（解码部分也缺乏VP8/VP9的支持，且API的更新状态似乎也比较慢），此外，值得一提的是，最新的状态是，Nvidia似乎是想用NVDEC去取代提供VDPAU接口的方式去提供Linux上的硬件加速（https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-NVDEC-GStreamer），或许不久的将来，VA-API会统一Linux上的Video硬件加速接口（这样，AMD也不必有去同时支持VDPAU 与VAAPI而双线作战的窘境），这对Linux上的用户，无疑可能是一个福音。除去VDPAU和VAAPI，Linux的Video4Linux2 API的扩展部分定义了M2M接口，通过M2M的接口，可以把CODEC作为Video Filter去实现，现在某些SoC平台下，已经有了支持，这个方案多使用在嵌入式环境之中。
下图展示了VA-API接口在X-Windows下面的框图以及解码流程：
FFmpeg 上，对VA-API的支持最为完备，基本上，所有主流的CODEC都有支持，DECODE支持的细节如下：
ENCODE支持的细节如下：
在AVFilter部分也同时支持了硬件加速的Scale/Deinterlace/ ProcAmp(color balance) Denoise/Sharpness，另外，我们在前面提及过，FFmpeg VAAPI的方案中，不只是有Intel的后端驱动，同时，它也可以支持Mesa's state-trackers for gallium drivers，这样，其实可以支持AMD的GPU。
macOS: VideoToolbox
在macOS上的硬件加速接口也是跟随着Apple经历了漫长的演化，从90年代初的QuickTime 1.0所使用的基于C的API开始，一直到iOS 8 以及 OS X 10.8，Apple 才最终发布完整的 Video Toolbox framework（之前的硬件加速接口并未公布，而是Apple自己内部使用），期间也出现了现在已经废弃的Video Decode Acceleration (VDA)接口。Video Toolbox是一套C API ，依赖了CoreMedia, CoreVideo, 以及 CoreFoundation 框架 ，同时支持编码，解码，Pixel转换等功能。Video Toolbox所处的基本层次以及更细节的相关结构体如下：
关于Video Toolbox的更多细节，可以参考https://developer.apple.com/documentation/videotoolbox。
参考文献
https://trac.ffmpeg.org/wiki/HWAccelIntro，FFmpeg的网站上对硬件加速的信息，是首要阅读的文档
Supporting DXVA 2.0 in Media Foundation 微软的msdn，讲解了如何在Media Foundation中支持 DXVA2, 里面讲的是如何绑定 Direct3D9 device
Supporting Direct3D 11 Video Decoding in Media Foundation 另一份msdn文档，讲的是Media Foundation 中如何使用 Direct3D 11 去支持 DXVA2
有关标准的漫画，出自https://xkcd.com/927/
https://wiki.archlinux.org/index.php/Hardware_video_acceleration 和https://wiki.ubuntu.com/IntelQuickSyncVideo Archlinux和Ubuntu 网站对 VDPAU和 VA-API后端驱动的支持，虽然内容有些过时，但仍然颇值得参考
https://trac.ffmpeg.org/wiki/Hardware/VAAPI 和 https://wiki.libav.org/Hardware/vaapi 如果你忘了怎么在FFmpeg 命令行使用VA-API， 这两个地方是你最应该看看的
Video Toolbox and Hardware Acceleration 里面详细讲解了macOS平台上，硬件加速框架的演化还有Video Toobox的技术细节，与之对应的是WWDC2014 上的 https://developer.apple.com/videos/play/wwdc2014/513/ 也值得一读
https://github.com/intel/libva VA-API 的接口定义甚至没有正规的文档，好在头文件里面的注释还写得非常清楚，这也是典型开源项目的风格吧
活动推荐
2018年初的音视频技术生态并不平静，LiveVideoStack将通过“LiveVideoStack Meet：多媒体开发新趋势”系列沙龙，展现新技术在音视频领域的探索与实践，以及新兴应用场景和传统行业的最新、最佳实践。3月31日我们将迎来系列沙龙的第一站——北京，届时来自小米、今日头条、理光软件研究院、三体云等5位资深多媒体开发大咖一同展望多媒体开发最新趋势和技术实践。
关注LiveVideoStack公众号，回复【北京】将获得限量5折优惠码，先用先得。点击【阅读原文】获取更多沙龙信息。
