文｜網(wǎng)易云信資深流媒體開發(fā)工程師

背? ? 景

科技的進(jìn)步以及通訊基建的高速發(fā)展，使得人們對交流的模式要求越來越即時，對交流內(nèi)容要求越來越具象，這些要求催化著內(nèi)容交換模式的不斷發(fā)展，從傳統(tǒng)的信件，到短信電話再到互聯(lián)網(wǎng)場景下的微信語音、抖音短視頻、視頻直播及實(shí)時音視頻通話。隨著5G正式商用元年的真正到來，更加即時與具象的實(shí)時音視頻通訊將被更廣泛的應(yīng)用。實(shí)時音視頻系統(tǒng)，是一個相對比較復(fù)雜的內(nèi)容傳輸系統(tǒng)，從大的流程上來講，系統(tǒng)覆蓋音視頻采集、音視頻編碼、音視頻傳輸、音視頻解碼、音視頻繪制。想要做到高質(zhì)量的音視頻通話，每個環(huán)節(jié)都需要豐富的手段才能進(jìn)行各種場景及設(shè)備的適配與效果提優(yōu)。

實(shí)時音視頻的最顯著的特點(diǎn)是低延遲，也就是說實(shí)時音視頻對于網(wǎng)絡(luò)的要求是非常高的，甚至可以說是矛盾的。一方面它為了追求低延遲，它能夠允許網(wǎng)絡(luò)傳輸中的丟包，另一方面因為視頻編解碼的傳遞參考性，任何的丟包都會造成很大的視頻質(zhì)量的損失，最終將降低實(shí)時通話的QoE評價，所以又不能容忍網(wǎng)絡(luò)傳輸中的丟包。為此搭建一個高質(zhì)量實(shí)時音視頻系統(tǒng)，尤其是多方參與的會議系統(tǒng)，應(yīng)對于參與通話各方上下行網(wǎng)絡(luò)復(fù)雜性（帶寬受限/丟包/抖動/高時延）的傳輸QoS策略的設(shè)計是非常有必要的。本文就會議場景下，服務(wù)器端的QoS策略，做一些詳細(xì)的分享。

會議場景分段QoS

會議場景的通話，決定了參與通話的各方都要通過中轉(zhuǎn)的流媒體分發(fā)服務(wù)器進(jìn)行傳輸內(nèi)容的交換。會話傳輸鏈路可以劃分為實(shí)時通話發(fā)送端到流媒體分發(fā)服務(wù)器的上行傳輸鏈路，以及流媒體分發(fā)服務(wù)器到實(shí)時通話接受端的下行傳輸鏈路。上下行傳輸鏈路，從服務(wù)器角度而言其承擔(dān)傳輸角色是不同的，傳輸策略作用輕重亦不相同，為此針對于這種多人會議場景，需要制定上下行獨(dú)立的QoS傳輸方案，去保障上下行的傳輸質(zhì)量。我們稱之為分段QoS策略。

上行QoS

網(wǎng)易云信的設(shè)計里，QoS的強(qiáng)控制權(quán)都交由發(fā)送端。接收端做被動的接受信息反饋和丟包請求與恢復(fù)。針對于上行QoS的策略，服務(wù)器端作為接收端，設(shè)計了一系列的QoS手段，進(jìn)行高可靠的鏈路傳輸。包括但不局限于：丟包重傳請求（NACK）、前向糾錯（FEC）、關(guān)鍵幀請求（PLI/FIR）、接受信息反饋（FeedBack）等手段。這里選取兩個抗丟包手段做一些深入的講解。

?丟包重傳請求?

