大家好，我是騰訊云的趙軍，同時(shí)我也是FFmpeg決策委員會(huì )委員、開(kāi)源愛(ài)好者。在2018年成為FFmpeg maintainer，2019年入選 FFmpeg 決策委員會(huì )（voting committee），具備豐富的基于Linux 的Router/Gateway 開(kāi)發(fā)經(jīng)驗，并持續關(guān)注Linux 在網(wǎng)絡(luò )方面發(fā)展。曾開(kāi)發(fā)基于Linux 的高清/ 標清H.264/MPEG2視頻解碼器及圖像處理平臺。曾在Intel DCG/NPG 負責基于FFmpeg以及Intel平臺上的視頻編碼/解碼/轉碼、視頻后處理、視頻分析的硬件加速的工作。目前在騰訊云負責視頻云的系統優(yōu)化相關(guān)工作，除去支持公司內部的項目開(kāi)發(fā)以外，也在持續向FFmpeg社區提交patch，同時(shí)也倡導引領(lǐng)同事以開(kāi)放的心態(tài)擁抱開(kāi)源。

　　今天的演講將分為明眸、智眸、云剪和開(kāi)源四個(gè)部分來(lái)講解，其中明眸主要針對音視頻編解碼與畫(huà)質(zhì)增強方案，智眸主要涉及智能媒體檢索、分析和審核方案，云剪主要提供在線(xiàn)媒體內容生產(chǎn)方案，而開(kāi)源則是本次演講中將重點(diǎn)介紹的內容。

　　在騰訊云團隊看來(lái)，目前音視頻技術(shù)的發(fā)展現狀更偏向于清晰、流暢和品質(zhì)這三者的博弈，對于視頻來(lái)說(shuō)，體育賽事、游戲等領(lǐng)域對直播清晰度要求不斷提升，國家政策也在鼓勵4K和8K的增長(cháng)，這些因素使得超高清晰度視頻內容成為音視頻技術(shù)發(fā)展的重要方向，與此同時(shí)，人們開(kāi)始追求更多的趣味性和附加能力，但硬件計算能力或者軟件性能并沒(méi)完全跟上，這使得成像品質(zhì)以及其他附屬能力所需要的計算能力也位于了問(wèn)題之列；一如既往的，無(wú)論是4G還是即將到來(lái)的5G時(shí)代，網(wǎng)絡(luò )的制約在能預計的時(shí)間內，依然也還是一個(gè)不可忽視的影響因素之一。

　　1. 音視頻技術(shù)+AI，打造從內容生產(chǎn)、極速高清到視頻識別分析全鏈路產(chǎn)品

　　提到極速高清就不得不聊聊視頻編碼，上圖從Codec和系統工具的角度，以MPEG組織為基準描述了發(fā)展歷史，圖片下方是容器格式，做過(guò)工程的人都了解，很多時(shí)候相比Codec，容器格式有時(shí)會(huì )暴露很多的工程問(wèn)題。圖中色塊分別代表不同階段的技術(shù)發(fā)展，紅色部分已經(jīng)是歷史，橙色部分表示過(guò)渡，藍色部分更像是現在和不遠的將來(lái)的交界。

　　明眸主體由場(chǎng)景識別、前置處理和編碼算法動(dòng)態(tài)優(yōu)化三部分組成，場(chǎng)景識別主要是對場(chǎng)景進(jìn)行切分，根據場(chǎng)景預設編碼模板。其次前置處理主要解決的問(wèn)題是多次轉碼帶來(lái)的副作用，最后在基于以上兩部分的前提下做編碼算法的動(dòng)態(tài)優(yōu)化。

