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

2、何謂FFmpeg/VA-API？

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

3、Linux Video API

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

4、VA-API

當(dāng)時(shí)的英特爾開始涉足硬件加速領(lǐng)域，于是在1999年左右英特爾提出VA-API接口。這是一套在Linux上的標(biāo)準(zhǔn)接口，從上層來看大家可以將其理解為一個OS層面的Video加速Spec，且與硬件無直接關(guān)聯(lián)。這套通用接口，同時(shí)需要特定的后端實(shí)現(xiàn)支持。與大多數(shù)開源項(xiàng)目相似，VA-API并沒有一個特別好的Document進(jìn)行說明，需要自己仔細(xì)的去讀它的頭文件以了解其設(shè)計(jì)思想和細(xì)節(jié)。另外，既然這是一個Spec，其設(shè)計(jì)上自然想剝離與特定硬件的強(qiáng)關(guān)聯(lián)，所以雖然今天我的分享主要圍繞Intel GPU實(shí)踐進(jìn)行，但實(shí)際上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等；在后端實(shí)現(xiàn)中還有Mesa‘S state-trackers包括Radeon、Nouveau、Freedreno等的支持，另外，還有些公司開發(fā)了一些API Bridge，包括Vdpau-va Bridge、Powervr-va的bridge以提供VA-API的支持，但這些bridge大部分由于種種原因慢慢轉(zhuǎn)為封閉而逐漸被廢棄；與此同時(shí)，英特爾的態(tài)度則更為開放，它希望大部分的開發(fā)者有能力在現(xiàn)有成熟平臺上進(jìn)行更深層次的定制與探索，開放出更多的硬件能力以及驅(qū)動代碼，這也是英特爾作為一個開源大廠的風(fēng)范吧。

6、Intel GPU

Intel GPU從Gen 3的Pinetrail發(fā)展到Gen 9.5的Kabylake，每一代GPU的功能都在增強(qiáng)，在Media上的能力也在增強(qiáng)。關(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；第三部分則為通用計(jì)算，其中包括NVIDIA的CUDA與AMD、ARM等公司采用的OpenLL。附帶說一句，有人會混淆GPU的通用計(jì)算能力與Media處理能力，以為通用計(jì)算能力很強(qiáng)，則Media能力就很強(qiáng)，這并不正確，實(shí)際使用中，需要把這三個指標(biāo)分開來根據(jù)具體的使用場景來分析與比較，以挑選最合適的硬件方案。

6.1 Intel GPU Media 硬件編程模型

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

6.2 FFmpeg & Intel GPU加速方案

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

6.3 Intel GPU 支持

1）解碼支持

上圖展示的是Intel GPU Decode部分的的支持狀況。一般情況下我們可以將Decode分為8Bit與10Bit，以HEVC為例，有一些數(shù)據(jù)顯示10bit的壓縮率要高于8bit，感興趣的同學(xué)可以思考一下其原因。從表也可以看到，英特爾的各代GPU逐漸進(jìn)化，從開始只支持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時(shí)我們增加了對VP9和10Bit HEVC的編碼支持。關(guān)于VP9我想強(qiáng)調(diào)一點(diǎn)，據(jù)我所知，現(xiàn)在量產(chǎn)的SoC/GPU/CPU中可能只有英特爾的Kaby Lake及其后續(xù)的產(chǎn)品與三星的SoC支持VP9的編碼硬件加速。

6.4 使用案例

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

7、FFmpeg硬件加速全覽

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

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

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

9、其他問題

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

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

9.2 FFmpeg中的硬件加速

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

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

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

10、To Do List

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