英特爾提供了一套基于VA-API/Media SDK的硬件加速方案，通過在FFmpeg中集成Intel GPU的媒體硬件加速能力，為用戶提供更多的收益。本文來自英特爾資深軟件開發(fā)工程師趙軍在LiveVideoStackCon 2017大會上的分享，并由LiveVideoStack整理而成。

大家好，今天與大家分享的主題是FFmpeg在 Intel GPU上的硬件加速與優(yōu)化。

1、Media pipeline review

上圖展示的是典型的Media Pipeline。我們知道，F(xiàn)Fmpeg對輸入格式支持非常的全面，可以是文件、網(wǎng)絡(luò)流等，也可以使用Device的Caputer作為輸入；輸入的音視頻經(jīng)過Splitter后一般會分為兩種常見場景：Play Back與Transcoder。上圖的右上半部分實際是一個Transcoder的基本流程，解復(fù)用之后的Video、Audio的ES流，再經(jīng)過Video、Audio的Filter，大部分情況下，Video有可能在AVFilter執(zhí)行一些Scale、Frc、Crop操作（也可以在AVFiter中抓取有價值的信息）；隨后音視頻數(shù)據(jù)會被轉(zhuǎn)碼成為用戶指定的格式，轉(zhuǎn)碼時候多伴隨著碼率轉(zhuǎn)換、指定IPB幀類型等；Audio也會經(jīng)過類似的處理流程。上圖的右下半部可以視為播放器處理流程也就是Playback，Playback流程與Transcoder處理流程的主要差異在于對解碼的數(shù)據(jù)是否進行再次編碼或者直接顯示。另外，眾所周知，Encoder與Decoder的復(fù)雜程度存在一個數(shù)量級的差異，計算復(fù)雜度大概為10：1，且一般情況下Encoder每十年進化為一代，從MPEG2發(fā)展到H264大概用了十年時間，而從H264發(fā)展到HEVC將近十年時間（實際不到十年），其計算復(fù)雜度提升均為上一代的十倍左右，但壓縮率提升大概只有40%到50%，其背后是對計算量的大幅渴求，CPU的計算能力有時不能實時跟上計算量的需求或在高轉(zhuǎn)碼密度條件下不能提供較好的性價比，在此背景下，Intel提出了基于Intel GPU的媒體硬件加速解決方案。

2、何謂FFmpeg/VA-API？

作為最為流行的開源媒體解決方案，F(xiàn)Fmpeg有兩種使用方式：直接使用它自帶Tools，或者把FFmpeg作為Library調(diào)用它的API而實現(xiàn)自己的邏輯。其中的Tools包含我們經(jīng)常看到的轉(zhuǎn)碼工具FFmpeg；輕量媒體播放器FFPlayer；進行格式的探測分析的FFProbe ；輕量級流媒體測試的服務(wù)器FFServer等。另外，F(xiàn)Fmpeg的內(nèi)部實現(xiàn)基本以C語言為主，輔助以部分匯編優(yōu)化；同時它支持Linux、MacOSX、Android、Windows等不同OS，有著良好的跨平臺兼容性。這里另外強調(diào)一點的是FFmpeg自身的License問題，也許國內(nèi)的廠商不會特別在意License，但在實際使用場景中，所使用軟件或者庫的License即版權(quán)是不能不考慮的問題。最近幾年FFmpeg已經(jīng)將License的問題澄清得比較清楚，目前它的大多數(shù)內(nèi)部實現(xiàn)代碼使用GPL2.1版本的License。

3、Linux Video API

