纵览FFmpeg硬件加速方案，涉及主流硬件和操作系统！

被称为“多媒体技术领域的瑞士军刀”，FFmpeg拥有广泛的应用基础。不过，当（实时）处理海量视频时，需要借助各种方法提升效率。比如，短视频平台Revvel将视频转码服务迁移到AWS Lambda和S3上，节省了大量费用和运维成本，并且将时长2小时的视频转码从4-6小时缩短到不到10分钟。本文将纵览FFmpeg的硬件加速方案，涉及各主流硬件方案和操作系统。本文为此系列的下篇，上篇请访问这里。感谢英特尔资深软件开发工程师赵军的投稿。

文 / 赵军

Android: MediaCodec 

MediaCodec是Google在Android API 16之后推出的用于音视频编解码的一套偏底层的API，可以直接利用硬件以加速视频的编解码处理。MediaCodec的概念中，一般而言，编解码器处理输入数据并生成输出数据。它异步处理数据并使用一组输入和输出缓冲区。在简单的层面上，需要请求（或接收）一个空输入缓冲区，填充数据并将其发送到编解码器进行处理。编解码器使用数据并将其转换为其空的输出缓冲区之一。最后，你请求（或接收）一个填充的输出缓冲区，消耗其内容并将其释放回编解码器。

MediaCodec可以处理的数据有以下三种类型：被压缩的Buffer（Compressed Buffers）、原始音频数据(Raw Audio Buffers)、原始视频数据(Raw Video Buffers)。可以使用ByteBuffers处理所有三种数据，但一般应该使用Surface以提高编解码器的性能。 Surface使用本地视频缓冲区，无需映射或复制到ByteBuffers; 因此，效率更高。 通常在使用Surface时无法访问原始视频数据，但可以使用ImageReader类来访问不安全的解码（原始）视频帧。 这可能比使用ByteBuffers更有效率，因为一些本机缓冲区可能被直接映射到ByteBuffers。 当使用ByteBuffer模式时，也可以使用Image类和getInput / OutputImage（int）访问原始视频帧。FFmpeg自3.1版本加入了android MediaCodec硬件解码支持，其实现Follow了FFmpeg的HWaccel接口，但直到现在为止，FFmpeg都并未支持基于MediaCodec的硬件加速编码。

1.基于Chip 厂商的私有方案

这里所提及的私有，并非是说代码没有Open，更多层面上是指所提供的相应的API接口和实现，是厂商所特定的，而非行业标准定义的API ，诸如OpenMAX或者OS层面剥离了硬件具体实现相关抽象的API。更进一步说，是采用相关厂商私有方案之后，如果想要二次深度开发，其困难度较大一些。实际上，从开放的角度而言，Intel，AMD，Nvidia这3家GPU大厂所提供的方案的Open 程度不尽相同，总的说来，其开放程度是Intel好于AMD, 而AMD又好于Nvidia。

Intel: Media SDK: 

Intel提供的Media SDK，本质是一套跨平台的加速方案，它在Windows/Linux上提供了相同的API，底层则分别使用了Windows上的DXVA2和Linux上的VAAPI接口，以Windows平台上为例，它的基本结构框图如下：

而在FFmpeg的集成中，基本上是在Libavcode/Libavfilter内提供了一个基本的wrapper去调用Media SDK的API来提供相应的功能。下图展示了Libavcodec集成MediaSDK的h264/hevc/mpeg2 Codec的状态，需要注意的是，FFmpeg master开发分支上支持的FFmpeg QSV已经支持了更多的Codec和相关VPP功能。

