FFmpeg 硬件加速方案概览 （上）

被称为“多媒体技术领域的瑞士军刀”，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或解决方案一面在不断的进化同时，它们也背负着过去的历史，后面的分析中也可以或多或少的窥知其变迁的痕迹。