文/王莫為
整理/LiveVideoStack
1. 自适應碼率（ABR）算法
本次分享的内容主要分為三個方面，首先會介紹ABR算法的一些背景和過去的一些傳統算法，接下來會介紹機器學習驅動的ABR算法的發展和它潛在的一些問題，最後會簡單介紹一下AITrans競賽與直播場景下的ABR算法。
生活中各種各樣的視訊應用越來越多，包括視訊點播、視訊直播、短視訊和線上教育，各大廠商也花費了很大力氣去提高使用者體驗。
觀看視訊時，我們經常會遇到由于各種各樣原因導緻的視訊卡頓或者碼率不高導緻畫面不清晰的問題，這時大家一般都會在右下角通過選擇視訊清晰度來改善卡頓或者不清晰的問題，而目前很多廠商已經上線了自适應碼率技術來提高使用者的使用體驗。
國内包括B站、愛奇藝都有相對應的技術上線，國外的YouTube、Twitch也有相關的技術應用。自适應碼率一般來講采用基于HTTP的DASH協定，基本運作流程是首先在CDN中存儲已經按照不同碼率編碼好的視訊塊，用戶端會不斷向伺服器請求某個碼率下的視訊塊，每個視訊塊含有幾秒鐘的内容，伺服器把視訊傳輸給用戶端，用戶端會把視訊塊存在本地的緩沖區Buffer裡。上圖中紫色的塊可以認為是視訊塊，持續時間是一秒，高度就是它的碼率。在視訊播放中，Buffer就會被實時消耗，如果此時你的下載下傳速率與碼率不比對就會出現排空Buffer或者累計Buffer，當帶寬遠低于碼率時會出現卡頓，于是各個播放器廠商都會考慮采用自适應碼率來根據目前網絡狀況和Buffer長度來選擇合适的碼率去優化使用者的體驗品質（Quality of Experience），也就是QoE。QoE包括的名額一般有視訊品質、卡頓和碼率抖動等。
ABR的研究已經持續了很多年，但仍有一些挑戰需要解決。假設現在有一個播放器已經播放了一段時間，視訊的Throughput如上圖所示，這時需要選擇一個碼率使得使用者的QoE較高。有一種方式是對Throughput進行預測，然後根據Throughput的變化選擇一個與它接近或者比它低一點的碼率，但在移動裝置或者無線場景下，網絡變化難以預測，這給ABR決策帶來了挑戰。另一方面QoE名額之間是互相沖突的，視訊品質越高視訊塊越大，所需的帶寬越大，是以造成卡頓的機率越高，如果比較保守的選擇低品質的視訊塊，雖然可以減少卡頓機率，但也會犧牲視訊品質進而無法提高QoE。另一方面，ABR算法跟随Throughput變化的速度會影響視訊切換的頻率，如果想讓碼率變化盡可能的平滑就需要用提前準備好的Buffer去處理未來可能會遇見的Throughput的低谷。最後一點是碼率決策具有一定的級聯效應，先前的決策會對未來産生很大影響，換言之就是需要提前為某些Throughput的抖動變化預留一些Buffer，比如在某一時刻對Throughput的預測不是很好，選擇了比較高的碼率，如果網絡發生抖動，在未來全部選擇低碼率也無法阻止這一次卡頓，是以這就需要ABR算法具有一定的前瞻性和預測性。
2. 機器學習驅動的ABR算法
關于ABR算法的研究工作一直都在進行。Rate-based的方法是一種經典的傳統ABR算法，它首先對Throughput進行估計，之後選擇與Throughput接近或略低的碼率，可能還要配上些啟發式算法來處理魯棒性或者帶寬探測的問題。2014年提出的BBA（buffer-based approach）算法基于buffer來進行碼率決策，之是以選擇buffer是因為Throughput抖動非常大，很難對其進行預測。BBA的基本政策是在Buffer比較小的時候認為卡頓機率比較高，選擇相對低的碼率，Buffer比較大的時候卡頓機率比較低，可以選擇相對高的碼率，處于二者之間時會以某種線性函數或者其他對應關系将buffer長度映射到中間的碼率，來實作一種不依賴Throughput的解決方案。這個方案會出現Buffer比較小時相對保守，切換比較頻繁的現象。還有一種同時基于throughput和buffer進行碼率決策的方法MPC，全稱是Model Predictive Control模型預測控制。其基本邏輯是先對用戶端的播放邏輯進行簡單模組化，模組化的目标是可以利用throughput和buffer來判斷選擇不同碼率下未來可以得到的QoE，進而可以利用這個模型對未來進行規劃。
到了2016年和2017年就開始出現了一些基于機器學習的ABR算法，其中CS2P主要解決MPC在Throughput預測不準的情況下會出現明顯性能下降的問題，尤其是在Throughput進行快速抖動的情況下。CS2P利用隐馬爾可夫模型進行帶寬預測，可以認為是利用機器學習算法進行間接ABR決策的工作。
Pensieve是基于深度強化學習進行端到端碼率決策的ABR算法。
2.1 CS2P
CS2P的全稱是Cross-Session Stateful Prediction，基本邏輯是利用更好的Throughput預測來達到更好的碼率選擇，基本操作就是把Throughput預測拼到MPC方案上。作者觀察到吞吐量具有某種狀态轉移特性，關鍵特征相似的會話吞吐量特性相似，例如上圖中兩條紅線之間Throughput會呈現某種狀态特性，然後它又對這些資料集中某一個時間段到另一個時間段的吞吐量轉移進行了分析，發現其中确實具有明顯的狀态轉移特性，這種特性可以考慮用隐馬爾可夫模型去模組化Throughput的變化。另一方面，作者發現如果把所有session的Throughput資訊都拿去訓練同一個模型，就會導緻這個模型變得很差，表征能力不強或者學到相對平均的結果以至于不能反映每一個子類的特性。為了解決這個問題，可以考慮利用關鍵特征對會話進行聚類，之後再針對每個類别訓練單獨的隐馬爾可夫模型。這個工作整體上就是通過Throughput的預測方式間接對碼率進行決策。
2.2 Pensieve
2017年的Pensieve（Pensieve：AI帶來的更流暢的高品質觀看體驗）是第一篇基于深度強化學習端到端進行碼率決策的論文，這篇文章中提到之是以這樣做是因為先前的工作總有一些固有的局限，是以考慮用端到端的方式去學習，減少人為幹涉。ABR本身具有長期規劃特性，這與深度強化學習本身十分适配，深度神經網絡也可以處理多元輸入狀态來輔助決策。
強化學習的基本邏輯是靠Agent和Environment之間不斷互動進行學習。具體的操作方式是，Agent會從Environment中不斷地觀測到狀态state，基于state做出一些決策動作action傳遞給Environment，Environment會依據目前狀态和決策轉移到下一個狀态，并且給Agent一個Reward回報，Agent由此進行學習去最大化未來的累計Reward和。
ABR中的決策就是為未來每一個視訊塊選擇一個合适的碼率，輸入資訊包括目前帶寬、曆史選擇碼率和目前Buffer長度，除此之外可能還需要塊大小、下載下傳時間和剩餘塊數量等資訊，由此Agent就可以每次決定一個動作後告訴環境。這裡首先需要解決ABR算法與環境的互動的問題，強化學習需要不斷地互動疊代才能實作很好的學習效果，這要求環境需要足夠的快才能在有限的時間内完成學習過程。這裡有兩個選擇，一個是ABR算法與真實環境進行互動，但真實環境互動次數遠不足以支援Agent的訓練，是以這裡采用了一個塊級别的仿真器來對用戶端行為進行近似模拟，實作高加速比（十分鐘模拟100小時播放）。有了仿真器和Agent互動之後就需要考慮Reward的設計，ABR算法的最終目标是要最大化的QoE和，每一步的Reward就應該是單步的QoE（品質、卡頓、切換的帶權線性和），這個QoE 模型也是MPC所使用的。Pensieve的訓練方案用的是A3C的快速異步算法，使用真實trace 或者人工合成的trace得到的效果都還不錯。
2.3 機遇與挑戰
Pensieve看上去似乎無懈可擊，但仍存在一些問題。在ABR和流媒體優化中，QoE模型如何建構一直是一個懸而未決的問題，不同使用者和業務需求中品質、卡頓和切換比例關系可能會有變化。而Pensieve一旦訓練完成之後，比例關系就已經确定，不太能夠适應新的業務需求，是以預測在未來可能會出現多目标強化學習來解決多目标QoE的要求。
Pensieve在泛化方面有兩種場景，一個是In-distribution，假設Pensieve應用的網絡狀态場景是可采樣的，這樣我們就可以對目标場景有一定認識，但之前的一些實驗表明如果把流量分布的數量增加并且将對應的資料集混合在一起訓練，分布的數量越多會導緻Pensieve性能下降的約大。這使得在某些具體的資料集上訓練Pensieve，混合訓練和單獨訓練的pensieve agent之間的QoE差距會達到50%，這是不太能接受的程度。第二個場景是Out-of-distribution，在沒有訓練過的場景上pensieve很大程度會fail。
在視訊源泛化方面，由于視訊内容不同，編碼得出的塊的大小抖動幅度也不一樣，如果在訓練時沒有考慮到多種視訊源特性的話會導緻一定程度上的性能下降，是以在這裡可能會需要一些線上學習或者Meta-learning的方案去實作線上學習。
第三個問題在于仿真器與真實網絡環境是否比對的問題，這其中最大的問題在于仿真器是一個數值仿真，在網絡狀态部分采用的是直接讀取Throughput trace去看某一時間段平均Throughput 大概是多少，這時Throughput trace是沒有與傳輸層進行互動的，是以這裡沒法展現不同決策對傳輸層所帶來的影響，這種情況下仿真器所得到的結果就會潛在得與真實網絡環境存在偏差，同時也沒辦法模拟多使用者帶寬競争的問題。還有個問題在于現在使用Throughput trace往往反應的都是當時的吞吐量而非帶寬容量，而實際上的帶寬大小很難采集，這之間的差異也會對這個問題産生影響。
在Pensieve paper中提到可以使用mahimahi仿真器作為傳輸層的仿真模拟，mahimahi很多時候也被用在TCP的擁塞控制場景裡，它能夠模拟中間瓶頸鍊路的Buffer變化情況，進而反映帶寬和RTT的變化。但其本身加速比非常低，如果聯合Throughput trace一起訓練會拉低整個訓練效率，是以這個方案存在一些效率問題。最近也有學者在考慮應用層ABR和傳輸層TCP擁塞控制的聯合優化，斯坦福大學的puffer就是這方面的工作，大家可以關注一下。雖然有了Pensieve 提供的資料集、QoE模型和仿真器，但在網絡或者流媒體領域去真的推進這件事情的話還需要一個公認的仿真系統或者開放的資料集。
3. AITrans競賽與直播場景下的ABR算法
團隊在去年9-12月份舉辦了一個直播流媒體的比賽AITrans，在其中建構了一套系統和平台，包括仿真器和資料，希望能為大家提供一些這方面的幫助，這個比賽後來拓展為ACM MM Grand Challenge。其主要任務是希望大家幫助我們去優化直播場景下的ABR決策，其中DASH以視訊塊為傳輸機關，延遲大，是以改為與公司合作，做了一個幀級别基于Push的直播流媒體傳輸系統。同時直播内容實時産生，ABR算法可利用資訊減少，因為是直播對低延遲、高清、低卡頓、少切換的多目标QoE有更多的要求，這都導緻了這個場景和原先點播場景有一些差別。為了解決低延遲的問題我們在ABR的基礎上又添加了時延控制機制，也就是快慢播和跳幀，以此來對時延進行控制，最後在搭建的低延遲時間直播傳輸仿真平台L3VTP進行測試。
在比賽的過程中可以發現選手們在直播場景下更多的還是在使用BBA、MPC、Pensieve算法的變種，比如有多門檻值BBA，MPC + Oboe [SIGCOMM’18]和在Pensieve基礎上加上直播資訊作為輸入，并修改訓練算法和神經網絡結構的變種等。
而一些選手包括冠軍隊都采用了一些方案來提高ABR的性能，一是網絡狀态分類，二是在直播場景下對源端資訊進行幀大小和間隔的預測（機器學習或傳統方法）。由于快慢播和跳幀機制的存在，采用強化學習的方案中還額外面對Reward對齊的問題。在點播中每個下載下傳的塊都會去播放，進而可以在下載下傳時直接對塊的QoE進行計算，而在直播中時延控制機制會導緻下載下傳的塊也可能不會被播放，或者是以不同的速率播放，這都會影響最終的QoE，是以在最後計算reward的時候要和當時的決策對應才能使算法能夠更好的運作。這其中得到的教訓是不要過度依賴仿真器，團隊在初賽時使用仿真器而決賽時使用真實系統，這兩個之間還是存在某些實作上的差異，以至于某些在仿真器環境下比較好的算法在真實環境下出現了一些問題。
————————————————
版權聲明：本文為CSDN部落客「LiveVideoStack_」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。
原文連結：
https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/100562543「視訊雲技術」你最值得關注的音視訊技術公衆号，每周推送來自阿裡雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流切磋。