在Windows平台，如果你想在Intel 平台上执行编码相关的事务， Media SDK基本上是唯一的选择。当然，如果你更偏向FFmpeg的API，可以使用FFmpeg QSV/Media SDK的方式；而在Linux平台，FFmpeg VA-API与FFmpeg QSV/Media SDK 接口大部分功能重合，更多的区别可能在于软件灵活度和开放程度的考量。一般说来，FFmpeg VA-API提供了更大的灵活度，对于有开发能力或者想二次定制的客户更加的友好一些。从FFmpeg的角度看，这两者在FFmpeg框架内的最大不同点在于： FFmpeg VA-API是以Native CODEC的方式直接实现与FFmpeg内部，而FFmpeg QSV集成Media SDK的方式，非严格的类比则类似于FFmpeg 集成libx264 这样第三方库的方式，需要依赖Media SDK，而FFmpeg VA-API则并不依赖第三方的库，其CODEC的实现直接位于FFmpeg代码库自身。另外，需要提及的另外一件事情是，Media SDK开放了部分功能，其代码Repo在：

https://github.com/Intel-Media-SDK/MediaSDK

Nvidia: CUDA/CUVID/NVENC 

之前提及Nvidia的时候说过，Nvidia曾经一度提出VDPAU与Intel 提出的VA-API在Linux上竞争，但最近的趋势似乎是Nvidia走向了更为封闭的方式，最主要的倾向是，Nvidia似乎放缓了对VPDAU的支持，取而代之的是提供较为封闭的NVDEC与NVENC库。另外，在FFmpeg中集成NVENC 与NVDEC的方式与FFmpeg QSV集成Intel Media SDK方式一致，也是以集成第三方库的方式集成进FFmpeg的。这带来的弊端是，对NVENC/NVDEC的依赖较大，加上Nvidia并未开放NVENC/NVDEC的代码，因此如果想做二次开发或者功能增强以及性能调整的时候，基本都得依赖Nvidia自身去改动NVENC/NVDEC，这可能对部分开发者带来一些影响。

下面是NVECN/NVDEC说支持的CODEC的一个图示，基本上FFmpeg CUVID/NVECN/CUDA部分分别集成了硬件加速的解码，编码以及部分CUDA加速的诸如Scaling这样的Filter。另外，CUVID部分，为了和NVENC统一，Nvidia已经把它改称为NVENC，但FFmpeg并没有去做这个更新。

AMD: AMF

AMF SDK用于控制AMD媒体加速器，以进行视频编码和解码以及色彩空间转换，现在开源出来的版本（https://github.com/GPUOpen-LibrariesAndSDKs/AMF），并未支持Linux，只能在Windows上进行编码，支持的Codec有AVC/HEVC。需要指出的是AMF的全称是Advanced Media Framework，之前有时会被称之为VCE（Video Coding Engine）

另外，VCE实际上支持两种模式，一种模式是所谓的full fixed mode，这种模式之下，所有的编码相关执行使用的ASIC 方式，而另一种模式则是hybrid mode，主要是通过GPU中的3D引擎的计算单元执行编码相关动作，而对应的接口则是AMD's Accelerated Parallel Programming SDK 以及 OpenCL。

除了上述的一些方案以外，还有一些使用在嵌入式平台的一些方案，能够看到的有：

• BRCM的MMAL：

  http://www.jvcref.com/files/PI/documentation/html/

  https://github.com/techyian/MMALSharp/wiki/What-is-MMAL%3F

• RockChip：MPP

  http://opensource.rock-chips.com/wiki_Mpp

  http://opensource.rock-chips.com/images/f/fa/MPP_Development_Reference.pdf

• TI DSP方案：

  http://www.ti.com/processors/dsp/applications.html 

有兴趣者，可以通过这些资源自行去获取相关信息。

2.独立于平台与Chip厂商的优化方案

OpenCL与Vulkan: 

