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

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

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

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

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

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

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

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

對(duì)于Direct3D 9 DXVA2的接口，基本解碼步驟如下：

• Open a handle to the Direct3D 9 device.

• Find a DXVA decoder configuration.

• Allocate uncompressed Buffers.

• Decode frames.

而對(duì)于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。

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

• Linux：VDPAU/VAAPI/V4L2 M2M

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

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

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

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

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

在AVFilter部分也同時(shí)支持了硬件加速的Scale/Deinterlace/ ProcAmp(color balance) Denoise/Sharpness，另外，我們?cè)谇懊嫣峒斑^(guò)，F(xiàn)Fmpeg VAAPI的方案中，不只是有Intel的后端驅(qū)動(dòng)，同時(shí)，它也可以支持Mesa's state-trackers for gallium drivers，這樣，其實(shí)可以支持AMD的GPU。

• macOS: VideoToolbox

在macOS上的硬件加速接口也是跟隨著Apple經(jīng)歷了漫長(zhǎng)的演化，從90年代初的QuickTime 1.0所使用的基于C的API開(kāi)始，一直到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 框架 ，同時(shí)支持編碼，解碼，Pixel轉(zhuǎn)換等功能。Video Toolbox所處的基本層次以及更細(xì)節(jié)的相關(guān)結(jié)構(gòu)體如下：