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

　　今天的演講將分為明眸、智眸、云剪和開源四個部分來講解，其中明眸主要針對音視頻編解碼與畫質增強方案，智眸主要涉及智能媒體檢索、分析和審核方案，云剪主要提供在線媒體內容生產方案，而開源則是本次演講中將重點介紹的內容。

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

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

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

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

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

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

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

　　在客戶使用和對接時，基本上是以Rest API做對接，圖中清晰展示了整個流程運行起來的全貌。

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

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

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

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

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

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

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

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

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

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

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

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