Khronos在OpenGL的年代一战成名，最近这些年，围绕着高性能图形图像API提出了大量的标准，其中有两个较新的标准值得注意，一个是OpenCL，最初是Apple提出，现在则是异构高性能并行计算的标准，其出发点基本是以Nvidia的CUDA为对标；另一个则是OpenGL的后继者Vulkan。最新的动向是Khronos似乎打算把OpenCL标准整合进Vulkan，所以很可能不久的将来，Vulkan会变成统一图像与计算的API。由于OpenCL基本上是GPU上编程的唯一通用标准（另一个业内使用范围更广泛的是Nvidia的CUDA），很自然的FFmpeg也打算用OpenCL去加速相应的一些Codec或者AVfiter相关的任务。最初，x264尝试用OpenCL优化，但结果并不尽理想，主要原因估计是很多时候编码器实现是一个反复迭代的过程，数据之间也会出现依赖，导致想完全并发利用OpenCL去加速，比较困难，所以最终x264只用OpenCL加速了部分功能，更多的信息可以参考

https://mailman.videolan.org/pipermail/x264-devel/2013-April/009996.html

FFmpeg并未尝试用OpenCL去优化Codec部分，但是却优化了AVFilter部分，主要用在硬件加速转码的场景下。其最大的好处是解码，Filter、编码都在GPU内部完成，避免了GPU与CPU之间的数据交换，而一般Codec输出的数据，需要与OpenCL实现所谓的Zero Copy，这一点，需要OpenCL做一些扩展以支持接收解码器解码的出来的数据格式，并输出编码器能接收的数据格式。这里典型的扩展如Intel 提出的OpenCL与VA-API的Surface sharing：

https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_va_api_media_sharing.txt：

最近，FFmpeg社区的Rostislav Pehlivanov开始尝试用Vulkan优化AVFilter，已经提交了Patch，正处于Review阶段，从他FOSDEM的PPT https://pars.ee/slides/fosdem18_encoding.pdf 看，他似乎也想再次尝试用Vulkan来优化Codec，但初期只有针对AVFilter的优化代码出现。顺带说一句，Rostislav Pehlivanov的这份PPT中，回顾了各种CODEC上的各种尝试，整个行业在CODEC上的努力，而其中大部分的CODEC，并未流行开来，但这些人的种种努力不该被完全忘记。

3.参考文献

• https://developer.nvidia.com/nvidia-video-codec-sdk 更多Nvidia video codec的信息，可以从这里获取到

• http://on-demand.gputechconf.com/gtc/2016/presentation/s6226-abhijit-patait-high-performance-video.pdf 这里对NVENC/NVDEC 给出了一些详尽的说明

• https://developer.android.com/reference/android/media/MediaCodec.html 使用MediaCodec时候，Android上的文档基本上是必须要先读的

• https://elinux.org/images/9/9d/Android_media_framework--van-dam_and_kallere.pdf

• https://static1.squarespace.com/static/4eb80772d09a941b5c45e0c0/t/541f2918e4b092469720191e/1411328280290/Video_DroidConNYC.pdf

• https://www.khronos.org/  khronos 最近动作不断，一方面，看到各种新标准的提出，另一方面又担心这些标准最终实施的状况。

WebRTCon 2018

WebRTCon 2018将于5月19-20日在上海光大国际会展中心举行，这是一次对过去几年WebRTC技术实践与应用落地的总结。

大会组委会以行业难点为目标，设立了主题演讲，WebRTC与前端，行业应用专场，测试监控和服务保障，娱乐多媒体开发应用实践，WebRTC深度开发，解决方案专场，WebRTC服务端开发，新技术跨界，WebRTC与Codec等多个专场。邀请30余位全球领先的WebRTC技术专家，为参会者带来全球同步的技术实践与趋势解读。

在主题演讲环节，Google软件工程师 Zoe Liu 、姜健，将分别向国内的开发者分享AV1的最新进展与技术探索、VP9的SVC优化。此外，北京大学教授王荣刚、英特尔实时通信客户端架构师邱建林、Aupera傲睿智存 CTO周正宁将分别分享国产Codec AVS2的最新演进、H.264的硬件编码优化，FPGA加速WebRTC服务端和转码。上海交通大学图像通信与网络工程研究所副所长宋利会分享学术界在Codec优化的最新思路与尝试，他会介绍AI、区块链和大数据赋能的Codec。