騰訊雲H5語音通訊QoE優化

本文首發在雲+社群，未經許可，不得轉載。

雲+導語：4月21日，騰訊雲+社群在京舉辦“‘音’你而來，‘視’而可見——音視訊技術開發實戰沙龍”，騰訊音視訊實驗室高階工程師張軻圍繞網路傳輸方面講解了《騰訊雲H5語音通訊QoE優化》，包含騰訊雲H5解決方案，音訊QOS優化整體框架及優化技術，和運營方法幾個方面。QOS優化包含頻寬估計擁塞控制、抗丟包技術、延時、抗抖動技術四個領域。張珂重點分享了WebRTC與WebRTC之間，tbs與WebRTC之間，tbs與natvie之間互通所涉及的QoS相關的技術問題，回溯分析工具能夠提高工作效率，可以快速發現潛在技術改進點，加快技術迭代速度。 騰訊音視訊實驗室高階工程師張軻 ![enter image description here][1]

11月份，W3C釋出了WebRTC的標準。另外一個專注於WebRTC的國際組織RETF在12月份也釋出了第一個RFC8298，目前還沒有成為真正的標準。我今天講的重點，是圍繞網路傳輸的一些心得。

2017年3月份CallStatus.io WebRTC釋出的全球質量報告中，第一個有10%的通話會因為各種頻寬、丟包、流失原因，造成中途中斷。第二個是有10%到15%的使用者，對音視訊通話的質量不滿意。第三個是有7%左右的大丟包，有95%左右的使用者已經流失在240毫秒以下。

正是因為現在的WebRTC方案有很多問題，我們簡單分析一下剛才的一些質量不佳的原因，有大概三個原因：

第一個，本身WebRTC涉及的是P2P的網路連線，中間可能沒有大量的中轉系統，在遇到跨運營商，甚至小運營商的時候，它的網路鏈路是沒有質量保證的。

第二個，各個瀏覽器互操作性、相容性很差。這些問題剛好都是我們的專長。我們基於此開發了一套解決方案。

兩個核心的技術優勢 第一個是我們的實時音視訊；第二個是基於QQ瀏覽器的TBS核心的瀏覽器上面支援了WebRTC的能力。我們可以針對WebRTC程式碼做很多修改，甚至優化。

我們使用者端可以在微信、QQ瀏覽器上面，對WebRTC進行程式設計。我們還有一些推流、錄製、點播等等的能力。

三種差異化的服務質量 實現一套基本的WebRTC，工作量是後臺的搭建，接入部署，包括在後臺實現傳輸控制、媒體加密，增加運營能力。QQ的東西是十多年海量使用者的經驗，我們現在每天QQ的通話時長大概在10到20億分鐘左右。擴充套件的WebRTC，是相當於在QQ瀏覽器核心裡面，整合了WebRTC的核心，同時對它做了一個擴充套件，解決了現在WebRTC的一些問題。我們對QOS也做了一些簡單的擴充套件。我們會根據後面使用者量的一些使用情況來決策，看這三個怎麼更好地協調，或者說優勢互補。

介面機的分配及接入的狀況 我們建立了一套機房節點全球鏈路質量監控系統，在WebRTC專案裡面，大概部署了60多個節點，覆蓋了30多個國家。國內98%的節點之間鏈路延時小於36ms。有90%全球的網路節點之間，大概鏈路節點小於100毫秒。鏈路優化是持續的過程，包括節點的部署，也會根據使用者量的使用情況來決策，在哪些地域或者是地區投放我們的節點部署。

QOS優化——擁塞避免演算法和抗丟包技術 後臺質量控制示意圖中能看到我們實現了SFU和MCU。質量控制，就是三級策略，介面級這個地方，先估計終端上行網路的質量，包括做頻寬估計，包括抗丟包機制的對接。下行的頻寬估計，抗丟包的一些機制對接。最核心的地方，控制策略是根據上下行的一些質量資訊，來決策我們的流量控制到底應該怎麼做，這裡面有一個核心決策體系，這個東西也是我們整個實時資料裡面一個非常核心、非常有競爭力的技術。

QOS優化到底有哪些技術？ 分頻寬、丟包和延時、抗抖四個領域。想做好QOS，環節特別多，從編解器、鏈路、傳輸、處理、裝置等眾多環節，處理好技術的協作關係，各種演算法的排程、管理、配合是核心難點。

頻寬工具，包括網路擁塞，有GCC、NANA、SCReam、FRACTal。抗丟包技術裡面有ARQ、FEC、PLC延時構成，包括我們的核心在做採集播放的時候，我們會控制很多領域的東西。不同的問題牽扯到不同的技術，各種基礎技術的理解深度和廣度以及應用策略，這是第一個層面的東西。