丟包重傳請求，簡單的實(shí)現(xiàn)就是服務(wù)器作為接收端，在實(shí)時接收傳輸?shù)牧髅襟w的時候，進(jìn)行傳輸層媒體包序的連續(xù)性檢查，當(dāng)出現(xiàn)非連續(xù)包出現(xiàn)的時候，經(jīng)過一定的超時時間（考慮到實(shí)時音的低時延要求往往這個超時時間會設(shè)置的比較短），便會向發(fā)送端進(jìn)行丟失包的重傳請求。由于丟包的不確定性，丟失的包序的分布也會呈現(xiàn)出不確定性。為此我們需要設(shè)計出一個合適的重傳協(xié)議來覆蓋丟包的各種分布情況，達(dá)到重傳請求的最小帶寬占用的目的。

我們設(shè)計了靈活NACK請求協(xié)議，其協(xié)議設(shè)計可以很好的解決上述情況：

協(xié)議允許單個NACK請求包對多個流，進(jìn)行不同丟包情況的重傳請求。

?前向糾錯?

前向糾錯（FEC）其實(shí)是一種冗余錯誤恢復(fù)的算法。應(yīng)用在網(wǎng)絡(luò)傳輸中，主要是用來抵抗網(wǎng)絡(luò)丟包導(dǎo)致的信源錯誤。

其具體的做法就是將原始的信源數(shù)據(jù)進(jìn)行可逆的運(yùn)算，生成額外的冗余包，在實(shí)際發(fā)送的時候會將原始包和冗余包分為一組發(fā)送到網(wǎng)絡(luò)上。在網(wǎng)絡(luò)出現(xiàn)丟包的時候，接收端可以通過同一分組的原始包和冗余包進(jìn)行逆運(yùn)算去還原所丟失的原始包。當(dāng)然這里的還原是有條件的，還原的成功率跟我們?nèi)哂嗨惴ǖ娜哂喽却笮∮嘘P(guān)，一般情況下成正相關(guān)。但過多的冗余包會占據(jù)很多的發(fā)送流量，這樣其實(shí)是不利于正常的媒體傳輸?shù)摹?/p>

關(guān)于冗余算法的選取在服務(wù)器端也是非常重要的一個課題，主要涉及到兩點(diǎn)：

冗余度在算法層面是否支持動態(tài)調(diào)整。?

計算復(fù)雜度能否滿足服務(wù)器性能要求。

第一點(diǎn)很容易理解，因為網(wǎng)絡(luò)丟包是復(fù)雜多變的，固定冗余度的算法要么會帶來帶寬的浪費(fèi)要么恢復(fù)效果不理想。第二點(diǎn)的話，源自于實(shí)時音視頻服務(wù)器主要的角色是做媒體分發(fā)的，其根本要求是分發(fā)的高效，一旦FEC的算法復(fù)雜度過高，在高并發(fā)高I/O吞吐的情況下，勢必會降低服務(wù)器并發(fā)性能，甚至?xí)腩~外的端到端的delay。

目前已經(jīng)實(shí)現(xiàn)的FEC算法很多，簡單有基于異或的實(shí)現(xiàn)，復(fù)雜的有基于矩陣運(yùn)算的，以及一些其他的算法，這里就不詳細(xì)描述了。

?網(wǎng)易云信實(shí)踐?

以上簡單的介紹了丟包重傳請求和前向糾錯的策略。這兩種機(jī)制是常見的抗丟包策略。在具體的應(yīng)用上，各個音視頻廠商，只是在協(xié)議實(shí)現(xiàn)和算法選取上略有不同而已。既然ARQ和FEC都是為了對抗丟包而制定出來的策略，那么在網(wǎng)易云信中我們?nèi)绾巫鲎顑?yōu)的策略選取的呢？

首先在做策略選取之前，我們先回顧一下兩種策略對抗丟包的不同思路。

第一種丟包重傳策略（ARQ），解決的是當(dāng)前丟包已經(jīng)發(fā)生，需要做短暫的時延犧牲（即做丟包重傳的時候會造成Jitter），來對抗丟包，其優(yōu)點(diǎn)明顯，即不會實(shí)時的占用信道帶寬，缺點(diǎn)就是引入的Delay，一些不當(dāng)?shù)腘ACK請求策略的設(shè)計甚至?xí)斐闪髁考獯獭?/p>

