被稱為“多媒體技術(shù)領(lǐng)域的瑞士軍刀”，FFmpeg擁有廣泛的應(yīng)用基礎(chǔ)。不過，當(dāng)（實時）處理海量視頻時，需要借助各種方法提升效率。比如，短視頻平臺Revvel將視頻轉(zhuǎn)碼服務(wù)遷移到AWS Lambda和S3上，節(jié)省了大量費用和運維成本，并且將時長2小時的視頻轉(zhuǎn)碼從4-6小時縮短到不到10分鐘。本文將縱覽FFmpeg的硬件加速方案，涉及各主流硬件方案和操作系統(tǒng)。感謝英特爾資深軟件開發(fā)工程師趙軍的投稿。

文 / 趙軍

多媒體應(yīng)用程序是典型的資源密集型應(yīng)用，因此優(yōu)化多媒體應(yīng)用程序至關(guān)重要，這也是使用視頻處理專用硬件加速的初衷。作為回報，這允許整個系統(tǒng)更加有效地運行（以達(dá)到最佳性能）。 但是為了支持硬件加速，軟件開發(fā)廠商面臨著各種挑戰(zhàn)：一個是存在潛在的系統(tǒng)性能風(fēng)險問題；此外，軟件開發(fā)商一直也因為要面對各種硬件架構(gòu)的復(fù)雜性而苦苦掙扎，并需要維護(hù)不同的代碼路徑來支持不同的架構(gòu)和不同的方案。優(yōu)化這類代碼，耗時費力。想想你可能需要面對不同的操作系統(tǒng)，諸如Linux，Windows，macOS，Android，iOS，ChromeOS；需要面對不同的硬件廠商，諸如Intel，NVIDIA，AMD，ARM，TI, ?Broadcom……，因此，提供一個通用且完整的跨平臺，跨硬件廠商的多媒體硬件加速方案顯得價值非凡。

專用視頻加速硬件可以使得解碼，編碼或過濾（Filter）等操作更快完成且使用更少的其他資源（特別是CPU），但可能會存在額外的限制，而這些限制在僅使用軟件CODEC時一般不存在。在PC平臺上，視頻硬件通常集成到GPU（來自AMD，Intel或NVIDIA）中，而在移動SoC類型的平臺上，它通常是獨立的IP核（存在著許多不同的供應(yīng)商）。硬件解碼器一般生成與軟件解碼器相同的輸出，但使用更少的Power和CPU來完成解碼。另外，各種硬件支持的Feature也各不相同。對于具有多種不同Profile的復(fù)雜的CODEC，硬件解碼器很少實現(xiàn)全部功能（例如，對于H.264，硬件解碼器往往只支持8bit的YUV 4：2：0）。

許多硬件解碼器的一個共同特點是能夠輸出硬件Surface，而該Surface可以被其他組件進(jìn)一步使用（使用獨立顯卡時，這意味著硬件Surface在GPU的存儲器中，而非系統(tǒng)內(nèi)存） ，對于播放（Playback）的場景，避免了渲染輸出之前的Copy操作；在某些情況下，它也可以與支持硬件Surface輸入的編碼器一起使用，以避免在轉(zhuǎn)碼（transcode）情況下進(jìn)行任何Copy操作。另外，通常認(rèn)為硬件編碼器的輸出比x264等優(yōu)秀軟件編碼器質(zhì)量差一些，但速度通常更快，且不會占用太多的CPU資源。也就是說，他們需要更高的比特率來使輸出相同的視覺感知質(zhì)量，或者他們以相同的比特率以更低的視覺感知質(zhì)量輸出。具有解碼和/或編碼能力的系統(tǒng)還可以提供其他相關(guān)過濾（Filter）功能，比如常見的縮放（scale）和去隔行（deinterlace）；其他后處理（postprocessing）功能可能取決于系統(tǒng)。

FFmpeg所支持的硬件加速方案，粗略以各OS廠商和Chip廠商特定方案以及行業(yè)聯(lián)盟定義的標(biāo)準(zhǔn)來分為3類；其中，OS涉及Windows，Linux，macOS，Android；Chip廠商的特定方案涉及到Intel，AMD，Nvidia等；而行業(yè)標(biāo)準(zhǔn)則著重OpenMAX與OpenCL ；這只是一個粗略的分類，很多時候，這幾者之間縱橫交錯，聯(lián)系繁雜，之間的關(guān)系并非像列出的3類這般涇渭分明；這從另一個側(cè)面也印證了硬件加速方案的復(fù)雜性。就像我們熟知的大部分事情一樣，各種API或解決方案一面在不斷的進(jìn)化同時，它們也背負(fù)著過去的歷史，后面的分析中也可以或多或少的窺知其變遷的痕跡。

