本文來自英特爾資深軟件工程師李忠，張華在LiveVideoStackCon 2018大會上的分享，由LiveVideoStack整理而成。分享中兩位老師重點介紹了基于FFmpeg的運動視頻分析技術架構，以及英特爾視頻分析的軟硬件解決方案。

大家好，我是來自英特爾開源技術中心的李忠，致力于對FFmpeg硬件加速的研究開發。今天我將與來自英特爾Data Center Group的張華老師一起，與大家分享我們對基于FFmpeg的運動視頻分析解決方案的技術實踐與探索。

首先我會為大家介紹視頻分析的市場前景與基于FFmpeg的運動視頻分析解決方案的主體架構。而張華老師會為大家分享英特爾運動視頻分析的典型案例，希望可以為大家帶來幫助。

1.視頻分析的市場前景

可以說，視頻分析是一片潛力巨大的新興市場，目前全球視頻分析市場規模已超過145億美元，資本對視頻內容的總投入逐年增加并會在未來保持繼續增長的態勢。目前的網絡帶寬中視頻流占總體數據流的80%，如果我們能夠在這樣一個規模龐大的市場借助視頻分析的力量為用戶帶來更優秀的產品體驗，無疑是對整個音視頻行業的一次有利的促進。

2.視頻行業的技術趨勢

從技術趨勢上看，視頻分析與當下多種高新技術緊密結合。根據專業咨詢公司給出的2018年技術趨勢報告，視頻分析與AI Foundation（可提供多種能夠幫助用戶進行視頻分析的AI基礎組件如Framework、Analyse等）、智能APP與智能分析（完善的智能分析解決方案）、沉浸式體驗（VR、AR、MR等）。我們希望視頻分析技術能夠在市場中大放異彩，為客戶帶來理想的收益與價值。

3.基于FFmpeg的運動視頻分析

3.1 視頻分析流程

那么落實到技術當中，接下來我將介紹視頻分析的詳細流程。視頻分析不單單包括對視頻數據的計算，而是由多個協同工作的組建構建起的一套完整架構并集成在一條符合邏輯的處理流程當中。上圖展示的是比較典型的視頻分析流程。首先，傳輸進來的視頻源數據會被解碼、縮放與視頻顏色空間轉換從而便于后續的分析；而后視頻數據會被具體分析如人臉檢測、入侵檢測、視頻特征提取、車輛識別與檢測等；完成分析后傳輸的結果可能是從視頻中提取的目標信息，也可能是經過轉碼生成的視頻流；整套視頻分析流程需要強大的服務器支撐如Video Storage Server、Video Streaming Server與Video Application Server等服務器；最底層則是HW Platform，用戶可根據自身需求通過HW Platform調用CPU、GPU等硬件。

3.2 視頻分析架構

我們需要一個能夠完美支持上述視頻分析流程的優秀架構，也就是將FFmpeg的架構與視頻分析流程緊密結合。上圖展示的是一個完整的FFmpeg架構，有著對Streaming、Decoding、Encoding、Mux、Demux等功能的良好支持，且能夠將經過Demux/Splitter處理的數據流分解成Video流與Audio流以便于后續進行對音視頻的分析處理如傳統的去抖動、顏色空間轉換、FRC等操作。（FFmpeg有兩個典型輸出：輸出Video Renderer與或再進行一次編碼后與音視頻流復合輸出，通過流媒體傳輸上載到端設備處。）

大家可以看到FFmpeg的架構和視頻分析的流程非常相似，FFmpeg的優勢之一是對流媒體、編解碼、Mux/Demux等功能的良好支持，其次FFmpeg也支持多種視頻Filter如Scaling、CSC、Denoise、Tone-Mapping等。至于硬件解決方案，FFmpeg同樣支持Hardware Upload/Download等Filter，用于CPU和GPU存儲之間的數據交換。當然，FFmpeg對英特爾硬件加速轉碼的Filter如DXVA、VA-API、QSV、OpenCL等的支持同樣優異。雖然FFmpeg擅長處理視頻相關復雜任務，但其對AI相關功能的支持還停留在較為原始的階段，僅能勝任一些簡單AI處理任務如超分辨率等。除此之外，擅長視頻轉碼的FFmpeg并不擅長視頻分析，如果我們需要將其用于視頻分析則需要把FFmpeg與一些CV Libaries或AI Libaries相結合。