第二種FEC策略，其作用效果是實(shí)時觀測丟包率的變化，做丟包率的預(yù)估，實(shí)時產(chǎn)生冗余數(shù)據(jù)來對抗可能出現(xiàn)的丟包。其優(yōu)點(diǎn)在基本不需要犧牲時延，可以做快速的丟包恢復(fù)。但其缺點(diǎn)亦很明顯，即依賴于丟包預(yù)測的準(zhǔn)確度，過高的冗余會造成帶寬流量的浪費(fèi)，甚至擠壓正常的信源的傳輸，導(dǎo)致一個不健康的信道傳輸狀態(tài)。

下面介紹一下網(wǎng)易云信對這兩種策略組合的使用方法。

1. 建立網(wǎng)絡(luò)狀態(tài)的觀測器。

其主要監(jiān)控當(dāng)前網(wǎng)絡(luò)的丟包率、抖動、時延、擁塞狀態(tài)。觀測器的建立質(zhì)量好壞會很大程度的反應(yīng)到我們的抗丟包效果上去，在丟包率上我們會根據(jù)關(guān)心的閾值去做不同區(qū)間的采樣標(biāo)本，做多個細(xì)分丟包率的觀測和預(yù)估。這里的丟包率有平均RTT內(nèi)的丟包率，有去抖動的丟包率，以及跟NACK請求相關(guān)的丟包重傳超時時間相關(guān)的丟包率。觀測器主要的作用是進(jìn)行網(wǎng)絡(luò)可數(shù)據(jù)化的狀態(tài)偵測。為后側(cè)的策略提供網(wǎng)絡(luò)類型的分析，并提供確切的指標(biāo)，供核心調(diào)控模塊來調(diào)節(jié)自適應(yīng)的參數(shù)。

2. ARQ手段先行，FEC手段做兜底。

具體的意思是我們會根據(jù)預(yù)設(shè)的最大端到端Delay（這個Delay跟用戶設(shè)置模式有關(guān)，可以動態(tài)調(diào)節(jié)），再根據(jù)觀測器觀測出來的相關(guān)網(wǎng)絡(luò)指標(biāo)去計算ARQ的成功率，剩下的失敗率由FEC做兜底。具體算法如下：假設(shè)當(dāng)前選取的網(wǎng)絡(luò)平均丟包為L，當(dāng)前Rtt為R，我們能容忍的最大Delay時間為D，最小NACK請求間隔為I，則單個包可以進(jìn)行NACK的請求次數(shù)C = (D-R) / I,那么經(jīng)過重傳之后，單個包仍處于丟失的概率為：X_L?= L * L^C= L^(C+1)，那么FEC冗余率設(shè)計的參考丟包率T_L?= a * X_L?+ b * B_L，其中a為增益系數(shù)，屬于自適應(yīng)調(diào)整參數(shù)，B_L是基于觀測器得到的網(wǎng)絡(luò)基本（最小）丟包率，b為調(diào)節(jié)系數(shù)（b 小于等于1.0），一般在網(wǎng)絡(luò)帶寬不受限的情況下，將b設(shè)置為 1.0。此外基于丟包率如何去選取冗余度，有很多計算方式，這里就不展開了。

3. 基于接收端反饋以及模塊自檢的策略調(diào)整。

服務(wù)器作為接收端會建立抗丟包效果評估模塊，具體到指標(biāo)有NACK成功率，NACK響應(yīng)時長，FEC 成功率等。發(fā)送端會基于此類的反饋，以及兩個模塊自身的相關(guān)統(tǒng)計數(shù)據(jù)，如Rtx（重傳包）、FEC流量與原始信源的流量占比，以及擁塞控制模塊的擁塞狀態(tài)等，進(jìn)行模塊內(nèi)策略相關(guān)的參數(shù)（D、I、a、b等）的動態(tài)的調(diào)整。