1.基于OS的硬件加速方案

• Windows：Direct3D 9 DXVA2 /Direct3D 11 Video API/DirectShow /Media Foundation

大多數(shù)用于Windows 上的多媒體應(yīng)用程序都基于Microsoft ?DirectShow 或Microsoft Media Foundation（MF）框架API，用他們?nèi)ブС痔幚砻襟w文件的各種操作；而Microsoft DirectShow Plug in和Microsoft Foundation Transforms（MFT）均集成了Microsoft DirectX ?視頻加速（DXVA）2.0，允許調(diào)用標(biāo)準(zhǔn) DXVA 2.0 接口直接操作GPU去offload Video的負(fù)載（workload）。

DirectX視頻加速（DXVA）是一個API和以及需要一個對應(yīng)的DDI實現(xiàn)，它被用作硬件加速視頻處理。軟件CODEC和軟件視頻處理器可以使用DXVA將某些CPU密集型操作卸載到GPU。例如，軟件解碼器可以將逆離散余弦變換（iDCT）卸載到GPU。 在DXVA中，一些解碼操作由圖形硬件驅(qū)動程序?qū)崿F(xiàn)，這組功能被稱為加速器（ accelerator）；其他解碼操作由用戶模式應(yīng)用軟件實現(xiàn)，稱為主機(jī)解碼器或軟件解碼器。通常情況下，加速器使用GPU來加速某些操作。無論何時加速器執(zhí)行解碼操作，主機(jī)解碼器都必須將包含執(zhí)行操作所需信息的加速器緩沖區(qū)傳送給加速器緩沖區(qū)。

DXVA 2 API需要Windows Vista或更高版本。為了后向兼容，Windows Vista仍支持DXVA 1 API（Windows提供了一個仿真層，可在API和DDI的版本之間進(jìn)行轉(zhuǎn)換；另外，由于 DAVX 1現(xiàn)在存在的價值基本上是后向兼容，所以我們略過它，文章中的DXVA，大多數(shù)情況下指的實際上是 DAVA2）。為了使用 DXVA功能，基本上只能根據(jù)需要選擇使用DirectShow或者M(jìn)edia Foundation；另外，需要注意的是，DXVA/DXVA2/DXVA-HD只定義了解碼加速，后處理加速，并未定義編碼加速，如果想從Windows層面加速編碼的話，只能選擇Media Foundation或者特定Chip廠商的編碼加速實現(xiàn)。現(xiàn)在，FFmpeg只支持了DXVA2的硬件加速解碼，DXVA-HD加速的后處理和基于Media Foundation硬件加速的編碼并未支持（在DirectShow時代，Windows上的編碼支持需要使用FSDK）。

下圖展示了基于Media Foundation媒體框架下，支持硬件加速的轉(zhuǎn)碼情況下的Pipeline：

注意，由于微軟的多媒體框架的進(jìn)化，實際上，現(xiàn)在存在兩種接口去支持硬件加速，分別是：Direct3D 9 DXVA2 與 Direct3D 11 Video API; 前者我們應(yīng)該使用IDirect3DDeviceManager9 接口作為加速設(shè)備句柄, 而后者則使用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.

?

在微軟網(wǎng)站上，上述兩種情況都有很好的描述，參考鏈接在：https://msdn.microsoft.com/en-us/library/windows/desktop/cc307941(v=vs.85).aspx。

從上面可以看到，實際上，FFmpeg基于Windows上的硬件加速，只有解碼部分，且只使用了Media Foundation媒體框架，只是同時支持了兩種設(shè)備綁定接口，分別是Direct3D 9 DXVA2 與 Direct3D 11 Video API。

• Linux：VDPAU/VAAPI/V4L2 M2M

Linux上的硬件加速接口，經(jīng)歷了一個漫長的演化過程，期間也是各種力量的角力，下面的漫畫非常形象的展示了有關(guān)接口的演化與各種力量的角力。

最終的結(jié)果是VDPAU（https://http.download.nvidia.com/XFree86/vdpau/doxygen/html/index.html）與VAAPI（https://github.com/intel/libva）共存這樣一個現(xiàn)狀，而這兩個API其后的力量，則分別是支持VDPAU的Nvidia和支持VA-API的Intel，另一個熟悉的Chip廠商AMD，實際上同時提供過基于VDPAU和VA-API的支持，真是為難了他。另外，對照VDPAU與VA-API可知，VDPAU僅定義了解碼部分的硬件加速，缺少了編碼部分的加速（解碼部分也缺乏VP8/VP9的支持，且API的更新狀態(tài)似乎也比較慢），此外，值得一提的是，最新的狀態(tài)是，Nvidia似乎是想用NVDEC去取代提供VDPAU接口的方式去提供Linux上的硬件加速（https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-NVDEC-GStreamer），或許不久的將來，VA-API會統(tǒng)一Linux上的Video硬件加速接口（這樣，AMD也不必有去同時支持VDPAU 與VAAPI而雙線作戰(zhàn)的窘境），這對Linux上的用戶，無疑可能是一個福音。除去VDPAU和VAAPI，Linux的Video4Linux2 API的擴(kuò)展部分定義了M2M接口，通過M2M的接口，可以把CODEC作為Video Filter去實現(xiàn)，現(xiàn)在某些SoC平臺下，已經(jīng)有了支持，這個方案多使用在嵌入式環(huán)境之中。