3.3 FFmpeg 英特爾硬件加速解決方案

我們知道，對一條視頻流進行分析需經過編碼、解碼、處理、分析等流程，其背后的計算過程之復雜，數據量之大超乎想象，如何保證性能的持續高效輸出便成了擺在我們面前的關鍵性命題。如果僅基于CPU實現這樣一套計算量巨大流程復雜的實時處理效果顯然是不現實的，單純地堆砌CPU也會為企業帶來巨大的成本壓力。那么我們能否選擇現有的硬件加速解決方案來優化處理流程使其實現硬件的充分利用？

在轉碼領域，FFmpeg已對英特爾硬件加速有了較為優異的支持。在Linux環境下，FFmpeg包含三個plugins：VA-API Plugins、QSV Plugins、Compute Plugins。VA-API Plugins可直接調度LibVA的Interface并通過Intel Video Driver實現硬件加速；QSV Plugins則需要調用MSDK，再通過MSDK調用LibVA從而通過Intel Video Driver實現硬件加速；而Compute Plugins則主要通過調用OpenCL或即將被支持的Vulkan來進行計算，利用GPU強大的通用計算能力提供更多的擴展功能。

英特爾GPU支持的Codec范圍十分廣泛，除了HEVC，還有H.264、VP8、VP9、MPEG2等；基于VAAPI的Filter有dnoise、color space convertion，以及scaling等，而基于QSV的Filter功能上也是很類似的。無論是VAAPI還是Media SDK都對Intel Video Driver、Intel HW Fix Function有良好支持。有時我們需要一種更為靈活的方案，那么可以用到Compute Pugins，主要包括OpenCL與Vulkan。開發者可通過此Filter利用英特爾GPU的通用計算能力實現強大功能，并且目前Compute Plugins對Overlay /ToneMapping等都有良好支持。也許有人會提出疑問：為什么需要三個Plugins？從平臺限制角度來看，Compute Plugins可以不局限于Fix funtion而提供更為靈活的解決方案。而VA-API Plugins則是FFmpeg的一條更為本地化（Native）的pipeline，并不依賴Media SDK；但VA-API Plugins的局限在于僅支持Linux而不支持Windows，而QSV Plugins 流程下的Media SDK卻可提供跨平臺支持，比如Media SDK可在Windows上進行Encode的原因；其次VAAPI更多是基于FFmpeg實現諸多功能，這對熟悉FFmpeg的開發者而言上手難度較低，方便基于VAAPI實現二次開發，而Media SDK更多由英特爾主導。另外，一些針對英特爾硬件平臺做的高復雜度所做的功能或優化，并不適合在FFmpeg這層實現，比較適合由MSDK處理，比如MFE等。

對轉碼流程而言最重要的三項Encoder指標：質量、性能表現、配置靈活度。為了提升Encoder質量，我們加入了look ahead碼率控制、動態GOP判斷、自適應（IPB）劃分等為Encoder質量帶來顯著提升。