　　當場(chǎng)景識別、前置處理和編碼算法動(dòng)態(tài)優(yōu)化三部分做完之后，我們可以得到一些基本的結論，由于直播客戶(hù)更在意主觀(guān)質(zhì)量，明眸以VMAF為目標做開(kāi)發(fā)。簡(jiǎn)單提及一下，騰訊云在對VMAF和PSNR做比較時(shí)發(fā)現，如果VMAF的分數在70分左右甚至更高，VMAF的分數會(huì )與PSNR正相關(guān)，倍數關(guān)系大概在2.5-3倍之間，反之，我們也發(fā)現，PSNR分數比較高時(shí)，VMAF的分數不一定高，所以我們認為，以VMAF為目標的優(yōu)化也大概率的涵蓋了PSNR的目標值。明眸可以在相同碼率下將VMAF評分提升10+，同VMAF分下碼率節省可以達到30%左右。當然VMAF也存在一些問(wèn)題，比如對小分辨率的適配并不是很好，這可能與Netflix自身由點(diǎn)播內容居多，并且片源的質(zhì)量都非常高有關(guān)。

　　從上圖可以看到目前視頻AI比較通用的流程，視頻源從左向右邊，解碼之后如果要做對象探測會(huì )有一個(gè)Scale和CSC，如果做Tracking會(huì )向下走，如果做ROI coordinates會(huì )向上進(jìn)行正常的解碼。這個(gè)流程圖看似簡(jiǎn)單，但在工程中需要各種各樣的考量，其中的每一個(gè)點(diǎn)都可能會(huì )成為潛在的性能瓶頸。

　　以上是智眸的一些基本能力，包括人像、聲音/文字、圖像以及基本物體的識別、智能分析和審核，它可以根據需求靈活組合，圖中也列出了很多的應用場(chǎng)景。

　　在客戶(hù)使用和對接時(shí)，基本上是以Rest API做對接，圖中清晰展示了整個(gè)流程運行起來(lái)的全貌。

　　以上是騰訊云在視頻識別和視頻分析中要解決的問(wèn)題，其中智能拆條需要根據內容或關(guān)鍵人物出現進(jìn)行拆分，智能集錦應用在體育場(chǎng)景中較多，比如制作進(jìn)球或得分集錦。

　　如果將視頻當作一條鏈路來(lái)考慮，可以看到視頻從最初上傳到制作處理，再到內容管理、傳輸分發(fā)，最后在終端播放，其中制作與處理部分騰訊云存在一些技術(shù)缺失，因此騰訊云做了云剪來(lái)彌補這部分的功能，主要目的是讓用戶(hù)實(shí)現在云端不需要SDK就可以對視頻數據做處理，這種場(chǎng)景中比較具有代表性的是電競行業(yè)，它的素材可能在PC端已經(jīng)做好，不用在移動(dòng)端進(jìn)行處理。

　　云剪目前也是一個(gè)把騰訊云已有的能力打包，用以解決行業(yè)痛點(diǎn)的一個(gè)綜合性質(zhì)的產(chǎn)品。

　　2. 擁抱開(kāi)源，以開(kāi)放的心態(tài)加速技術(shù)升級

　　從事多媒體行業(yè)，基本沒(méi)有人可以完全忽視 FFmpeg這個(gè)開(kāi)源界中最流行的多媒體庫，FFmpeg庫有著(zhù)多平臺的支持，無(wú)論是服務(wù)器Linux、移動(dòng)端Android、PC 端的MAC以及Windows都可以使用，使用方式分為tools和C libraries兩種，tools包括ffmpeg、ffplay、ffprobe等，另一種方式則是C libraries，但C libraries場(chǎng)景時(shí)候，我們也發(fā)現它在某些場(chǎng)景下缺乏一定的靈活性。

　　在剛進(jìn)騰訊云時(shí)，大的部門(mén)中有38個(gè)repo都叫FFmpeg，這可能也是業(yè)務(wù)快速發(fā)展過(guò)程中所經(jīng)歷的一些痛處。我們開(kāi)始嘗試做一個(gè)統一版本，嘗試將部門(mén)將不同repo中，比較有價(jià)值的部分提煉出來(lái)，構造一個(gè)內部完整而統一的Repo；另一方面，我們認為，既然使用的FFmpeg來(lái)自開(kāi)源，我們在它上面的工作成果，也應該讓它最終返回到開(kāi)源社區去。這樣，一方面可以使得原來(lái)內部的FFmpeg庫統一，減少內部的重復性工作，另一方面對于社區來(lái)說(shuō)騰訊云及時(shí)將Feature、Bug Fix、性能優(yōu)化、文檔更新和samples反饋給它，在這個(gè)過(guò)程中，也順勢打造了一個(gè)非常完整流暢的工作流程，用于支持內部的開(kāi)發(fā)，也用于反饋給開(kāi)源社區。