接下來我將介紹Linux平臺上Video加速API的進化歷史。我們知道，每一個突破性創(chuàng)新都是從細微之處開始慢慢演化，最后才可能成為舉世矚目的創(chuàng)造；另外很多技術(shù)的進化過程中，都是工程與算法科學(xué)相互交織，Linux上的硬件加速API的進化流程也遵循了這一點。最初的Linux Video API被稱為Xv，基本只能借助硬件加速實現(xiàn)Scaling與Color Space Conversion兩個功能，明顯無法滿足行業(yè)需求；隨后經(jīng)過擴展，使得在那個MPEG-2稱霸的時代實現(xiàn)了對MPEG-2 Decoding硬件加速API的支持, 也就是Xv/XvMC，不過這一部分在當(dāng)時還停留在比較初級的階段，iDCT、XvMC-VLD等還未實現(xiàn)被API所標(biāo)準(zhǔn)化；隨后社區(qū)便開始嘗試實現(xiàn)Slice層加速API標(biāo)準(zhǔn)化，以避免之前包括不支持解碼所有階段硬件加速且依賴于X-Protocol協(xié)議等在內(nèi)的諸多問題，演化到現(xiàn)在，最終的結(jié)果就是VA-API。

4、VA-API

當(dāng)時的英特爾開始涉足硬件加速領(lǐng)域，于是在1999年左右英特爾提出VA-API接口。這是一套在Linux上的標(biāo)準(zhǔn)接口，從上層來看大家可以將其理解為一個OS層面的Video加速Spec，且與硬件無直接關(guān)聯(lián)。這套通用接口，同時需要特定的后端實現(xiàn)支持。與大多數(shù)開源項目相似，VA-API并沒有一個特別好的Document進行說明，需要自己仔細的去讀它的頭文件以了解其設(shè)計思想和細節(jié)。另外，既然這是一個Spec，其設(shè)計上自然想剝離與特定硬件的強關(guān)聯(lián)，所以雖然今天我的分享主要圍繞Intel GPU實踐進行，但實際上VA-API這套Spec并不只限于英特爾的GPU。

5、VA-API可用的后端驅(qū)動

VA-API可用的后端驅(qū)動非常多：Intel VA（i965）Driver是Intel OTC Team開發(fā)的一套全開源驅(qū)動，隨后也出現(xiàn)了Intel Hybird Driver、Intel iHD Driver等；在后端實現(xiàn)中還有Mesa‘S state-trackers包括Radeon、Nouveau、Freedreno等的支持，另外，還有些公司開發(fā)了一些API Bridge，包括Vdpau-va Bridge、Powervr-va的bridge以提供VA-API的支持，但這些bridge大部分由于種種原因慢慢轉(zhuǎn)為封閉而逐漸被廢棄；與此同時，英特爾的態(tài)度則更為開放，它希望大部分的開發(fā)者有能力在現(xiàn)有成熟平臺上進行更深層次的定制與探索，開放出更多的硬件能力以及驅(qū)動代碼，這也是英特爾作為一個開源大廠的風(fēng)范吧。

6、Intel GPU

Intel GPU從Gen 3的Pinetrail發(fā)展到Gen 9.5的Kabylake，每一代GPU的功能都在增強，在Media上的能力也在增強。關(guān)于GPU性能我們比較關(guān)注以下三部分指標(biāo)：第一部分是3D渲染能力，這一部分的標(biāo)準(zhǔn)化程度較好，可以使用標(biāo)準(zhǔn)接口包括OpenGL或Vulkan，當(dāng)然也有Windows上可與OpenGL與Vulkan適配的DirectX等；第二部分是Media；第三部分則為通用計算，其中包括NVIDIA的CUDA與AMD、ARM等公司采用的OpenLL。附帶說一句，有人會混淆GPU的通用計算能力與Media處理能力，以為通用計算能力很強，則Media能力就很強，這并不正確，實際使用中，需要把這三個指標(biāo)分開來根據(jù)具體的使用場景來分析與比較，以挑選最合適的硬件方案。

6.1 Intel GPU Media 硬件編程模型

從FFmpeg到具體的GPU，是如何進行一些Media處理的？首先FFmpeg會通過VA-API接口，調(diào)到對應(yīng)的Driver例如i965或iHD，之后數(shù)據(jù)經(jīng)過OS Scheduler進入OS KMD，接下來經(jīng)過一系列硬件編程抽象和GPU&CPU數(shù)據(jù)交換，生成Command streamer并傳輸給EU（也就是Intel GPU中的一個計算執(zhí)行單元）或者特定的IP以執(zhí)行相關(guān)的Media任務(wù)。注意，GPU的Media部分有時也會使用EU這些通用計算資源，而像Sampler、VDBOX、VEBOX、SFC等都是基于一些特定的Fix Function硬件實現(xiàn)相應(yīng)功能。所以，可以這樣理解，英特爾的GPU實際上是將媒體的大部分功能通過Fix Function方式實現(xiàn)，同時必要時候使用EU作為一個通用的計算資源這樣協(xié)同工作的。