下圖展示了VA-API接口在X-Windows下面的框圖以及解碼流程： ?

FFmpeg 上，對VA-API的支持最為完備，基本上，所有主流的CODEC都有支持，DECODE支持的細(xì)節(jié)如下：

ENCODE支持的細(xì)節(jié)如下：

在AVFilter部分也同時支持了硬件加速的Scale/Deinterlace/ ProcAmp(color balance) Denoise/Sharpness，另外，我們在前面提及過，FFmpeg VAAPI的方案中，不只是有Intel的后端驅(qū)動，同時，它也可以支持Mesa's state-trackers for gallium drivers，這樣，其實可以支持AMD的GPU。

• macOS: VideoToolbox

在macOS上的硬件加速接口也是跟隨著Apple經(jīng)歷了漫長的演化，從90年代初的QuickTime 1.0所使用的基于C的API開始，一直到iOS 8 以及 OS X 10.8，Apple 才最終發(fā)布完整的 Video Toolbox framework（之前的硬件加速接口并未公布，而是Apple自己內(nèi)部使用），期間也出現(xiàn)了現(xiàn)在已經(jīng)廢棄的Video Decode Acceleration (VDA)接口。Video Toolbox是一套C API ，依賴了CoreMedia, CoreVideo, 以及 CoreFoundation 框架 ，同時支持編碼，解碼，Pixel轉(zhuǎn)換等功能。Video Toolbox所處的基本層次以及更細(xì)節(jié)的相關(guān)結(jié)構(gòu)體如下：

?

關(guān)于Video Toolbox的更多細(xì)節(jié)，可以參考https://developer.apple.com/documentation/videotoolbox。

參考文獻(xiàn)

• https://trac.ffmpeg.org/wiki/HWAccelIntro，FFmpeg的網(wǎng)站上對硬件加速的信息，是首要閱讀的文檔?

• 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?

• 有關(guān)標(biāo)準(zhǔn)的漫畫，出自https://xkcd.com/927/

• https://wiki.archlinux.org/index.php/Hardware_video_acceleration 和https://wiki.ubuntu.com/IntelQuickSyncVideo Archlinux和Ubuntu 網(wǎng)站對 VDPAU和 VA-API后端驅(qū)動的支持，雖然內(nèi)容有些過時，但仍然頗值得參考

• https://trac.ffmpeg.org/wiki/Hardware/VAAPI 和 https://wiki.libav.org/Hardware/vaapi 如果你忘了怎么在FFmpeg 命令行使用VA-API， 這兩個地方是你最應(yīng)該看看的

• Video Toolbox and Hardware Acceleration 里面詳細(xì)講解了macOS平臺上，硬件加速框架的演化還有Video Toobox的技術(shù)細(xì)節(jié)，與之對應(yīng)的是WWDC2014 上的 https://developer.apple.com/videos/play/wwdc2014/513/ 也值得一讀?

• https://github.com/intel/libva VA-API 的接口定義甚至沒有正規(guī)的文檔，好在頭文件里面的注釋還寫得非常清楚，這也是典型開源項目的風(fēng)格吧

活動推薦

2018年初的音視頻技術(shù)生態(tài)并不平靜，LiveVideoStack將通過“LiveVideoStack Meet：多媒體開發(fā)新趨勢”系列沙龍，展現(xiàn)新技術(shù)在音視頻領(lǐng)域的探索與實踐，以及新興應(yīng)用場景和傳統(tǒng)行業(yè)的最新、最佳實踐。3月31日我們將迎來系列沙龍的第一站——北京，屆時來自小米、今日頭條、理光軟件研究院、三體云等5位資深多媒體開發(fā)大咖一同展望多媒體開發(fā)最新趨勢和技術(shù)實踐。

關(guān)注LiveVideoStack公眾號，回復(fù)【北京】將獲得限量5折優(yōu)惠碼，先用先得。點擊【閱讀原文】獲取更多沙龍信息。

總結(jié)

以上是生活随笔為你收集整理的FFmpeg 硬件加速方案概览 （上）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。