FFmpeg 硬件加速介绍

Posted 2023-04-05 音视频开发老马

硬件加速简介

使用专用硬件(通常集成到GPU)对视频处理进行加速，比如解码、编码或filter等操作[1]。

优点：

• 比软件处理速度快。
• 减少CPU的负荷，更省电。
• 避免数据拷贝。许多硬件解码器能够生成输出到硬件设备(比如显存)的surface，这意味渲染输出之前不需要额外的数据拷贝。在某些情况下，它还可以支持硬件设备的surface输入与编码器一起使用，以避免在转码时候的数据拷贝。

缺点：

• 硬件编码器生成的输出质量通常比好的软件编码器低得多[1]。
• 硬件加速方案依赖于各硬件和平台的支持，没有统一的方案。
• 对于特定处理(比如编解码)硬件加速的支持和更新迭代速度慢。

关于硬件加速的详细介绍参见[2][3]。

FFmpeg 硬件加速各环境支持情况

硬件加速API在各系统和硬解环境的支持情况如下[1]。

FFmpeg实现的API的情况如下[1]。

FFmpeg命令行工具使用硬件加速

• -hwaccel选项启用硬件解码器。
  • 软件解码器会正常启动，如果它检测到一个硬件可解码的流，将尝试将所有重要的处理交给硬件。如果流在硬件中不可解码，那么将自动使用软件解码。
• -hwaccel_device选项指定特定的硬件设备(比如有多个显卡可用)。
• -codec:v选项设置特定的编解码器，适用于外部包装的编解码器。
  • 通常将它们命名为codec_api(例如:h264_cuvid)，要求事先知道编解码器的名称。
  • 如果不支持不会回退到软件编解码。
• 硬件filter可以像其他filter一样在filtergraph中使用。
  • 存在硬件filter与软件filter支持的格式不同的情况，需要使用hwupload和hwdownload filter在硬件surface和内存之间拷贝数据。

【扫码进君 羊，免费分享】资料包括《Andoird音视频开发必备手册+音视频学习视频+学习文档资料包+大厂面试真题+2022最新学习路线图》等等 

示例：
1. 使用NVENC进行h264编码：

ffmpeg -s 1280*720 -i input_yuv -c:v h264_nvenc -pixel_format yuv420p -preset default output.mp4

 2. NVEDC进行h264解码

ffmpeg -hwaccel nvdec -i input.mp4 output_yuv

 

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 最近动作不断，一方面，看到各种新标准的提出，另一方面又担心这些标准最终实施的状况。