6.2 FFmpeg & Intel GPU加速方案

大部分客戶偏向于使用FFmpeg的同時，也希望其具備出色的硬件加速能力，我們現(xiàn)在致力于在FFmpeg中集成Intel GPU諸多的媒體硬件加速能力，使用戶可通過FFmpeg的接口使能調(diào)用英特爾的GPU的各種能力從而帶來更多收益。這里的集成方式主要有兩種：1）直接實現(xiàn)為與FFmpeg融為一體的Native Decode/Encode。FFmpeg的大部分Decode如H.264、H.265、VP8、VP9等都使用Native Decoder的方式，2）Warpper第三方庫的，如在FFmpeg中集成Libx264的方式；現(xiàn)在部分Encode都以第三方庫的形式集成進FFmpeg的。根據(jù)上圖我們可以看到在Intel GPU中集成了兩個Plugin到FFmpeg中：第一個是QSV Plugin，其類似于libx265的做法，其Codec實現(xiàn)的底層與MediaSDK相關(guān)；但FFmpeg社區(qū)更傾向于基于libva/vaapi的方式，即直接在FFmpeg中進行集成，不warpper第三方的庫，一是因為此方案相對而言更加輕量，二是因為此方案更加開放；這樣做意味著將全部的硬件Codec部分的代碼都集成在FFmpeg中，與FFmpeg融為一體，如果客戶希望進行定制或改變，那么直接在FFmpeg內(nèi)部代碼中修改即可實現(xiàn)。除了解決基本的解碼/編碼硬件加速問題，我們也在考慮集成OpenCL、OpenCV等以適應(yīng)客戶的一些其他需求。

6.3 Intel GPU 支持

1）解碼支持

上圖展示的是Intel GPU Decode部分的的支持狀況。一般情況下我們可以將Decode分為8Bit與10Bit，以HEVC為例，有一些數(shù)據(jù)顯示10bit的壓縮率要高于8bit，感興趣的同學(xué)可以思考一下其原因。從表也可以看到，英特爾的各代GPU逐漸進化，從開始只支持MPEG-2、H.264、VC-1解碼的Sandy Bridge到增加了MJPEG解碼支持的Ivy Bridge再到多用于嵌入式平臺的Bay Trail乃至之后的Haswell，從Broadwell開始對VP8的支持與Cherry Trail/ Braswell對HEVC的支持再到Skylake之后的Apollo lake與 Kaby lake對VP9解碼與10bit HEVC&VP9的解碼支持，其解碼能力穩(wěn)步增加。

2）編碼支持

編碼方面，Intel GPU很早開始就支持了H.264編碼，到了Broadwell增加了對VP8的支持；而Skylake則增加HEVC和MJPEG，到了Kaby Lake時我們增加了對VP9和10Bit HEVC的編碼支持。關(guān)于VP9我想強調(diào)一點，據(jù)我所知，現(xiàn)在量產(chǎn)的SoC/GPU/CPU中可能只有英特爾的Kaby Lake及其后續(xù)的產(chǎn)品與三星的SoC支持VP9的編碼硬件加速。

6.4 使用案例

上圖展示的這些Use Cases可基本涵蓋大部分用戶的使用場景。解碼部分主要是使用hwaccel vaapi進行硬件解碼，由于一款設(shè)備上可能存在多款GPU，因此我們需要是hwaccel_device選擇不同的硬件設(shè)備。對比硬件編碼與硬件解碼我們不難發(fā)現(xiàn)，在解碼部分我們使用hwaccel_device而編碼部分則使用vaapi_device。這里的vaapi_device是一個Group Option，因為FFmpeg中存在Group Option與Per-Stream Option，解碼部分的hwaccel_device是Per-Stream Option，而編碼部分的vaapi_device是全局的并且Decoder和Encoder只需指定一次。從上面看來，轉(zhuǎn)碼的例子更為復(fù)雜，首先進行硬件解碼，而后在GPU中進行de-interlace與Scall和HEVC編碼，實際上整個過程是一個硬件解碼結(jié)合GPU中的Deinterlace/Scale和隨后的HEVC硬編的過程，這里需要注意一些關(guān)于碼控設(shè)定的問題，對此問題有興趣的同學(xué)可以直接閱讀FFmpeg的文檔或者代碼。

