介紹FFmpeg是什么？與關(guān)于FFmpeg的問(wèn)題回答介紹FFmpeg是什么？與關(guān)于FFmpeg的問(wèn)題回答介紹FFmpeg是什么？與關(guān)于FFmpeg的問(wèn)題回答介紹FFmpeg是什么？與關(guān)于FFmpeg的問(wèn)題回答
1、什么是FFmpeg
FFmpeg誕生于十幾年前，最初是作為一個(gè)MPlayer播放器的一個(gè)子項(xiàng)目出現(xiàn)。因?yàn)楫?dāng)時(shí)的播放器有需要支持各種各樣解碼的需求， 其中有一位Mplayer的開(kāi)發(fā)者看到了這樣的需求，于是編寫了FFmpeg。
它作為迄今為止最流行的一個(gè)開(kāi)源多媒體框架之一，F(xiàn)Fmpeg有兩種基本使用方式——作為庫(kù)或者作為工具，其中后者的使用場(chǎng)景更多，同時(shí)它也被稱為多媒體開(kāi)發(fā)的“瑞士軍刀”。FFmpeg庫(kù)中90%的代碼以上使用C，同時(shí)也有一些匯編語(yǔ)言上的優(yōu)化，還有一些基于GPU的優(yōu)化。對(duì)于匯編優(yōu)化而言，由于YASM對(duì)最新的CPU指令支持效果不好，F(xiàn)Fmpeg的匯編現(xiàn)在正在向NASM轉(zhuǎn)變。FFmpeg本身有一些基本的開(kāi)發(fā)策略，希望所有的Codec集成在內(nèi)部庫(kù)中隨時(shí)調(diào)用；當(dāng)然它也在必要時(shí)可以依賴一些外部第三方庫(kù)，例如像眾所周知的X.264。（X.264作為一個(gè)Encoder來(lái)說(shuō)已經(jīng)足夠優(yōu)秀，我們可以看到大部分的商業(yè)產(chǎn)品都以X.264為對(duì)標(biāo)，常會(huì)看到某某Codec宣稱比X.264好多少，似乎X.264已經(jīng)成為業(yè)內(nèi)一個(gè)基本對(duì)標(biāo)點(diǎn)）。FFmpeg同樣也是一個(gè)跨平臺(tái)的產(chǎn)品，主要的License是GNU GPLv2，或GNU LGPLv2.1+的，講到這里我想說(shuō)的是，希望大部分的使用者也能夠在項(xiàng)目通過(guò)聲明使用了FFmpeg這一點(diǎn)為開(kāi)源社區(qū)帶來(lái)正面的反饋。
1.1 FFmpeg的發(fā)展歷史
這里需要說(shuō)明的是FFmpeg與Libav之間的關(guān)系， 2011年FFmpeg社區(qū)中的一部分開(kāi)發(fā)者因?yàn)槟承┰蛎撾x了FFmpeg社區(qū)并創(chuàng)立了Libav社區(qū)，而后來(lái)使用Libav的大部分的發(fā)行版本又慢慢遷移回了FFmpeg。但是，直到現(xiàn)在仍有幾位脫離FFmpeg社區(qū)的主要開(kāi)發(fā)者堅(jiān)守在Libav，而大部分的開(kāi)發(fā)者與資源都重新遷回了FFmpeg社區(qū)?，F(xiàn)在FFmpeg的最新穩(wěn)定版本為2018年4月更新的v4.0.0，從v3.4.2 到最新的v4.0.0，其中最大的改進(jìn)之一便是硬件加速。
1.2使用場(chǎng)景
FFmpeg有很多使用場(chǎng)景，其中較為典型的有播放器、媒體編輯器、云轉(zhuǎn)碼等等。據(jù)我所知有上圖中左側(cè)的這些公司在以上場(chǎng)景中使用FFmpeg，而右側(cè)的公司則是將FFmpeg作為第三方Codec使用。
2、FFmpeg組件
關(guān)于FFmpeg組件，大家可以在網(wǎng)上查到使用FFmpeg的API編寫播放器的教程文章。FFmpeg組件中應(yīng)用最多的是FFmpeg，它被用于進(jìn)行轉(zhuǎn)碼，而FFprobe則被用于進(jìn)行碼流分析（這些都是基于命令行的工具）；而FFserver的代碼庫(kù)已經(jīng)被刪除，其最主要的原因是FFmpeg Server的維護(hù)狀態(tài)并不好，出現(xiàn)很多問(wèn)題。最近社區(qū)又有人在重寫FFmpeg Server，估計(jì)不久之后代碼庫(kù)會(huì)得以恢復(fù)。但這時(shí)的FFserver的實(shí)現(xiàn)方式跟之前已經(jīng)基本沒(méi)什么關(guān)系了。在上圖中我們可以看到其中的Libavdevice主要使用硬件Capture或者進(jìn)行SDI （流化），Libavformat是一些常見(jiàn)容器格式例如Mux或Demux等。我個(gè)人的大部分工作是在Libavcodec與Libavfilter，在Libavcodec上進(jìn)行一些基于英特爾平臺(tái)的優(yōu)化，而Libavfilter主要是針對(duì)圖像的后處理。我認(rèn)為在AI盛行的時(shí)代Libavfilter會(huì)出現(xiàn)非常大的改動(dòng)，加入更多新功能而非僅僅基于傳統(tǒng)信號(hào)處理方式的圖像處理。最近實(shí)際上已經(jīng)有人嘗試在其中集成Super Resolution，但在性能優(yōu)化上仍有待改進(jìn)，預(yù)計(jì)還需要持續(xù)一段時(shí)間才能真正做到實(shí)時(shí)與離線。除去作為基礎(chǔ)組件的Libavutil，其他像Libavresample、Libswresample、Libpostproc這幾個(gè)庫(kù)現(xiàn)在都有逐漸被廢棄的趨勢(shì)。
2.1 基本介紹
為什么FFmpeg會(huì)有那么高的使用量？ FFmpeg和Gstreamer究竟是什么關(guān)系？我也在反復(fù)思考這些問(wèn)題，為什么我會(huì)用FFmpeg而不用Gstreamer？將這個(gè)問(wèn)題引申來(lái)看可能會(huì)考慮：FFmpeg適合做哪些？不適合做哪些？我想人們熱衷于使用FFmpeg的原因之一是FFmpeg的API非常簡(jiǎn)潔。上圖是一個(gè)范例，我們可以看到只需五步就可寫出一個(gè)基本的Decoder。這個(gè)例子非常容易理解，如果能將這個(gè)例子從API到底層逐步研習(xí)其細(xì)節(jié)便可對(duì)FFmpeg有更深層的認(rèn)識(shí)。
2.1.1 Libavformat
Libavformat的主要任務(wù)是Demuxer/Muxer功能。我們可以看到FFmpeg的框架設(shè)計(jì)得十分精煉，基本上如果需要實(shí)現(xiàn)一個(gè)AVFormat或AVCodec以對(duì)應(yīng)新的Format/Codec；所以即使一位開(kāi)發(fā)者不了解FFmpeg框架也可以編寫一個(gè)簡(jiǎn)單的Format或Codec，需要做的最主要是實(shí)現(xiàn)對(duì)應(yīng)的AVFormat/AVCodec。
2.1.2 Libavcodec
需要提及一下的，有兩種方案實(shí)現(xiàn)對(duì)應(yīng)的Libavcodec，一種是以Native方式實(shí)現(xiàn)在FFmpeg內(nèi)部，另一種是利用集成的第三方庫(kù)，我們現(xiàn)在看到的一些Encoder相關(guān)的是以集成的第三方庫(kù)為基礎(chǔ)。而對(duì)于Decoder ，F(xiàn)Fmpeg社區(qū)的開(kāi)發(fā)者做得非?？臁Ｄ腿藢の兜氖?，據(jù)說(shuō)FFmpeg內(nèi)部VP9 的Decoder速度比Google Libvpx Decoder還要快，我們知道Google是VP9 Codec的創(chuàng)立者，但是Google的表現(xiàn)還不如FFmpeg自身的VP9 的Decoder 。
2.1.3 Libavfilter
Libavfilter是FFmpeg內(nèi)部最復(fù)雜的部分之一，其代碼一直在反復(fù)重構(gòu)。Libavfilter的思想可能借鑒了Windows 的DirectX上一些思想，但代碼卻有些復(fù)雜。其構(gòu)成并非像圖片展示的那樣是一個(gè)簡(jiǎn)單的串行關(guān)系，實(shí)際上它可以構(gòu)成一個(gè)有向無(wú)環(huán)圖，這意味著只要能夠構(gòu)成一個(gè)DAG這個(gè)LibavFilter就能工作。但是Libavfilter的綜合表現(xiàn)并不是特別好，我一直在想嘗試對(duì)其進(jìn)行改進(jìn)，但因?yàn)檫@一部分的復(fù)雜度比較高，總是令我感覺(jué)不入其門。
2.1.4 FFmpeg Transcoding
FFmpeg的應(yīng)用場(chǎng)景之一是Transcoding轉(zhuǎn)碼，涉及Demux/Decoder/Encoder/Muxer,同時(shí)我們可以把Demux+Mux的流程看作是它的一個(gè)特例。另一應(yīng)用場(chǎng)景是作為Player播放器，上圖展示了Transcoding與Player兩種應(yīng)用場(chǎng)景的流程。
3、FFmpeg開(kāi)發(fā)
FFmpeg中比較重要的API包括如何進(jìn)行Decoder、Postprocess、Encoder等。如果你對(duì)此感興趣，我認(rèn)為最好的辦法是去認(rèn)真看一看FFmpeg里一些很好的例子。最近兩年FFmpeg把過(guò)去的API進(jìn)行了重構(gòu)，如果我以原來(lái)的FFmpeg API為基礎(chǔ)進(jìn)行解碼，其做法是輸入一個(gè)已經(jīng)壓縮過(guò)的Frame數(shù)據(jù)并希望得到一個(gè)解碼的Frame，但實(shí)際上此過(guò)程存在的限制是需要確保輸入的Frame與解碼出的數(shù)據(jù)一一對(duì)應(yīng)。后來(lái)隨著開(kāi)發(fā)的深入，特別是H.264提供的MVC這種模式以后，有時(shí)我們輸入一個(gè)Frame后需要分左右解碼兩個(gè)幀，此時(shí)它的API便無(wú)法支持這種場(chǎng)景。因此最近FFmpeg的API被從輸入一個(gè)Frame輸出一個(gè)Packet修改為兩個(gè)API，這樣便可解除它們之間的耦合。當(dāng)然由于輸入與解碼變成了兩個(gè)分離的步驟，導(dǎo)致代碼中需要大量的While循環(huán)來(lái)判斷此解碼過(guò)程是否結(jié)束。
4、硬件加速
我在英特爾負(fù)責(zé)FFmpeg硬件加速的工作，因此更關(guān)注FFmpeg的硬件加速在英特爾GPU上的表現(xiàn)。我們一直在考慮如何更快地將英特爾的硬件加速方案推薦給客戶使用，讓用戶能夠有機(jī)會(huì)體驗(yàn)到硬件加速的強(qiáng)大功能。現(xiàn)在英特爾提出的兩種通過(guò)FFmpeg驅(qū)動(dòng)GPU的硬件加速方案，其中一種方案基于MediaSDK，我想如果你用過(guò)英特爾的GPU便應(yīng)該會(huì)對(duì)其有所了解，已經(jīng)有很多客戶基于MediaSDk進(jìn)行了部署，其中，MediaSDK的VPP部分作為AVFilter也在FFmpeg內(nèi)部；另一種更為直接的方案是VA-API，VA-API類似于Windows上提供的DXV2或是MacOS上提供的Video Toolbox等基于OS層面的底層硬件加速API，我現(xiàn)在的大部分的工作專注于此領(lǐng)域。FFmpeg同樣集成了OpenC++L的一些加速，它使得你可以借助GPU進(jìn)行轉(zhuǎn)碼工作并在整套流程中不涉及GPU與CPU的數(shù)據(jù)交換，這個(gè)方案方案會(huì)帶來(lái)明顯的性能提升。我們雖希望從解碼到VPP再到編碼的整條流程都可以在GPU內(nèi)完成，但GPU的一些功能上的缺失需要其他硬件加速功能來(lái)彌補(bǔ)，此時(shí)就可考慮使用OpenCL優(yōu)化。其次是因?yàn)镺penCV已經(jīng)進(jìn)行了大量的OpenCL加速，所以當(dāng)面對(duì)這種圖像后處理的硬件加速需求時(shí)可以考慮把OpenCV集成到FFmpeg中，但在OpenCV發(fā)展到v3.0后其API從C切換到了C++，而FFmpeg自身對(duì)C++的API支持并不友好，這也導(dǎo)致了FFmpeg的官方版本中只支持OpenCV到v2.4。如果你對(duì)此感興趣，可以嘗試基于在OpenCV v3.0以上的版本做一個(gè)新的C Warper，再考慮集成進(jìn)FFmpeg。但如果你對(duì)性能要求足夠高，直接使用VA-API和OpenCL去做優(yōu)化，保證整個(gè)流程能夠在GPU內(nèi)部完整運(yùn)行，達(dá)到最好的性能表現(xiàn)。
上圖是對(duì)GFFmpeg硬件加速的流程概覽圖，大部分人可能對(duì)英特爾的兩套方案有比較清晰的認(rèn)識(shí)，最關(guān)鍵的點(diǎn)在于QSV方案依賴于MediaSDK，而VA-API則可以理解為將整個(gè)MediaSDK做的工作完整的放進(jìn)了FFmpeg的內(nèi)部，與FFmpeg融為一體，F(xiàn)Fmpeg開(kāi)發(fā)者與社區(qū)更推薦后者?，F(xiàn)在的OCL方案最近也正不停的在有一些Patch進(jìn)來(lái)，這里主要是對(duì)AVFilter的處理的過(guò)程進(jìn)行硬件加速。需要說(shuō)明一下，因?yàn)樯鐓^(qū)曾經(jīng)有嘗試用OpenCL加速X.264使其成為一個(gè)更快的Codec，但結(jié)果并不是特別好。所以用OpenCL去硬件加速Encoder，其整體性能提升并不是特別明顯。
上圖展示了更多細(xì)節(jié)，我們可以看到每種方案支持的Codec與VPP的功能與對(duì)應(yīng)的Decoder和Encoder。
這兩種方案的差異在于實(shí)際上是QSV Call第三方的Library，而VA-API直接基于VA-API 的Interface，使用FFmpeg的Native 實(shí)現(xiàn)而并不依賴任何第三方外部庫(kù)。
VA-API
經(jīng)常會(huì)有人提出疑問(wèn)：VA-API是什么？它的本質(zhì)類似于Microsoft在Windows上提出的DXVA2，也就是希望用一套抽象的接口去隱藏底層硬件細(xì)節(jié)，同時(shí)又暴露底層硬件的基本能力。VA-API有多個(gè)可用后端驅(qū)動(dòng)，最常見(jiàn)的是原先英特爾OTC提供的VA （i965）的驅(qū)動(dòng)，現(xiàn)如今在Linux發(fā)行版本中也存在；而Hybird驅(qū)動(dòng)則更多被用于當(dāng)硬件的一些功能還沒(méi)有準(zhǔn)備好的情景，需要先開(kāi)發(fā)一個(gè)仿真驅(qū)動(dòng)；等硬件部分準(zhǔn)備完成后再使正式驅(qū)動(dòng)。第三個(gè)是iHD/Media driver，這部分驅(qū)動(dòng)在去年年底時(shí)Intel便已經(jīng)開(kāi)源，這一套驅(qū)動(dòng)對(duì)比i965驅(qū)動(dòng)其圖像質(zhì)量和性能表現(xiàn)更優(yōu)但穩(wěn)定性較差?，F(xiàn)在我一直在此領(lǐng)域工作，希望它能夠更好地支持FFmpeg。Mesa’s State-Trackers主要支持AMD的GPU，但是由于現(xiàn)在只有Decoder而Encoder處在試驗(yàn)階段一直未開(kāi)放，所以AMD的GPU在FFmpeg上無(wú)法進(jìn)行Encoder加速。
上圖是VA-API的一些基本概念，在這里我就不做過(guò)多闡述。
這是基于VA-API 一個(gè)基本流程。FFmpeg的VA-API也是基于此流程做的。
開(kāi)放問(wèn)題
FFmpeg的QSV硬件加速方案究竟有什么優(yōu)缺點(diǎn)？如果將 FFmpeg與GStreamer比較，什么情況下選擇FFmmpeg什么情況下選擇GStreamer，這是我一直在反反復(fù)復(fù)考慮的內(nèi)容，還有FFmpeg與OpenMAX的差別這些（Android使用了OpenMAX）。對(duì)于未來(lái)趨勢(shì)，我們期待基于FFmpeg與英特爾的GPU構(gòu)建一個(gè)全開(kāi)源的解決方案，將整個(gè)開(kāi)發(fā)流程透明化；在之后我們也考慮OpenCL的加速 ，順帶說(shuō)一句，作為OpenCL最初的支持者的Apple，在不久前的WWDC上稱要放棄OpenCL，不過(guò)從現(xiàn)實(shí)來(lái)看，如果想在GPU或異構(gòu)上進(jìn)行硬件加速開(kāi)發(fā)，OpenCL仍然是最優(yōu)的選擇。其他方案直到現(xiàn)在還沒(méi)有OpenCL的廣泛適應(yīng)度。實(shí)際上OpenCL本身的推出并不是特別的成功，在OpenCL過(guò)去的十年發(fā)展中并沒(méi)有出現(xiàn)殺手級(jí)應(yīng)用；另一個(gè)趨勢(shì)是，Vulkan作為OpenGL的后繼者開(kāi)始流行，因此業(yè)界也在考慮直接把OpenCL作為Vulkan部分合并在一起。另外，OpenCV有大量的OpenCL優(yōu)化，如果你不愿意重寫OpenCL的優(yōu)化，可以考慮用FFmpeg與 OpenCV一起加速來(lái)構(gòu)建整個(gè)流程。
上圖展示了你所見(jiàn)的基于各個(gè)OS與硬件廠商的硬件加速狀態(tài)。大部分專注于硬件加速的開(kāi)發(fā)者更關(guān)心播放器的表現(xiàn)，在Windows上進(jìn)行硬件編碼的需求并不強(qiáng)。
Q&A
Q1：FFmpeg Server最近的一些大改動(dòng)是什么？
A：FFmpeg Server的代碼在最新版本的FFmpeg里已經(jīng)不存在了，主要是由于維護(hù)者并不積極?，F(xiàn)在又有開(kāi)發(fā)者正在重寫FFmpeg Server并且已經(jīng)Review到第三輪，我相信最快需要一兩個(gè)月它又會(huì)回到FFmpeg里面，但和以前的FFmpeg Server完全不一樣。
Q2：FFmpeg 4.0已經(jīng)有VA-API的方案嗎？
A：VA-API的Encoder從3.3.1開(kāi)始支持，這部分的代碼從2016年到2018年一直在進(jìn)行重構(gòu)，在4.0.0時(shí)VA-API的Encoder都可以支持。屆時(shí)是一個(gè)開(kāi)箱即用的狀態(tài)。
Q3：安卓平臺(tái)現(xiàn)在可以硬件加速嗎？
A：VA-API的方案是英特爾的，由于英特爾的產(chǎn)品生態(tài)緣故，安卓的解決方案是基于MediaCodec而非VA-API，其硬件加速就目前而言只有解碼加速?zèng)]有編碼加速。
Q4：后臺(tái)的多任務(wù)轉(zhuǎn)碼服務(wù)器需要用硬件來(lái)編碼，那么可以同時(shí)進(jìn)行多少任務(wù)？如果根據(jù)硬件的核心數(shù)量來(lái)決定，那么超過(guò)性能極限是否會(huì)導(dǎo)致創(chuàng)建編碼器失?。?/p>
A：如果是基于CPU的編碼方案，那么編碼的性能與CPU的線程數(shù)有關(guān)，而FFmpeg性能并未和CPU的核心數(shù)量構(gòu)成一個(gè)線性關(guān)系；如果是基于GPU的編碼方案，包括1對(duì)n的轉(zhuǎn)碼，這需要以官方測(cè)試為準(zhǔn)。英特爾在官方網(wǎng)站的GPU參數(shù)有相關(guān)數(shù)據(jù)，這與硬件平臺(tái)有非常大的關(guān)系，具有強(qiáng)大性能的硬件平臺(tái)可以保證良好的編解碼運(yùn)算處理能力。
Q5：還有一個(gè)跟WebRTC相關(guān)的問(wèn)題，他說(shuō)這個(gè)在WebRTC 在Chrome里FFmpeg實(shí)現(xiàn)硬件加速有哪些，可以替換其他版本的FFmpeg嗎？
A：據(jù)我所知在ChromeOS中只有當(dāng)自身API硬件加速不工作的情況下才會(huì)使用FFmpeg，Chrome可以說(shuō)是把FFmpeg作為一個(gè)備選方案，并沒(méi)有直接用作硬件加速。
Q6：英特爾 Collabration 的客戶端SDK,支持喂數(shù)據(jù)給WebRTC的，這里硬件編碼是用的WebRTC內(nèi)部，還是自己替換的？
A：英特爾 Collabration的客戶端我不知道這個(gè)事情，在Server端采用了三套方案，一套方案是MediaSDK進(jìn)行硬件加速，第二套方案是VPX以支持VP8，VP9 ，其他還有支持另外格式的方案。我無(wú)法準(zhǔn)確推斷是否會(huì)用FFmpeg進(jìn)行硬件加速與軟件解碼，之前與內(nèi)部有過(guò)相關(guān)的的交流，但最終沒(méi)有決定。
Q7：還有個(gè)問(wèn)題，F(xiàn)Fmpeg有哪些Filter是使用了硬件加速，有沒(méi)有這方面的加速計(jì)劃？
A：現(xiàn)在是有這個(gè)計(jì)劃，以下圖片可以說(shuō)明
現(xiàn)在已經(jīng)有一些基本的硬件加速，主要是一些ColorSpace的轉(zhuǎn)換，有一些Scaling，再就是 Deinterlace，F(xiàn)RC現(xiàn)在考慮OpenCL去做，因?yàn)?iHD driver這塊支持應(yīng)當(dāng)沒(méi)有了。預(yù)計(jì)更多的OpenCL會(huì)進(jìn)行加速，我們希望Decoder + Filter + Encoder的整個(gè)過(guò)程都在GPU內(nèi)部運(yùn)算完成從而減少CPU的性能損耗，同時(shí)也希望OpenCL具有一定的靈活度。
Q8：VA-API在Linux下支持哪些型號(hào)CPU？
A：這與驅(qū)動(dòng)有關(guān)，總體來(lái)說(shuō)i965支持更多的處理器，iHD支持英特爾Skylake架構(gòu)以后的處理器
Q9：如何提升硬件編解碼的質(zhì)量？
A：這是硬件編解碼方面的老大難問(wèn)題，每一個(gè)做硬件編解碼的人都會(huì)提出類似的問(wèn)題。因特爾曾提出了一個(gè)被稱為FEI的解決方案，其原理是僅提供GPU中與硬件加速相關(guān)的最基本功能，而像圖像質(zhì)量等方面的提升則基于搜索算法等非硬件加速功能。這就使得可以讓用戶考慮使用自己的算法，而與計(jì)算量相關(guān)的問(wèn)題則交給GPU處理，但此方案并未出現(xiàn)一個(gè)特別成熟的應(yīng)用。
Q10：基于CPU、GPU設(shè)置FFmpeg線程數(shù)，線程數(shù)和核心數(shù)有什么對(duì)應(yīng)關(guān)系？
A：其實(shí)對(duì)GPU而言處理速度已經(jīng)足夠快，運(yùn)行多進(jìn)程的轉(zhuǎn)碼對(duì)GPU而言基本沒(méi)有什么影響。根據(jù)實(shí)測(cè)來(lái)看，例如運(yùn)行4進(jìn)程的轉(zhuǎn)碼，對(duì)CPU和GPU的消耗沒(méi)有特別大的區(qū)別。但在這種情況下如果是用GPU進(jìn)行，我的建議是用進(jìn)程會(huì)更好管理。其次是FFmpeg自身1對(duì)n的特性使得在價(jià)格上比較敏感，這也是我們一直致力改進(jìn)的重點(diǎn)。相信改進(jìn)之后會(huì)為1對(duì)n轉(zhuǎn)碼帶來(lái)一個(gè)比較大的提升，但就目前而言仍處于內(nèi)部設(shè)計(jì)的初級(jí)階段。
聯(lián)系客服