為了提升性能表現，我們針對以下兩種轉碼場景進行了優化調整——一對一轉碼和一對多轉碼。我們在一對一轉碼中引入了異步機制，較為復雜的視頻圖像任務交給GPU硬件加速完成，而音頻編解碼處理、Mux/Demux等工程量較小的任務則交給CPU完成?？茖W分配CPU與GPU所要承擔的任務并通過異步機制使二者默契配合。統流程中，當CPU完成給定任務后產生的等待間隙會對性能造成損失；而引入異步操作后，當CPU完成給定工作后會將這部分工作直接傳遞至GPU中而自己去處理其他一些亟待完成的任務，接下來GPU再將處理完的任務傳回CPU，這種異步操作可極大改善轉碼的性能表現。而針對一對多或多對多轉碼，我們使用一種被稱為MFE (multiple frame encoding)的方式優化轉碼流程。視頻編碼可被簡單理解為對一幀幀單獨編碼，而英特爾對轉碼的性能利用率要求很高，如果單純地一幀幀轉碼就會出現GPU利用率不高的問題，造成利用率不高問題的主要原因之一是流水并行的啟動和終止。我們知道，視頻編碼流程可看作是基于宏塊（macroblock）的流水線作業，流水線的并行需要啟動與終止時間；對于那些小分辨率視頻來說流水線的啟動與終止時間較長，整條線程還未完全排布滿工程這一幀就已結束，導致流水并行度的不足，硬件性能利用率不高；除此之外，還有像GPU hardware context switch問題也能造成GPU性能使用效率較低的情況。如何提高一對多或多對多轉碼的性能表現？MFE可以將多幀進行整合從而讓GPU編碼并輸出使得轉碼效率獲得顯著提升。

配置靈活性是除了編碼質量外影響GPU使用的另一重要因素，可使用Filter的數量與配置Encode的靈活便捷程度直接影響我們開發相關功能的成本。如X264包括許多非常方便的配置，并且也提供了很多Preset。我們希望盡可能簡化開發流程降低開發門檻，精簡用戶需要確定的輸入參數并提供一些簡單的Preset。這樣對于一般用戶而言不需要在運動搜索多少幀與范圍上花太多精力，只需設置好Preset就可在硬件加速的質量與性能表現二者之間取得平衡。

上圖展示的三條pipeline各有其優勢，且適用場景也不盡相同。在FFmpeg中我們可以靈活的選擇，如單純使用VAAPI進行轉碼、Scaling或CSC；或者通過QSV的Transcoding pipeline進行視頻編解碼和視頻處理；除此之外，還支持兩者間的混合使用，以達到優勢互補的效果。如選擇VAAPI decode + QSV encode的方式，構建成的pipeline適用性更強，可以極大程度上拓展用戶開發相關功能的范圍。

3.4 Intel AI Portfolio

盡管FFmpeg對AI的支持較為欠缺，但英特爾對AI Portfolio的支持可以說是相當完整，提供了一套從底層到中間層覆蓋完善的成熟AI工具集，無論是靈活性還是選擇范圍都非常優秀，開發者可根據具體應用場景來選擇使用什么樣的硬件與架構。

接下來有關英特爾運動視頻分析案例的解析部分，由來自英特爾DCG的張華老師為大家分享。

4.英特爾運動視頻分析案例解析

大家好，緊接著李老師的分享，我將會為大家介紹英特爾借助FFmpeg硬件加速實現運動視頻分析的典型案例，我們主要會將此功能用于大型體育賽事的回放與模擬，涉及在線視頻編解碼，對球和球員的識別，3D場景重建等功能從而實現沉浸式觀看體驗。

4.1 基于5G FlexRAN的2.5k體育直播畫面的虛擬分析

例如圖中展示的5G網絡下的足球比賽場景分析，包含多路視頻輸出。每路視頻都會進行球員的識別和跟蹤，球的識別和跟蹤，最終借助得到信息和視頻還原的整個球場的狀態。體育場上方會布置12臺不同角度用于圖像捕捉的攝像頭，由這些攝像頭捕捉并處理完成的數據首先會被以2.5k AVC@30fps的格式參數傳輸至集成了VCA卡的視頻處理服務器，視頻處理服務器處理完成后的視頻數據會被轉碼壓縮并傳輸至5G FlexRAN——這是英特爾一個基于5G網絡搭建的數據處理平臺，其功能類似于CDN，將處理完成的視頻數據傳輸分發至每一位場外觀眾的移動終端上。需要強調的是，這些攝像頭的位置都需要進行預先設置和標定，并且每路視頻會被獨立處理。

