音視頻抗丟包技術綜述，面向不可靠傳輸網絡的抗丟包編解碼器

時間 2019-11-17

原文原文鏈接

本文整理自高澤華聲網Agora.io 編解碼算法工匠，在RTC2017實時互聯網大會和QCon上海2017上的技術分享。算法

歡迎訪問 RTC 開發者社區，與更多開發者交流經驗，參與更多技術活動。後端

不管對於音頻編碼仍是視頻編碼而言，對於編解碼來講，都有不一樣的應用場景。比較大的兩個範圍，第一種，面向文件直播的編解碼器。第二種，面向網絡通訊的編解碼器。服務器

在不一樣的應用場景下面，編解碼器的選擇徹底不同。舉個例子，面向直播的時候，延時比較長、丟一些包、網絡帶寬跳動等，是不須要考慮。能夠在離線的時候，充分的利用CPU的能力去編，能夠固定I幀的間隔、固定I幀的大小，甚至多個B幀均可以。碼率也能夠是固定的，這對於錄文件和錄視頻沒有問題。網絡

可是若是面向實時網絡通訊這樣恐怕不太好，由於網絡是瞬變，並且網絡狀態通常來講都是會伴隨着丟包這樣的狀態，這個時候就不適合使用，好比說使用固定的I幀間隔，若是I幀丟了就要使用I幀重傳。還有就是也不能使用固定的碼率，由於碼率也是瞬變的。測試

因此在面向於網絡通訊的編解碼器中，編解碼器選擇和直播的編解碼器的選擇差異比較大。好比有人提出在網絡通訊中硬件壓縮是否能夠，其實因爲不一樣的廠商對硬件壓縮的支持是不同的，硬件壓縮的迭代不同，編碼支持也不太同樣。有的硬件版本也不能產生可變I幀大小，或者碼率是固定的，若是碼率不固定就會自動重啓硬件的編解碼器。我說的都是一些個例，並不表明全部編解碼器都是這樣。我想強調的是，編解碼器面向直播和網絡通訊是不同的，我今天想說的是面向不可靠傳輸網絡的抗丟包編解碼器。編碼

首先咱們來思考一下抗丟包的重要性。在2017年，有幾類應用是比較火的，第一類在大學校園最火的遊戲應該是王者榮耀和狼人殺，王者榮耀10人組隊實時廝殺，還有語音。狼人殺提供實時視頻。第二類就是互動直播，主播端把通訊直播流發到觀衆端，同時也能夠把觀衆端拉上麥，實現主播和觀衆的互動。我記得滬江的技術負責人吳海濱曾經提出，「在當前互動網絡教育中最難解決的問題仍是實時性，就是老師跟學生怎麼可以更好的互動」。互動直播，在當前網絡下給技術提了更高的要求，要求可以在低延時下提供高質量的通訊品質。包交換的網絡中，要想實現低延時和提升包質量，若是承載信息的包沒有按時到達，接收質量不會好。cdn

既然丟包是低延時和高質量的一個攔路虎，咱們來看一下當前的網絡狀態是否是有那麼多丟包。咱們提到丟包的時候首先要想到一點，丟包的定義是什麼？其實對於通訊來講丟包並不意味着真正的包丟了，我我的理解「只要包沒有按時到達都叫丟包」。好比第一個包沒有來，第二個包已經到了，此時第二個包發出去了，那麼第一個包再來對我沒有任何的幫助，實時通訊不可能重來。視頻

對於通訊系統而言，上圖是一個基本的通訊系統，一個APP經過4G和WIFI，再經過公有云實現通訊。你們可能會講了，已經4G、5G，是否是帶寬足夠大，不須要考慮丟包的問題了呢？blog

不徹底是那樣。舉個例子，咱們看一下上圖這個包的到達通路，手機和Pad通訊，假如說Pad經過4G到達公有云，再經過WIFI發回給手機端。在這個通路中有三段網絡，也就是有三段可能會產生丟包的地方。第一段是公有云之間，由於公有云之間也會有不少路由的轉換。第二是4G或者WIFI到APP端，第三段就是，還有就是APP，device自己。遊戲

先來說第一段，在公有云上咱們都會建一些服務器。即便是在同一個運營商下，早上八點、中午12點到晚上8點，網絡情況都不同，一般來講晚上8點網絡高峯期，這個時候網絡傳輸很是上不穩定，在服務器和服務器之間常常容易產生丟包。第二是不一樣的運營商之間，好比電信和聯通之間，當聯通向電信傳輸數據時，因爲兩個運營商出口帶寬結算問題，不在高峯期均可能不太穩定。還有一個問題就是，小運營商，好比教育網，機房的狀態不是一直穩定的，可能會產生丟包。