第二個層面，各種技術、各種因素，它的配合影響，包括反饋以及聯動策略，相對來說比較綜合的第二個層面的東西。

第三個層面，很多業務特性決定了基於場景的差異化的策略，也會導致要採用的策略不一樣。

想做好QOS，必須要把這三個層面的東西解決好，不然QOS是做不好的。

什麼樣的演算法才是比較好的擁塞控制演算法？ 實時媒體擁塞避免控制方案，一直是IETF RMCAT的熱點研究課題。傳輸延時要小於100毫秒。資料流之間不能相互干擾，不能因為自發引起不恰當的使用頻寬。丟包是越小越好，頻寬應用率要高，儘可能使用頻寬。在頻寬有限的情況下，傳輸通道不能餓死。出於安全的考慮，要對可能的一些擁塞控制領域的反饋攻擊做一些處理。安全性方面，媒體資料的傳送一定要是平滑的。公平性方面，不要餓死，也不能搶更多的頻寬，要共享頻寬。

適應性有很多方面，第一適應實際頻寬的波動。比如說在音訊裡面會啟動不連續傳輸，可能導致頻寬越來越弱，這時候怎麼處理？最後一個就是反饋，反饋通道不好了怎麼辦？反饋包丟失了怎麼辦？怎麼去控制好？能把這10個方面做好，就提供了比較好的工具。

TFRC是大概十年前用的技術，最大的問題是延時不可控，視訊幀大小經常發生變化。有速率振盪行為。高丟包下的準確度有問題。

LEBDBT，好處是延時相對來說絕對可控。它的缺點是太靈敏了，有網路波動或者是在頻寬上有一些突發流量，都會導致它迅速崩潰，導致頻寬飢渴。還有一個是後來者效應。它會把第一路的頻寬給搶佔了。

GCC，它是有兩部分，第一部分是收端是基於延時的控制演算法，發端是基於丟包的。它主要有幾個問題：它在行動網路環境多流共存情況下，表現很差。

在有TCP流並存的情況下會過度退讓從而導致WebRTC流飢餓在多WebRTC流併發的情況下，新加入的WebRTC流會損害已有流的通訊質量。 SCReam是基於視窗和麵向位元組。缺點是見SCREAM-CPP-implementaion，有線網路不如GCC。NADA是基於延遲和損失，目前仍是實驗程式碼。FRACTal是FEC探測頻寬，缺點是魯棒性仍需要提高，移動和無線網路待驗證。QUIC是Quick UDP，預設擁塞控制演算法無法保證低延時，可提供私有擁塞演算法。

兩套實現方案：現有WebRTC已切換到綠色部分基於延時的發端擁塞方案，上下兩套演算法通過SDP引數控制。

這是幾個主流的瀏覽器的實踐狀況。Edge還是老的演算法。OpenWebRTC主要推薦的是SCReam演算法。

我們的應用策略對於不同的瀏覽器、不同的版本能力是不一樣的，提供WebRTC解決方案，必須要清楚。我們在基本的WebRTC通話場景，通過SDK引數交換使用的擁塞控制方案。不同瀏覽器裡面，必須要管理好這些擁塞控制演算法。我們提供私有的擁塞控制演算法，主要是基於我們已有的經驗積累，包括剛才我對各種演算法的解讀，包括優缺點的優化方法，同時我們也會在運營層面上對比不同的演算法。

FEC演算法有很多種，第一個是Inband FEC，在語音的編碼器裡面，生成一部分冗餘資訊。它的缺點是以犧牲語音質量為前提的，雖然可以保證流量是穩定的，但是它的質量是不好的。

異或，這個是WebRTC裡面一個主要的實現方法。

Reed-Solomon的糾錯率比較高一點。交織編碼，在WebRTC裡面也有使用。它的目的不是糾錯，而是把丟包給散化。還有一個Fountain，這個技術也非常老了，近兩年在實施領域，可能在廣播裡面應用比較多。它是無位元速率的註冊編碼，特別適合多場景使用。它增加了流量和延時，但是相對來說FEC機制增加的延時量是比較穩定的，適合通道特徵穩定的場景。

WebRTC提供了異或和交織編碼這兩種。 WebRTC中使用的XOR FEC，異或是通過分組的原碼實現的。我提了4個資料包生成三個冗餘包。如果收到資料包123，資料包123丟失了，收到4567。123是資料包，4也是資料包，冗餘包是567，通過47，把資料包給否了。

需要損失程度和亂序相關的反饋，才能正確選擇KFecMaskRandom還是KFecMaskBursty。

這個是WebRTC中FLEXFEC，還是剛才的異或關係。一種是非交織，一種是交織的。非交織的比如說1234進行異或生產一個資料包。5678生成一個資料包。