4.2 解決方案詳述

如果想達到符合要求的重建效果，我們需要什么條件？除了剛才介紹到的12個負責采集、轉碼、視頻分析、三維重建的攝像機位，還需要可靠的網絡傳輸也就是5G FlexRAN；在功能上，我們需要將視頻以12x AVC 2.5k@30fps的編碼形式在整條流程上傳輸，而視頻分析、編解碼等操作都是在邊緣服務器上完成。為了滿足這樣的編解碼與視頻分析需求，我們需要24張VCA卡（每路視頻兩張）用于分析球與球員的運動情況，包括球與球員的監測與跟蹤、融合、分析結束后的轉碼等等。我們會根據終端的支持情況調整視頻輸出的格式參數。

4.3 關鍵特性

對于運動場景的視頻分析，關鍵在于球和球員的detection與tracking，結合球與球員運動軌跡分析二者精準位置與運動情況。這里需要強調的是，我們采取不同的流程處理球與球員。主要是因為對于2.5K分辨率的視頻進行監測與分析，球在畫面中只是一個很小的元素，單純的掃描無法準確判斷球的運動軌跡，所以系統只能將2.5k的視頻源畫面分割成若干個分辨率為160×160的小畫面并且使得畫面與畫面之間一定存在重合，這樣每幀原始視頻需要在計算大約兩百幅畫面后才能完成detection；而球員相對球而言在畫面中要更佳明顯，這樣需要計算的小畫面數量就會降低，如此龐大的數據量需要強大的計算能力；但球或球員的運動是有連續漸變的，這就使得我們不需要對每幀視頻進行detection；通過對球員的跟蹤大致預測球員的前進軌跡從而推測出下一幀球出現的位置，從而通過tracking加速分析過程。在此基礎上，一些功能就可以實現：“Freeze Moment”的功能，也就是定格比賽并以三維場景呈現賽場瞬間定格； “精彩瞬間”的功能，主要也是通過三維場景重建還原比賽的精彩瞬間。但三維重建等流程還未達到實時處理的要求，后續還需在算法上進一步優化。

4.4 處理流程

上圖展示的是每一路視頻的處理流程。此流程基于FFmpeg 充分利用Intel GPU的硬件pipeline，達到處理的最高效率，AI部分的處理工作是由GPU完成，數據也是在GPU的顯存中存儲，中間的主要處理流程包括球與球員的監測與跟蹤；detection是fine-tune后的Yolo-v2算法，tracking的算法是MDP。隨后系統會融合球與球員，也就是將攝像機坐標映射至球場坐標，根據物體的特點不同，融合的方法一不一樣，球是3D融合，球員是2D融合。12個機位代表有12路上述處理流程與數據，每一個機位之間都是聯動關系，這就需要一套可靠的任務分發機制保證每個機位的正常工作。

4.5 FFmpeg 英特爾硬件加速解決方案的實踐

英特爾硬件加速解決方案包括以下四個部分：FFmpeg Decoder Plugins 支持純硬件的視頻解碼，可充分利用英特爾GPU相關功能；FFmpeg Video Processing Plugins負責借助硬件加速優化YUV和ARGB 間的轉換等視頻處理；FFmpeg + OpenGL 3D Overlay用于整合解碼視頻與媒體分析這兩種輸出；FFmpeg Encoder plugin則利用英特爾GPU對由多路視頻分析輸出組成并以三維圖形呈現的幀進行編碼。

4.6 強調：并行計算

為什么采用并行策略？一場體育比賽需要的12個機位且機位之間是相互依賴的，系統只有等待12路數據全部處理完之后才能得出整個球場的實時動態。如果考慮時間軸上每一幀球場的動態變化則更為復雜，整套系統必須有一個高效的任務調度過程來處理多路視頻，實現同步。