第二段是4G或WIFI到終端，這一塊也並非很是可靠。若是兩臺設備連着是不一樣的基站互相通訊，基站之間可能產生一個轉化和丟包的問題。雖然鏈接了骨幹網，可是因爲骨幹網不一樣的運營商差別，會產生丟包。在同一個運營商之間，不一樣的地區，網絡狀態也是不同的。舉個例子，在今天的會場，雖然我以爲這附近4G是蠻不錯的，可是在2000人大型的會場都在使用聯通4G的時候，實際上共享網絡的狀態是比較差的。這就是所謂的共享網絡帶來的問題。

當咱們在不一樣的國家鏈接網絡的時候，好比印度、美國，不一樣的國家網絡狀態也不一樣，因此咱們在作網絡策略的時候實際上都不能一律而論。

除此以外還有WIFI。若是你們作過實時通訊的話，都會有一個感受，有些時候4G比WIFI更穩定。由於WIFI其實是很是不穩定的系統，若是你們在公司連WIFI的話，公司可能會存在數十臺路由器，路由器之間有頻率干擾。另外，即時是上千塊錢的路由器，可支持鏈接人數最多也就是三四十人。超過這個限制，即便是連上了也會主動丟包。因此，並非4G和WIFI帶寬足夠高就沒有丟包的問題。

再提出一個很是現實的現狀，運營商都在推行VoLTE，還有一個新詞叫VoWiFi。這是數字電話在產生的一個變革，把電路交換過渡到分組交換，在分組交換下全部的通訊都是經過包來傳遞，而不是固定的鏈路。以前的通話，我一旦撥通這個電話，鏈路就保持下來，無論有沒有用、用多少，鏈路都是存在，因此效果都比較好。可是在分組交換網絡下，數據都是以包的形式傳遞，不說話的時候不發包，或者發包比較少，碼率也會比較低。可是運營商提出VoLTE和VoWiFi已經好久了，實際上咱們只有少許狀況會使用VoLTE，當網絡很差時，都會回落到電路交換進行通話。運營商本身的4G網絡質量就很差，更不用說咱們在上面作端到端視頻的通訊。

既然丟包問題這麼常見，咱們有哪些辦法？一般有這四種方案：FEC、PLC、ARC、ARQ，還有一個是編碼器。ARC和ARQ分別是自動碼率控制和自動請求重傳，都是針對網絡狀態進行調整的策略，可是它們倆應用的場景不同。對於音頻來講，不管是語音仍是音樂，碼率一般需求比較低，尤爲是語音，此時ARC的應用場景並非特別大。好比，要傳一個16kbps的語音，在當今的網絡狀態下問題不大。要傳一個128kbps的音樂就稍微有一點問題。要傳一個400-800kbps的視頻問題就會比較多了。因此ARC是一種針對當前網絡狀態進行估計，而且回傳回來主動進行碼率調整的策略。

ARQ，自動請求重傳，當網絡延時比較低的時候，咱們能夠經過重傳的方法來實現抗丟包。這種方案有兩種策略：第一種，發出一個包，只要在規定的時間沒有響應，就再發一個包；第二種，發出一個包會等它的請求，若是它的請求到了就給它一個重傳包。可是這種技術的使用前提是端到端的網絡延時比較短，若是延時比較長，好比延時200-400毫秒，用重傳請求的方法，網絡傳輸的延時會更長。

PLC是一個徹底後端的抗丟包方法，有最簡單的插值法、過採樣法、還有WebRTC比較流行的拉伸和縮短法。WebRTC的這種方法效果不是很好，由於拉長或縮短會改變聲音的頻率，會產生奇怪的聲音，或者改變語速。插值法採用的策略是，第一個包到了，第二個包丟了，第三個包到了，能夠經過差值來實現。通常的PLC，能夠對抗5%的丟包，再高了就效果很差。

我想重點講的是FEC，這是一個很大的話題。FEC能夠分爲兩大類：基於信源和基於信道。信源FEC是，包能夠多發幾遍，對於音頻來講一秒能夠發50個包，信源FEC就發兩倍100個包，一樣大小多發一遍，來實現抗丟包。基於信道的抗丟包是，好比當前的丟包率25%，咱們能夠加50%的抗丟包。那麼原始有4個包，通過處理生成6個包，這6個包到達任意的4個包，均可以實現準確解碼。