網(wǎng)絡(luò)本身是復(fù)雜的，需要有一個合理的調(diào)度器來控制ARQ和FEC抗丟包模塊的協(xié)同作用，要做到具體網(wǎng)絡(luò)情況做具體的調(diào)節(jié)，我們的抗丟包策略不應(yīng)造成過多的網(wǎng)絡(luò)信道的擠壓，進(jìn)而反向壓制了信源的質(zhì)量，甚至導(dǎo)致?lián)砣臅r而發(fā)生，這樣將會和我們的抗丟包策略設(shè)計的初衷背道而馳。

下行QoS

相比較上行QoS，服務(wù)器在下行QoS可以做的策略可以更多，上文提到了我們的QoS設(shè)計里更多的控制權(quán)是交由發(fā)送方，對于下行QoS服務(wù)器角色便是發(fā)送方。除去抗丟包手段之外，服務(wù)器需要做的幾個重要的QoS相關(guān)的工作在于：

設(shè)計出下行接收端可彈性接收流組合的方案。

準(zhǔn)確的探測出用戶真實(shí)的下行帶寬。

制定合理的帶寬分配方案。

進(jìn)行流量的平滑發(fā)送以及擁塞控制。

下行QoS模塊控制總圖

設(shè)計合理的接收端可彈性接收的方案，是整個下行QoS的設(shè)計基礎(chǔ)。一個完整的擁塞控制系統(tǒng)，其必然要完成兩個基本的工作：

感知當(dāng)前信道的傳輸狀態(tài)，這個狀態(tài)可以是信道的最大帶寬，也可以是當(dāng)前合適傳輸速度。

能夠根據(jù)這個狀態(tài)對發(fā)送信源進(jìn)行調(diào)節(jié)，將信源的碼率控制在可承受范圍之內(nèi)。

所以，對于服務(wù)器端下行擁塞控制而言道理也是一樣。服務(wù)器設(shè)計了多流+SVC的機(jī)制進(jìn)行下行流量的控制。來實(shí)現(xiàn)對下行傳輸鏈路的控制，應(yīng)對于用戶不同的下行狀態(tài)，做到最佳的QoE效果。

多流機(jī)制

我們的多流機(jī)制選取大小雙流的方案，為了給服務(wù)器下行調(diào)節(jié)最大空間，以及考慮實(shí)際體驗效果，這里的大小流的分辨率也不是固定的，會隨著服務(wù)器調(diào)節(jié)的碼率，做彈性的伸縮。針對于多流而言，上行用戶可以根據(jù)自己的網(wǎng)絡(luò)能力做不同流的發(fā)布，下行用戶可以根據(jù)自身的需要以及網(wǎng)絡(luò)帶寬，做符合自身能力的流的訂閱。另外輔助SVC的策略，服務(wù)器可以做到最大的調(diào)節(jié)空間，充分利用用戶的下行網(wǎng)絡(luò)帶寬，做到用戶接收的最佳體驗。這里發(fā)送端彈性分辨率的雙流機(jī)制以及SVC方案，服務(wù)器就不做過多的描述了，感興趣的同學(xué)可以繼續(xù)關(guān)注我們網(wǎng)易云信的相關(guān)技術(shù)分享。

?帶寬探測?

帶寬探測。這個模塊實(shí)現(xiàn)的好壞，直接影響到下行QoS的效果。對于擁塞控制而言，開源的實(shí)現(xiàn)有GCC，PCC，BBR及其他的擁塞控制方法。

網(wǎng)易云信服務(wù)器下行QoS是基于Google的BBR算法，在實(shí)時音視頻場景下做了大量的優(yōu)化，進(jìn)而建立了完整的擁塞控制方案。

選取BBR算法兩個最主要的原因：

基于可測量的準(zhǔn)確帶寬。

算法層面的最大帶寬利用率。

