找回密码
 立即注册
LiveVideoStack 首页 资讯 查看内容
  • QQ空间
  • 回复
  • 收藏

FFmpeg 硬件加速方案概览 (1)

2018-3-9 09:00

被称为“多媒体技术领域的瑞士军刀”,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)。


123下一页
原作者: 赵军 来自: LiveVideoStack
文章点评