7、FFmpeg硬件加速全覽

上圖展示的是FFmpeg硬件加速全覽，我想這一部分對探索基于FFmpeg實現(xiàn)跨平臺的開發(fā)者來說非常有幫助。開發(fā)者經(jīng)常需要面對不同的硬件廠商：Intel、NVIDIA、AMD等等，他們希望僅僅與FFmpeg經(jīng)過一次集成，就可在不同硬件上實現(xiàn)同樣的功能。而現(xiàn)實情況，即是存在OS層面可以進行硬件優(yōu)化的API諸如Windows上的Dxva或MacOS上的VideotoolBox、Linux的Vaapi等，其實現(xiàn)可能還是非常分散，而FFmpeg在支持各種硬件加速接口之后，則幫助解決了上面的這個問題。另外，對于上表，Decoder部分只列舉了是否支持硬件surface的輸出。除此之外還有一些附加功能例如Filter，作為FFmpeg中非常重要的一部分，它主要是為了進行Video 后處理等；上表中的Hardware Context是指基于FFmpeg內(nèi)部的硬件加速接口的實現(xiàn)，Useable from FFmpeg CLI是指FFmpeg的命令行是否直接可用硬件加速（它的典型使用場景是，在Server端將FFmpeg直接作為工具使用，通過PHP在后端直接調(diào)用FFmpeg的Tools）。另外，如果開發(fā)者需要調(diào)用FFmpeg API進行解碼，此時需要關(guān)注Hwaccel的支持情況。最后我想強調(diào)一下圖中Decoder部分里的Internal和Standalone。它實際上是一個歷史遺產(chǎn)，在FFmpeg中，很早便實現(xiàn)了H.264的軟解碼，在此基礎(chǔ)上，如果想使能GPU的解碼能力則需要面臨以下兩個選擇：可以選擇重新實現(xiàn)有別于軟解碼的另一套基于GPU解碼實現(xiàn)，可以考慮為需要完整實現(xiàn)一個類似h264_vaapi的解碼其；也可將解碼相關(guān)的一些硬件加速工作直接Hook在已有的軟解碼Codec中，當(dāng)時的開發(fā)者選擇了后者，所以大部分基于OS的硬件加速解碼方案都基于后者的方案也就是Internal AVHWaccel；但諸如NVIDIA等提供NVDEC,NVENC的方案，因為自身已經(jīng)是一個完整的硬件解碼器，所以在FFmpeg內(nèi)只需實現(xiàn)成一個簡單的wrappe人即可，不需要借助FFmpe已有的軟解碼Codec的任何功能。

8、FFmpeg VA-API的細節(jié)信息