　　提及接口和框架的問(wèn)題，首先想到的是上面這段話(huà)，簡(jiǎn)單說(shuō)來(lái)，猶如為院子造墻，什么放在墻外，什么放在墻內，門(mén)開(kāi)在什么地方，還要提防想著(zhù)把墻推倒的人；在實(shí)際的項目中，也有類(lèi)似的問(wèn)題，如果項目要和別人合作，首先需要明確兩人的職責，這是最容易出問(wèn)題的部分；具體到FFmpeg，一方面，它需要解決怎么屏蔽不同的Os、硬件平臺和Codec細節，并保持使用過(guò)程中能靈活構建media pipeline的能力，與此同時(shí)，在A(yíng)I大潮中，它也面臨著(zhù)是否需要集成Deep Learning框架到AVFilter模塊的這種現實(shí)問(wèn)題。

　　性能在多媒體技術(shù)中一直是一個(gè)永恒的話(huà)題，例如壓縮技術(shù)在十年間可以提升50%的壓縮率，但復雜度卻會(huì )提升10倍以上，這對計算能力提出了一個(gè)非常大的挑戰。我們知道，所有優(yōu)化的前提是理解算法與數據流向，并且有Profiling的數據作為支撐，除了算法上面的提升以外，也需要更好更充分的利用已有的硬件資源。大部分情況下，硬件性能優(yōu)化是在CPU和GPU上完成。以FFmpeg為例，它的CPU優(yōu)化在上體現在多線(xiàn)程和SIMD優(yōu)化兩個(gè)方面，在解碼過(guò)程中使用了基于Frame和Slice的線(xiàn)程以及更為底層的SIMD優(yōu)化，在Filter中只用了基于Slice的線(xiàn)程與SIMD。GPU一般來(lái)說(shuō)有二個(gè)優(yōu)化方向，一個(gè)是專(zhuān)有硬件，比如Intel GPU中的QSV部分，一塊是通用計算加速和3D渲染，分別是CUDA，以及嘗試和CUDA對抗的OpenCL，還有歷史悠久的OpenGL以及它的繼任者Vulkan。

　　CPU的加速中，首先想到的是線(xiàn)程，本質(zhì)上說(shuō)，使用線(xiàn)程能力優(yōu)化是想充分釋放多核的能力，目前對于大部分的PC來(lái)說(shuō)以4線(xiàn)程或8線(xiàn)程居多，但對于Sever來(lái)說(shuō)核數可能會(huì )更多，目前的環(huán)境多以48或96線(xiàn)程為主，因此在不互相影響的前提下調動(dòng)多核的積極性是CPU加速所要解決的首要問(wèn)題。在FFmpeg中，以AVFilter為例，他有一個(gè)AVFILTER_FLAG_SLICE_THREADS的標識，很多實(shí)現上，是把一個(gè)Frame中不相關(guān)的數據以行或者列的方式做加速，以我的經(jīng)驗來(lái)看，如果程序出現性能問(wèn)題，首先應該考慮的問(wèn)題是是否使用了CPU的多線(xiàn)程能力。第二種CPU加速方式是SIMD加速，SIMD匯編優(yōu)化形式一般有intrinsics、inline assembly、hand-written assembly三種，FFmpeg匯編優(yōu)化以第三種為主，這是由于intrinsics在封裝是有些潛在的性能損失，相同的功能用intrinsics和hand-written assembly去解決，前者可能會(huì )引入一些性能損失；而inline assembly的問(wèn)題在于比較難以跨平臺，比如Linux和Windows，而FFmpeg的跨平臺是它的目標之一。所以，現在FFmpeg社區更偏向于hand-written assembly方式，另外，大部分的hand-written assembly匯編優(yōu)化其實(shí)是以x264的匯編優(yōu)化庫為基礎做的，并且選擇nasm為匯編器（不選擇yasm是由于它沒(méi)有支持最新的一些CPU指令）。

