百度媒體雲智慧編碼技術實踐
隨著視訊行業的蓬勃發展，提升視訊質量，降低頻寬成本成為各平臺的首要挑戰目標。本文來自百度雲資深工程師邢懷飛在LiveVideoStackCon 2018大會的精彩分享。在分享中其對百度雲智慧編碼技術進行了深入介紹，並結合具體實踐進一步介紹AI技術在雲轉碼中的應用探索。
文 / 邢懷飛
整理 / LiveVideoStack
大家好,我是來自百度雲的邢懷飛。畢業後一直在從事多媒體方面的工作，從最初的網路音樂播放器設計與實現到視訊編碼相關的技術研發工作，目前主要負責百度媒體雲的編碼、轉碼演算法方面的優化工作。
本次為大家帶來的分享是百度媒體雲智慧編碼的技術實踐，其主要內容分為以下幾個方面，首先簡單介紹下雲轉碼技術及其優化，接下來重點介紹智慧轉碼技術能夠給公有云服務帶來怎樣的提升，最後介紹我們的下一步雲技術探索工作。
1. 雲轉碼技術簡介
1.1概述
雲轉碼是一個比較基礎、成熟的服務，它包括格式的轉碼，協議的轉碼和封裝的轉碼。各種各樣的視訊源轉碼成不同格式、不同協議、不同解析度的碼流後在不同網路中分發到不同終端使用者上，從而使得每個終端上的使用者都能有更好的體驗。我總結了移動端雲轉碼的一些特點，首先網際網路視訊的內容量非常大，海量視訊需要轉碼；第二點就是視訊格式多種多樣，需要對其進行規一化；最後非常重要的一個特點是分散式的並行轉碼，即利用計算資源換取計算的轉碼時間和質量。轉碼服務通常具有一定的服務目標，比如高可靠性、高速的轉碼和高容錯性。轉碼最終的目標是在相同的頻寬條件下，或者相同的位元速率條件下，能夠最大程度上提升視訊的質量和使用者體驗。
1.2百度FEED應用案例
百度在視訊方面的投入也非常大，在這裡列出了當前百度在視訊FEED流裡上線的三款產品。百度APP，與之前版本最大的不同之處在於其首頁中存在一個短視訊的入口。另外兩個APP是好看視訊和全民小視訊。
1.3百度媒體雲支援視訊FEED
接下來了解一下雲服務在整個視訊FEED流端到端的解決方案中處於什麼位置。首先我們內容主要來自於UGC或PGC，比如PGC方面有百家號平臺，UGC則是每個端上都會有使用者自己上傳到雲平臺的內容，流媒體部分包括視訊的儲存，轉碼，處理以及視訊水印、黑邊處理等。其中比較有意思的是黑邊處理，比如在PC上播放視訊通常為橫向，由於目前大多數人選擇用手機看視訊，而手機介面呈現的視訊是豎直形式的，如果把手機上的視訊傳到PC上觀看時會產生黑邊，這是非常影響使用者體驗的，有些作者會選擇加一些特效、黑邊的處理。其中包括了智慧檢測黑邊，裁剪黑邊等一些技術。在整體piepline中我重點列出了兩部分內容，一部分是VOD平臺對整體視訊的處理，另外一部分是視訊內容的理解，其中包括視訊標籤，視訊質量，視訊稽核等，經過稽核之後視訊會統一錄入到視訊物料庫，進一步加工，接著會進入視訊推薦系統根據使用者的興趣與關注點進行視訊FEED流的推薦。
1.4技術挑戰
客戶提出的要求也可以看做是我們做雲轉碼技術所面臨的挑戰。首先需要有一個完善的功能，用四個字概括就是”多、快、好、省”。”多”，即功能多；”快”，即轉碼的速度快，保證視訊服務的時效性；另外就是在功能上要整合更多的AI能力，以應對客戶其它定製化的需求，而且我們可以用工作流的方式來滿足不同客戶的要求。”好”，即實現好的使用者體驗，或者是在壓縮之後有好的質量。”省”，即要節省使用者的運營費用。接下來就瞭解一下如何實現這些需求。
1.5技術架構
這裡介紹下我們雲轉碼技術的技術架構，首先使用者會發送一個轉碼的請求，這個請求通過API後會有各種各樣的引數和模板的設定。然後把使用者請求放在一個負載均衡和任務排程的佇列裡進行智慧的排程。這裡最根本的一個特點就是我們的轉碼例項（Worker例項）也都是通過分散式的計算資源處理的。我們將Worker型別分為三種，首先要實現海量的轉碼需要進行視訊檢測，檢測原視訊是否有問題以及預期的轉碼效果是怎樣的，接著制訂一些轉碼策略。第二個Work例項就是分片轉碼。轉碼例項就是整個真正執行轉碼操作的運算單元，在所有的分散式的機型中完成轉碼後還有一個視訊合併的環節。另外視訊AI的計算也放到了整個分散式的計算單元裡。在分散式轉碼裡會因為中間儲存的一些結果，比如分片的每個中間結果都會存到分散式的檔案系統上。介紹這個技術架構是為了後面介紹如何將智慧轉碼融合到我們現在的雲轉碼的基礎設施裡。
2. 視訊轉碼優化
2.1資源管理&任務排程
前面介紹了基本的架構，接下來會重點介紹我們的資源管理和排程的情況。我們現在用的計算資源大部分是CPU利用率不是很高的機器，把它進行虛擬化之後可以供轉碼的服務進行排程，但問題是無法保證服務質量。因為有的機器的計算資源是不均衡的，這時我們就需要對計算資源進行一個比較智慧的排程。本質上來說，一個轉碼的任務如何給它更合理的，或者更智慧的實現資源的分配呢？這時候我們就提出了基於複雜度預測的排程演算法。一個轉碼任務的複雜度與很多的因素有關係，其中包括時長，解析度，Codec型別，質量要求以及實效性要求。於是我們通過設定一個海量的視訊模型，根據原視訊的資訊訓練出一個大的模型，根據這些引數就可以預測複雜度。我們就通過這個模組排程到相應的計算資源，包括CPU、GPU叢集和FPGA的叢集。
2.2工程優化之分片策略
接下來我會介紹如何對視訊進行分割，首先給大家介紹一下分片策略。一個視訊是隨著時間的不斷變化的場景，這是最簡單的一個策略，也就是按照時間的均勻分片。但是這種策略會遇到各種各樣的問題，有可能你按照時間進行分片了，然後經過視訊轉碼之後發現時長多了或者有其它的問題。後面我們針對一些場景包括智慧轉碼的場景對分片的策略進行了一些優化，比如分片的精度到達了浮點數的精度。然後我們會根據視訊的場景進行分類，同時保證每一個分片的邊界是在一個GOP的邊界上。基於場景的分片的好處將在下面的智慧編碼環節做進一步的介紹。
2.3視訊容錯
在整個轉碼的工程裡也會遇到各種各樣的問題。由於原視訊是多種多樣的，所以會存在各種各樣的語法問題，使用者視訊上傳不完整，視訊質量問題以及時間戳問題。這些是在轉碼裡非常需要解決的問題，但是卻並沒有特別好的方法去解決，只能當遇到問題時，使用者反饋的問題，或者我們自身發現有問題，然後逐一分析解決。我們能做的事情是在轉碼後進行一個完整性的檢查，比如在時長上是否和預期的一致，在質量上我們還會加入質量後檢測這個環節，當然用什麼樣的指標去檢測，這在後面還會有介紹，到底用PSNR，SSIM或者是VMAF都是可以。
2.4 Codec引數調優
在視訊編解碼引數Codec調優方面，我們目前採用的是一些比較常規的開源技術方案，當然最重要的目標是實現編碼複雜度與質量的折中。視訊的預處理就是優化的一個方向，也就是在視訊的序列送到編碼器之前，如何讓人眼看到的效果更好，這樣就能使得編碼後的效果更好。其中就包括運用AI技術實現視訊增強的效果，實現超解析度技術。在人眼主觀質量優化方面也是一個優化的方向，比如基於人眼感興趣的一些區域可以多分配一些位元，同時在伺服器選擇，或者是在其它的的模組中可以用一些HVS相關的指標進行歷史資料優化。
2.5位元速率控制方法
接下來再介紹一下位元速率控制方法。實際上視訊內容型別非常多，圖中列出了四種不同的場景，一個是非常簡單的PPT場景；比較複雜的如NBA等體育比賽場景；室內訪談場景或者是室內電視劇場景。場景不同，那麼在相同質量下位元速率也是不同的。在這裡列出了幾種位元速率控制的方式，但是如何去選擇它呢？不同位元速率對頻寬和質量的要求是不一樣的， CBR位元速率非常恆定，但是它的質量波動比較大；VBR的位元速率有波動，但是它的質量相對來說要好一些。這時我們就會區分是頻寬方面，還是質量方面的要求。
3. 智慧編碼技術
3.1內容自適應編碼
下面主要介紹我們的最重要的目標，比如我們做內容自適應編碼時目標是在人眼主觀上實現一個恆定質量的使用者體驗。那麼接下來引入我們的智慧編碼技術。上面的第一張圖是對傳統的ABR的介紹，這種傳統的方法首先在同一時間要編出幾種不同位元速率的流出來，然後根據終端使用者網路頻寬情況的探測推薦一條最合適的碼流。但是它的缺點是，比如上圖中Apple TN 2224推薦的一個標準，它認為在一定的解析度條件下就應該採用對應的位元速率。2015年Netflix提出內容自適應編碼，名為Per-Title的技術。在上圖中，橫座標表示位元速率，縱座標表示質量，可以看到越往上質量越高，越往下質量越低。圖中的線證明每一個視訊都有自己唯一的一條曲線的特性，從編碼角度來說這是一條RD（率失真）曲線。如何在這些曲線上找到針對於Title本身的一條最優的曲線，這就是我們要解決的問題。
3.2內容自適應編碼CAE
我們在做CAE的時候可以在不同的粒度上做，從上圖可以看到最初的一個粒度是視訊類別，它的做法是用AI的一些方法或者是通過影象裡的內容本身或者其他方式分析出視訊內容是PPT還是球賽等。第二個級別是實現一個Title級別，它的做法是對一個片子進行分析，但是這個片子有長有短，即便是同一視訊型別，比如一個動畫片，它可能有運動劇烈的動畫片，有運動緩慢的動畫片，這都是有很多區別的。再更精細一點就到了分片場景，這個就跟雲轉碼結合起來。我們可以在Chunk 級別上做內容自適應，但是在Chunk階段也可能做得不會那麼好。那麼接下來就是場景級別，我們認為在一個場景裡的視訊的複雜度變化不是特別快。因為我們做場景檢測的時候就會區分出不同場景之間的邊界。大家做的最深入的就是幀級別，它牽扯到對Codec本身的一些優化，也就是需要根據內容本身的程度做位元速率的分配。而我們的方案還是選擇場景級別，也就是做與Codec無關的方案，但是也不是絕對的無關，因為每個Codec都有自己的特性。
3.3視訊源特性分析
那麼我們就要對內容特性進行分析，我們做Codec時候，視訊序列是多種多樣的，視訊源的複雜度也是不一樣的，傳統的都是基於解析度@位元速率的配置。上圖中的四幅圖是比較典型的，在測試序列裡假設分為ABCD四類，A類是幾乎靜態的；B類是一些室內的場景；C類是一些比較動態的，比如足球比賽；D類的在測試序列裡是非常難的一種，這種場景是非常難編的。介紹這個的原因是在我們的服務裡，比如現在最熱的短視訊，小視訊，甚至長視訊等等，給我們提供一些思路來在這裡面進行應用。
3.4視訊源複雜度的表徵
內容的複雜度在ITU的建議書裡很早就給出了一個公式。右邊這張圖是我從最新的MSU的Codec對比裡摘出來的，這幅圖在選擇測試序列的時候會對測試序列進行一些分類，獲取時間複雜度資訊，空間複雜度資訊，然後再評判Codec好壞。做這個分析是為了智慧編碼做一些準備。我們所要解決的最根本的問題是如何從視訊內容的複雜度，視訊質量，還有視訊位元速率中找到他們之間的關係，或者是從曲線上選擇一個最優的引數。當然這裡的視訊質量也有專題介紹，它相關的因素也很多。
3.5複雜度、位元速率與質量的關係
視訊質量相關的因素有很多，首先是視訊解析度，現在到了4K，8K，大家也是在無止境的往高處追求。第二個就是視訊幀率，幀率就是每秒24幀以上，那是對人眼的最基本的應用，也是越高越好。視訊位元速率，在本質上來說，在相同的條件下視訊位元速率是決定視訊質量最關鍵的一個因素。第四個因素就是我們今天講的視訊內容本身，因為內容不一樣複雜度也不一樣。另外不同Codec型別也是視訊質量相關的。但是如何進行評價呢？可能這個話題比較大了，但是我們在具體做自適應的時候會選擇適應自己的一個指標，比如我們現在選擇的還是比較傳統的方法，即PSNR。至於主觀的指標上的要求，我認為得看優化方向是什麼，並不是一定要根據潮流選擇最新的評價指標。但是我們最重要的目的是要在曲線上能夠針對內容找到最優的一個點出來。如何找到這個點呢？這裡有兩種方法，第一種是我們可以基於引數模型的方法，就是無參考的質量評估的一個問題。第二種就是基於機器學習的方法，因為現在是一個海量視訊的時代，如何從一個海量視訊裡利用海量視訊的特性，再結合現在最潮流的AI的技術從而找到一些關係。
3.6無參考質量評估方法
這裡對無參考的質量評估進行簡單介紹。在國際標準裡有很多不同的模型，這些模型也是有好有壞的，但是一直在不斷的進行優化。下面我舉一個例子，這個工作是由國內上海交通大學宋利老師的團隊來做的。也算其中的一個模型之一，上圖的公式中顯示，在給出一定預期的視訊質量的條件下，跟TI，SI，之間的找到一個關係。那麼就可以採用模型的方法預測出預期使用的碼流大小。接下來介紹一下實踐，因為我們最大的服務是百度的短視訊和小視訊，所以我首先對線上視訊的特性進行分析。
3.7 CAE 1.0百家號線上視訊特性分析
這裡簡單介紹一下短視訊和小視訊的特性，短視訊是橫屏的視訊，它可以在PC上觀看也可以在手機上觀看，並且它的長度不等。小視訊是一個豎型視訊，同樣視訊長度不等。我們對線上的視訊複雜度進行了一個統計，大約40%的視訊是中等複雜度的。短視訊作為內容運營來講，它有些自己的特點，就比如有可能看上去很簡單的一個場景，用一些語言描述就會導致它的點選率很高，所以這裡還是有非常大的頻寬節省空間的。從內容分析，我們也有多種型別的視訊，下面舉一些例子。
上圖中顯示的幾種場景是複雜度逐漸上升的場景，最後一個場景比較複雜，其複雜度為1.3，這種在視訊編碼中是非常難的，因為它的細節非常豐富。下面是小視訊的場景。
我們針對於小視訊也進行了複雜度的分類，第一幅圖是小百科的這種場景，還有一些監控的場景，接著複雜度為1.0的是一個表演場景，最後一個複雜度為1.2的是一個戶外的場景。在短視訊裡，包括快手，有很多是戶外的這種場景，它的複雜度相對來說是比較高的。
3.8 CAE1.0技術方案
在智慧編碼技術方案1.0版本的實現過程中，我們選擇了基於場景的分割。我認為基於場景的分割與雲轉碼配合起來是比較好的一個方案。進行場景分割之後也會出現一個問題，比如分割後的場景有的在15秒以內，有的只有一兩秒，這也會導致在轉碼的時候出現問題。我們會有一個從Short到Chunk的轉換或者合併。我們能保證的是Chunk的邊界肯定也是在之前檢測的場景的邊界上。視訊複雜度的計算使用的是CRF 編碼，我認為用CRF 23編碼評估它的複雜度是比較合理的。為了歸一化，我們還計算了BPP，把視訊編出來的位元速率再規劃到每個畫素上去。然後我們為了計算方便，為了後面的策略，還會使用一個函式對BPP進行壓擴到一個區間上，這樣就方便我們產生一些策略。我們最終的策略是在視訊位元速率上進行一次Scale，當然這裡有兩種方法，一種是可變的CRF，另一種是可變的視訊位元速率。
1）線上頻寬節省情況
我們上線了1.0版本後，根據不同的複雜度，再結合雲轉碼計算線上收益。在一般場景的例子中，位元速率節省21%的情況下，PSNR有略微降低，對人眼是沒有任何損失的，這是很重要的一點。在線上我們會做一個對比測試，分為實驗組和對照組。依據使用者的點選量，最後折算出頻寬的情況。CAE1.0相對CRF節省了11%的頻寬。但是這個頻寬的節省不一定有太多的參考價值，因為每家公司不一樣。不過我們在視訊的位元速率上平均節省了20%到30%。
2）效果對比CAE1.0 VS VBR
接下來舉一個在效果上對比CAE和VBR的例子。我們預期是要實現在整個視訊上進行比較理想的恆定質量的位元速率的分配。在區域性細節上，比如草的這種細節，可以看到CAE的效果上明顯保留了更多的細節，當然這是在相同的位元速率的條件下對比的。
3）CAE1.0的缺點
接下來介紹一下CAE的缺點。我們確實實現了CAE，但是卻需要消耗計算資源兩到三倍，時效性得不到滿足。第二個是用3 pass 編碼解決一些位元速率控制不準確問題，比如有些場景非常小，可能一兩秒，或者兩三秒，但是如果直接用VBR分配位元速率就可能導致位元速率不準確，所以我們就必須再用一個2 pass的方式實現理想的位元速率分配。後面我們會有一些探索，利用機器學習的方法，或者深度學習的方法替代CRF編碼的複雜度評估。
4. 下一步技術探索
4.1基於ML的複雜度評估
首先我們可以採用機器學習的方法，即依據TI，SI進行復雜度分級。我們在做評估的時候，已經採用了五類分級，從非常簡單，簡單，一般，複雜，到非常複雜。分級之後，我們可以用一些引數的方法，參考一下國內老師的工作或者國外的那些質量模型的工作在一定質量的要求上進行一些預測，給出部分最優的編碼引數，然後還可以提取其它更多的特徵。
4.2基於深度學習的最優編碼引數預測
雖然基於傳統的機器學習方法可以實現編碼的複雜度評估，但是目前深度學習非常火熱。而每天的視訊內容量非常大，那麼我們可以用深度學習的方法來進行最優編碼引數的預測。此時就會涉及到視訊特徵資料庫的建立，這裡需要提取TI，SI相關特徵資訊，利用 CRF進行編碼，得到質量，位元速率，內容複雜度指標。但是僅僅這些指標可能是不夠的，因為AI的能力目前並沒有那麼強大，所以還需要藉助於視訊本身的一些東西，比如提取一些語法資訊。由於沒有資料，因此我們目前還沒有具體實現的過程，但是目前已經進行了一些工作，比如利用一些現有的模型，CNN模型，它本身有提取特徵的一種能力，然後可以用一些其他TI，SI的特徵，加上語法裡的特徵，能夠預測出位元速率，這是目前正在探索的部分工作。
4.3AI智慧編碼框架
那麼將所有的工作整合起來，在整體排程中進行的改造是什麼呢？我們會對視訊內容進行分析，首先進行場景分割，接著視訊分片，然後是基於深度學習的編碼引數的生成器，有了生成器之後，就可以對每個場景進行最優的編碼分片。同時我們還會進行VMAF質量監測，視訊合併，到最後的分發，這也我們正在探索的方案。
精品文章推薦
技術乾貨：