上圖展示的是FFmpeg VAAPI的一些細節(jié)信息，之前我已經(jīng)對HWAcceled的解碼與Native的解碼進行了說明。提及編碼，硬件加速的編碼帶來的最大好處是速度優(yōu)勢：我曾經(jīng)基于Skylake-U這樣雙核四線程的低電壓CPU上測試1080P的轉(zhuǎn)碼，基本可實現(xiàn)240FPS的實時轉(zhuǎn)碼；同時，在大規(guī)模部署時不能不考慮功耗比與性價比，也就是單路的編碼或轉(zhuǎn)碼需要消耗多少電能以及單路轉(zhuǎn)碼的成本。現(xiàn)在集成了GPU的英特爾PC處理器，其功耗在40～65w，如果是面向服務(wù)器工作站的Xeon E3系列，可在一個65w的處理器上實現(xiàn)14到18路的1080P轉(zhuǎn)碼，而能達到相同性能的NVIDIA GPU所需的能耗大約在300w左右。另外，對于硬件編碼，有一些客戶可能在圖像質(zhì)量上有更高的需求，現(xiàn)在英特爾的GPU在低碼率上處理效果還有提升空間，但在處理中高碼率文件時，其評測結(jié)果與X264相比并無明顯的差距。如果客戶期望借助自己的一些高階算法通過更深度的定制實現(xiàn)更強大的功能，Intel也開放了被稱為Flexible Encoder Interface （FEI）的底層接口。此接口可詳細全面展示Intel GPU的全部硬件編碼能力，并讓用戶擁有足夠的靈活度去Tunning各種算法；如果說FFmpeg代表的是一個可以直接調(diào)用的成熟平臺，那么FEI則是可定制Codec算法的通用接口。與此同時，F(xiàn)EI對客戶的能力要求也更高，如果有高階深層次定制化的編碼需求，可以考慮FEI。最后，附帶一句，我們同樣在AVFilter中集成了GPU的VPP以實現(xiàn)硬件加速的Scaling與Deinterlace等操作，后續(xù)也會支持Overlay、CSC等。

9、其他問題

9.1 CPU與GPU的數(shù)據(jù)交換

當(dāng)我們在處理一些異構(gòu)計算時，始終需要面對此問題：CPU與GPU、DSP之間的數(shù)據(jù)交換。數(shù)據(jù)從CPU拷貝到GPU與從GPU拷貝到CPU并不是一個對等關(guān)系，一般而言，數(shù)據(jù)從CPU到GPU進行拷貝的速度很快且不存在性能瓶頸；而如果是GPU到CPU的拷貝交換有可能面臨性能瓶頸，其原因是兩者使用了不同的緩存策略。如果我們通過mmap GPU的memory到CPU側(cè)，之后不進行任何優(yōu)化而是直接使用諸如memcpy函數(shù)將數(shù)據(jù)拷貝到CPU側(cè)，會發(fā)現(xiàn)性能可能不如預(yù)期。關(guān)于這個問題，英特爾也提供了一些優(yōu)化辦法，例如使用SSE4/AVX等指令集中提供的bypass Cache的特定指令，也就是所謂的Faster Copy背后的特定指令；另外，也可考慮直接用GPU進行拷貝而非使用CPU，或者考慮從OpenCL層面進行優(yōu)化。

9.2 FFmpeg中的硬件加速

FFmpeg提供了一些Filter用于實現(xiàn)硬件加速pipeline的建立，分別為Hwupload、Hwdownload、Hwmap、Hwunmap，使得在組成硬件的Pipeline時盡量避免大量的數(shù)據(jù)交換，所有操作盡量在GPU內(nèi)部直接完成以提升性能。

9.3 硬件或驅(qū)動不支持

如果完成了編解碼的部署，需要AVFilter相關(guān)的優(yōu)化但硬件或者驅(qū)動層面卻不支持，面對這種情況，我們可考慮OpenCL。因為OpenCL現(xiàn)在可與FFmpeg Video的編解碼進行Buffer Sharing，這相當(dāng)于是一個GPU內(nèi)部零拷貝的過程；只需要依靠Hwmap和Hwunmap實現(xiàn)的map就能直接用OpenCL對現(xiàn)有的AVFilter進行優(yōu)化，從而幫助開發(fā)者解決此類由于CPU/GPU的數(shù)據(jù)交換導(dǎo)致的性能問題，與此同時，把OpenCL作為對GPU通用計算的標(biāo)準(zhǔn)接口，來優(yōu)化我們的各種視頻或圖像的處理；另外，我們可以將此思路放得更寬一點，如果客戶不希望直接使用來OpenCL來手動優(yōu)化AVFilter，也可考慮把OpenCV作為一個已經(jīng)被OpenCL優(yōu)化好的算法集合再集成進FFmpeg中。我們現(xiàn)在也在考慮此類方式并在其上進行嘗試。

10、To Do List

上圖展示的是我們正在實踐與探索的技術(shù)點，期待通過以上優(yōu)化為音視頻行業(yè)帶來技術(shù)進步與行業(yè)發(fā)展。