被稱為“多媒體技術領域的瑞士×××”，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）。

下圖展示了基於Media Foundation媒體框架下，支持硬件加速的轉碼情況下的Pipeline：

註意，由於微軟的多媒體框架的進化，實際上，現在存在兩種接口去支持硬件加速，分別是：Direct3D 9 DXVA2 與 Direct3D 11 Video API; 前者我們應該使用IDirect3DDeviceManager9 接口作為加速設備句柄, 而後者則使用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.

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

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

• Linux：VDPAU/VAAPI/V4L2 M2M

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

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

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

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

ENCODE支持的細節如下：

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

• macOS: VideoToolbox

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

關於Video Toolbox的更多細節，可以參考https://developer.apple.com/documentation/videotoolbox。

參考文獻

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

• 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

• 有關標準的漫畫，出自https://xkcd.com/927/

• https://wiki.archlinux.org/index.php/Hardware_video_acceleration 和https://wiki.ubuntu.com/IntelQuickSyncVideo Archlinux和Ubuntu 網站對 VDPAU和 VA-API後端驅動的支持，雖然內容有些過時，但仍然頗值得參考

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

• Video Toolbox and Hardware Acceleration 裏面詳細講解了macOS平臺上，硬件加速框架的演化還有Video Toobox的技術細節，與之對應的是WWDC2014 上的 https://developer.apple.com/videos/play/wwdc2014/513/ 也值得一讀

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