服務(wù)器下行和客戶端上行擁塞控制的本質(zhì)區(qū)別在于，下行要求的帶寬大。客戶端上行可以通過平滑的調(diào)整信源做到最佳的發(fā)送速率，而服務(wù)器只是基于現(xiàn)有上行流的轉(zhuǎn)發(fā)，要做到平滑的信源調(diào)節(jié)非常困難。所以客戶端的擁塞控制一般使用GCC比較多，原因在于GCC更側(cè)重于發(fā)送碼率的動態(tài)調(diào)節(jié)來進(jìn)行擁塞控制。

BBR本身的算法這里就不具體描述了，Webrtc對BBR在實(shí)時音頻場景下的應(yīng)用也有代碼的實(shí)現(xiàn)，處于測試階段。

在網(wǎng)易云信實(shí)際運(yùn)用BBR做下行帶寬探測的時候，我們做了很多優(yōu)化，這里羅列一些筆者認(rèn)為在實(shí)時音場景下，尤其在服務(wù)器端做帶寬探測，BBR建議做相應(yīng)優(yōu)化的點(diǎn)：

Probe_RTT 階段的隱藏弱化

上行網(wǎng)絡(luò)丟包帶寬補(bǔ)償

上行網(wǎng)絡(luò)RTT突變以及高Jitter場景優(yōu)化

下行鏈路抖動以及丟包的優(yōu)化

Padding流量的優(yōu)化

快速上探機(jī)制的實(shí)現(xiàn)

這里的上下行網(wǎng)絡(luò)，是針對于BBR網(wǎng)絡(luò)帶寬探測端而言的。經(jīng)過我們一系列的優(yōu)化，基本將帶寬探測的準(zhǔn)確度做到95%左右。

900kbps + 15% loss + 100jitter

?帶寬分配策略?

帶寬分配模塊要做的事情，其實(shí)就是結(jié)合下行用戶的探測出來的帶寬，以及下行用戶的原有的訂閱關(guān)系，幫用戶智能的選取最佳接收流的組合。在介紹具體介紹帶寬分配策略之前，簡單回顧一下我們下行QoS的設(shè)計基礎(chǔ)，即多流+ SVC的機(jī)制：用戶上行的多流中的每條流都會在發(fā)布的時候把自己的可調(diào)控碼率空間信息，即檔位信息告知發(fā)布訂閱管理器。通過這樣的實(shí)現(xiàn)，服務(wù)器便可制定靈活的帶寬分配方案。

基于此實(shí)現(xiàn)，那么對于服務(wù)器下行接收而言，能做的手段有兩種：

源端無感知的，接收端大小流切換

源端配合的流內(nèi)碼率（檔位）調(diào)整

這兩種手段都交由統(tǒng)一的帶寬分配策略來控制，具體的思路有兩點(diǎn)：

1. 盡可能不去反向壓制發(fā)送端的編碼碼率，在基于可選取的大小流的基礎(chǔ)上做最佳接收流的組合，來匹配用戶下行可實(shí)際接收的帶寬。

2. 反向壓制發(fā)送端編碼碼率需要建立在接收端用戶舉手表決的基礎(chǔ)上進(jìn)行結(jié)果裁定。

?平滑發(fā)送及擁塞控制?

平滑發(fā)送及擁塞控制。前面幾個模塊講的是用戶怎么接收的問題，最終如何控制下行的發(fā)送，交由這個模塊來管理。這個模塊的設(shè)計的每個細(xì)節(jié)和用戶體驗息息相關(guān)。大的思路有如下幾點(diǎn)：

1. 平滑發(fā)送。就平滑發(fā)送而言，我們主要的實(shí)現(xiàn)是創(chuàng)建Pacer對象，在單獨(dú)的發(fā)送線程中，起高精定時器，進(jìn)行發(fā)送的平滑，讓網(wǎng)絡(luò)流量不會在觀察區(qū)間內(nèi)有Burst的現(xiàn)象。