信源FEC中，若是採用多發包的方式，會產生新的問題，好比要傳輸的是16kpbs的語音，丟包時，是發32kpbs的語音，兩個16kpbs的都發過去。仍是把它拆成兩個8kpbs再發？各有優劣。若是使用兩個8kpbs，降低了音質來換取抗丟包性。若是選擇32kpbs，保持音質，以前16kpbs下網絡丟包假如是10%，帶寬變成32kpbs後，丟包狀況也會不一樣。因此，Opus和Silk的編碼器提出一種新方法，採用了降低碼率的作法，相似於兩個8kbps。在16kbps的音頻流中，有4kbps的小包來對前一幀補償。一旦大的包丟了，就使用小包來進行恢復，可是帶來的問題是音頻質量降低了。FEC是一種很好的抗丟包方法，可是它的問題是有可能會浪費帶寬。使用FEC以後，確實能提升包的到達率，能在有限的延時下把通訊的質量提升。

咱們來看一下FEC的流程。先發出了三個包，從device1發了3個包到device2，packet2丟了，那麼此時的丟包率是33%。device2會發一個lossinfo給device1，告訴它丟包率是33%。而後，device1接着發新的包，此時會發雙倍，兩個packet4，兩個packet5。packet4發生丟包，就會被另外一個packet4補償回來了。這是典型的FEC的流程，但有幾個問題：

loss info自己也可能會丟丟失
loss info沒丟失，但從device 2 到device 1會有延時
丟包估計可能不許。丟包率33%，若是擴大窗口多是25%
雖然是33%的抗丟包，發冗餘包時只能多發一倍，沒有辦法準確的發33%
只丟了packet4，但packet5也發了兩遍，這浪費了帶寬，沒有意義的

若是是多方通訊， device2丟包率33%，可是device3和device4不丟包怎麼辦？若是全部device都多發了一倍的包，並且碼率不上升，確實device2的抗丟包性好了，可是犧牲了device3和device4的質量。若是把碼率擴大一倍，全部device的質量都好了，可是浪費了一倍的帶寬。

基於這種現狀和當前的不少學術研究，咱們提出了一種新的思路：結合信源和信道編碼的特色，利用充分包交換網絡的特性，基於此，研發出了聲網新的編解碼器——Agora SOLO™。從通訊原理來講，信源編碼是儘量去追求高壓縮比，去冗餘。而信道編碼是追求強糾錯，靠加冗餘來實現糾錯。Agora SOLO™就是把加冗餘和減冗餘結合起來，不重要的地方減冗餘，重要的地方加冗餘。

咱們以上圖爲例，來看一下Agora SOLO™的抗丟包特色。對全部的接收端，咱們默認都發了這些包。可是，咱們會把包分紅兩塊，一個是packet 1，一個是packet 1’。若是隻收到其中一個包，那麼就實現一個有限失真的恢復，質量相對稍差。若是packet 2和packet 2’都收到了，那麼就兩個包合起來，實現一個高質量的解碼。也就是說，Agora SOLO™默認就不須要等待對當前網絡丟包狀態的統計，只須要直接把抗丟包作到編解碼內部。這樣作的好處是，首先實現了更低的延時，由於它不須要估計信道的狀態，直接把包發出去就好。第二是更高質量，收到一個包時質量達到的普通編解碼器水平，收到兩個包達到高質量編解碼水平。第三，這是面向多人環境的。不一樣人下行網絡不同，丟包不同。第四，策略更簡化，使用Agora SOLO™幾乎能夠不須要再作策略調整。

上圖我用ITU NTT的中文測試序列跑的測試結果。我稍微介紹一下，ITU的NTT是標準的編解碼器測試序列，裏面有26國語言，我這裏面只拿出了中文部分。除了荷蘭語和俄羅斯語之外，中文是比較難編。由於中文除了通常語言外還有四聲。看圖第一列，是隻收到8kbps的packet1， PESQ的平均分是3.52分。若是隻收到packet2，它分數是3.51分。若是packet1和packet2都收到，16kbps時，分數是3.95分。以上是窄帶的分數。寬帶下的分數，是3.58分，滿分是4.5分。這個測試結果能夠清晰的看到，只收到1個包時是有限失真的。當兩個包都收到時，質量會明顯提高。