　　提及了多線(xiàn)程優(yōu)化，我們也以使用者的角度看著(zhù)，使用FFmpeg API的時(shí)候，如何設置線(xiàn)程。對于FFmpeg來(lái)說(shuō)，大部分的情況下可能并未考慮在高負載/重耦合場(chǎng)景下運行的情況，FFmpeg在解碼時(shí)的默認策略是根據CPU的核數創(chuàng )建線(xiàn)程，目前大部分的PC設備都是四核八線(xiàn)程的配置，但一個(gè)典型的數據中心的Server有48核96線(xiàn)程，但解碼器實(shí)際上并沒(méi)法同時(shí)使用這么多的核，這種情況下，需要自己控制解碼線(xiàn)程，而非使用FFmpeg的默認策略，我們也遇到過(guò)使用FFmpeg API時(shí)候，默認創(chuàng )建超過(guò)1200個(gè)線(xiàn)程的問(wèn)題。第三個(gè)是BUG的問(wèn)題，FFmpeg集成時(shí)很多時(shí)候只在PC端測試過(guò)，并未在擁有這么多核的服務(wù)器上測試，使得FFmpeg的VP9encoder當時(shí)甚至會(huì )在多核服器上crash，種種事情表明，在多核服務(wù)器下使用FFmpeg，需要在多線(xiàn)程上做更細致的控制，而僅僅只使用其默認線(xiàn)程策略。另外，還有一點(diǎn)要提及，線(xiàn)程并不只是影響性能，它也會(huì )影響圖像質(zhì)量，我們也發(fā)現，在編碼時(shí)候，隨著(zhù)編碼器使用的線(xiàn)程數目的增加，其VMAF分數可能會(huì )降低。在服務(wù)器端，使用FFmpeg這類(lèi)框架時(shí)候，如何在保證性能以及圖像質(zhì)量的前提下，怎么更好的控制線(xiàn)程（使用CPU的計算能力），是個(gè)非常有趣的問(wèn)題。

　　在性能優(yōu)化過(guò)程中，SIMD優(yōu)化也面臨著(zhù)一些挑戰，一是在使用SIMD優(yōu)化時(shí)需要將算法改造成適合SIMD的算法，這并不總是一件容易的事情，其次需要考慮不同硬件之間的移植性。另外，對于SIMD一般都有內容對齊的需求，且算法上要盡量避免分支使得數據可以流化，同時(shí)，算法上的一些操作并不都被SIMD指令支持（相較而言x86的SIMD指令要比arm更為豐富一些）；另外，還有考慮不同硬件之間浮點(diǎn)算法的精確性，種種挑戰，使得SIMD的優(yōu)化的使用上并不特別的便利。

　　當時(shí)我基于英特爾的GPU做整個(gè)轉碼鏈路的優(yōu)化，Codec解碼主要有兩套plugins，一套是基于MSDK，類(lèi)似FFmpeg集成x264后依賴(lài)第三方去做解碼。第二套思路是基于VAAPI的interface去做，使得整個(gè)硬件加速Codec是FFmpeg自身的一部分。除了做Codec的加速以外，團隊同時(shí)還用OpenCL做了一些AVFiltrer的優(yōu)化，這兩種優(yōu)化之間各有優(yōu)勢。順帶提及一句，即使GPU已經(jīng)加速，在A(yíng)PI的角度依然無(wú)法判斷是否使用了GPU資源，這個(gè)問(wèn)題目前只能歸結到FFmpeg API的設計缺陷。另外，關(guān)于更多GPU的優(yōu)化問(wèn)題，可以參考我之前的一些文章（FFmpeg在Intel GPU上的硬件加速與優(yōu)化）。