2. 基于流級別的優(yōu)先級策略以及可選擇性發(fā)送策略。緩沖在發(fā)送隊列的流，會有不同的優(yōu)先級。在我們的默認(rèn)設(shè)計里優(yōu)先級順序為 重傳包 > 音頻包 > 大于視頻包 > 被切掉的流 > Padding包。另外也設(shè)計了用戶態(tài)的流的優(yōu)先級?？傮w策略是用戶態(tài)優(yōu)先級最高，然后再參考QoS本身的優(yōu)先級?？蛇x擇性發(fā)送策略的設(shè)計主要基于SVC，觀察Pacer的堆積情況，以及對應(yīng)流的堆積情況，進(jìn)行轉(zhuǎn)發(fā)分層的選取。

3. 擁塞避免。這個模塊的實(shí)現(xiàn)，主要是從BBR帶寬探測模塊獲取建議的發(fā)送碼率，并且嚴(yán)格按照碼率發(fā)送，在某些場景下如真實(shí)媒體數(shù)據(jù)不足的情況，甚至可以減少發(fā)送碼率。當(dāng)然這些行為都能夠讓帶寬探測模塊感知到。

4. 擁塞緩解。這里的擁塞緩解更多是模塊內(nèi)部擁塞狀態(tài)的緩解。主要的方法是通過獲取發(fā)送隊列的堆積情況，來進(jìn)行模塊內(nèi)部擁塞狀態(tài)的判斷。一旦源端超發(fā)或者帶寬分配模塊調(diào)節(jié)沒那么靈敏，導(dǎo)致模塊出現(xiàn)擁塞狀態(tài)。那么就要及時的進(jìn)行堆積的處理，而不是把數(shù)據(jù)放到網(wǎng)絡(luò)上，造成網(wǎng)絡(luò)的擁塞，帶來更多不確定因素。這里堆積判斷，主要基于Trendline 配合絕對Delay的固定閾值。

如圖，在t0時刻，Delay超過了我們的絕對閾值，但是計算出來的Trend并不高，既不是一個持續(xù)擁塞的狀態(tài)，反而它可能是一個擁塞緩解的狀態(tài)。在t1時刻這里我們看到Trend值已經(jīng)很高，而且Delay已經(jīng)超過我們的閾值。那么t1時刻是我們需要進(jìn)行擁塞緩解的時刻。擁塞緩解的具體做法就是根據(jù)流的優(yōu)先級進(jìn)行選擇性的丟棄。所以，在進(jìn)行擁塞緩解的時候，我們判斷擁塞的狀態(tài)一定要嚴(yán)謹(jǐn)，一旦主動代替網(wǎng)絡(luò)丟包，那么用戶體驗肯定會受影響。

平滑發(fā)送及擁塞控制總圖

總? ? 結(jié)

以上從大的框架上講述網(wǎng)易云信搭建的音視頻服務(wù)，在服務(wù)器端實(shí)現(xiàn)的一些QoS方案的介紹，其中細(xì)節(jié)很多，很難一一描述，但往往是細(xì)節(jié)決定最終的通話質(zhì)量。

音視頻通訊本身一個復(fù)雜的通訊系統(tǒng)，本文開頭也提到了，QoS的設(shè)計也只是其中的一環(huán)，想要達(dá)到最佳的通話效果，每個環(huán)節(jié)做到環(huán)節(jié)內(nèi)的最優(yōu)，環(huán)節(jié)間也要建立有效的反饋調(diào)節(jié)機(jī)制。才能將整個端到端的體驗做到最優(yōu)，這樣才能得到用戶的認(rèn)可。

推薦閱讀

《從入門到進(jìn)階｜如何基于WebRTC搭建一個視頻會議》

《開源｜如何開發(fā)一個高性能的redis cluster proxy？》

點(diǎn)擊【閱讀原文】，了解網(wǎng)易云信。

總結(jié)

以上是生活随笔為你收集整理的网易实战分享｜实时音视频会议场景下QoS策略的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。