對於交織的情況，可能就是159，然後生成一個縱向的冗餘包。現在還有二維的，橫向的也生一個冗餘包，縱向也生成一個冗餘包，它的糾錯能力不是那麼強，這是WebRTC裡面的事情。

還有一種是FEC和交織搭配的使用。資料包1234、1234，寫入一個矩陣，然後讀的時候是按列取的，這樣就實現了交織。

交織目標是為了把差錯離散化，再用FEC技術恢復。交織深度M越大，離散度越大，抗突發丟包能力越強，延時越大。

怎麼設計一套好的FEC演算法？ 1、抗丟包演算法要納入擁塞控制演算法，必須是網路自適應的，非常重要，是前提。

2、保證抗丟包能力的前提下如何減少冗餘流量。

3、如何最大化發揮各種FEC機制的優點，場景反饋（連續丟包次數，丟包特性）。

4、FEC演算法，分組大小的選擇，對流量、延時，抗丟包效能的影響均要考慮到。

5、動態冗餘率機制，收斂速度。

6、FEC效果評價。

7、一對多場景，需要對每路接收定製化FEC保護方案。

收端要做好各種反饋，收端收到資料包的時候，要做一些成功率的計算，都反饋到策略中心，來做相應的統計、控制。

NACK演算法關鍵點：

1、結合音訊/視訊的Jitter buffer狀態決策請求。

2、發端/收端延時控制。

3、其它很多精細化控制細節。

4、重傳效果的評估。

5、運營、資料監控。

結合糾錯和同傳的機制。上面對比了一下ARQ和FEC的能力。ARQ引入了突發抖動，較難處理。突發丟包處理能力好，流量效率高。引入延時不固定，但可以設定限制。

FEC抖動變化小，大小丟包均能處理好，但要犧牲頻寬突發丟包處理不好。引入延時相對固定。

WebRTC RetEQ演算法裡面的關鍵點：

1、延時估計演算法。

2、播放延時估計演算法。

3、自適應決策邏輯。

4、語音變速演算法。

5、VAD、CNG資料演算法。

關於流量。

1、降低傳輸包頭：傳輸層包頭。

2、增加組包時長，20毫秒調整到60或者80毫秒，減少包頭負載。

3、降低核心位元速率。1：VAD、DTX2codec層面優化位元速率。

4、降低冗餘。

關於延遲 網路延時：處理延時，排隊延時，傳輸延時和傳播延時。

裝置延時：採集、播放裝置。

播放延時，是資料包到達時和播放時間之間的延時，抗抖延時。

編解碼和處理延時：編解碼和各種前後處理演算法延時。

運營方法 第一部分是專業的實驗室，保證了我們測試資料的準確性和可靠性，以及可追訴性，為系統正式上線運營提供了保障。

QOE的影響因素是非常複雜的，目前我們僅關注客觀質量，設計了一套評估體系。我們線上上系統運營的時候，可以提供一個簡單的指標，衡量我們的演算法到底是好還是壞，直到後續的優化方向，做一些板塊監控。甚至具體到演算法調優層面，可以做一些聚類，劃定一些分析樣本，做進一步的有針對性的優化。

問題分析工具：還原通話過程技術引數，快速問題還原，分析、診斷，也為進一步優化提供豐富案例。

我們通過ABTest運營進行工作方法效果驗證。安卓平臺FEC優化版本新策略（奇數房間）質量明顯優於老策略（偶數房間）。好的系統和演算法是要通過運營資料來驗證和不斷迭代的。

我們雲語音質量的資料到底怎麼樣？2分以下佔比小於3%。10%的通話中斷了，10%到15%的使用者對質量不滿意，這個資料可以做一下對比。

我們的優化是永無止境的課題。WebRTC從M56到前兩天釋出的M66版本，WebRTC解決了1000多個Bug。

Q/A Q：我想問一下，比如說在接入請求的時候，可能會有一些效率，你的軟體、你的網路，還有一些其他硬體的原因。我想了解一下，您這個優化的時候，都是會遇到什麼樣的問題點？怎麼避免這些問題？問一下，比如說你硬體會有一些傳輸的效率，還有你的軟體，或者各個系統之間的一個整合互動的時候，這些憂患點能不能分享一下？

A：我剛才講到的，系統整合層面上，如果僅僅用瀏覽器，除了在後臺做優化之外，沒有太多的優化方法。可能更多的是優化你的流程層面的。如果你有從WebRTC內部層面做優化，那就太多了。音視訊所有的領域都可以做，這個範圍太大了。我講的僅僅是網路傳輸這一個層面，有回升、有效率等等，太多方面了。

騰訊雲H5語音通訊QoE優化-張軻.pdf [1]: https://main.qcloudimg.com/raw/f9fe2417acf2856b71a7ee7fd3b343e0.jpg