實時流媒體應(yīng)用的最大特點是實時性，而延遲是實時性的最大敵人。從媒體收發(fā)端來講，媒體數(shù)據(jù)的處理速度是造成延遲的重要原因；而從傳輸角度來講，網(wǎng)絡(luò)擁塞則是造成延遲的最主要原因。網(wǎng)絡(luò)擁塞可能造成數(shù)據(jù)包丟失，也可能造成數(shù)據(jù)傳輸時間變長，延遲增大。

擁塞控制是實時流媒體應(yīng)用質(zhì)量保證(QoS)的重要手段之一，它在緩解網(wǎng)絡(luò)擁堵、減小網(wǎng)絡(luò)延遲、平滑數(shù)據(jù)傳輸?shù)荣|(zhì)量保證方面發(fā)揮重要作用。WebRTC通控制發(fā)送端數(shù)據(jù)發(fā)送碼率來達(dá)到控制網(wǎng)絡(luò)擁塞的目的，其采用谷歌提出的擁塞控制算法(Google Congestion Control，簡稱GCC[1])來控制發(fā)送端碼率。

本文是關(guān)于WebRTC擁塞控制算法GCC的上半部分，主要集中于對算法的理論分析，力圖對WebRTC的QoS有一個全面直觀的認(rèn)識。在下半部分，將深入WebRTC源代碼內(nèi)部，仔細(xì)分析GCC的實現(xiàn)細(xì)節(jié)。

1 GCC算法綜述

Google關(guān)于GCC的RFC文檔在文獻(xiàn)[1]，該RFC目前處于草案狀態(tài)，還沒有成為IETF的正式RFC。此外，Google陸續(xù)發(fā)布了一系列論文[2][3][4]來論述該算法的實現(xiàn)細(xì)節(jié)，以及其在Google Hangouts、WebRTC等產(chǎn)品中的應(yīng)用。本文主要根據(jù)這些文檔資料，從理論上學(xué)習(xí)GCC算法。

GCC算法分兩部分：發(fā)送端基于丟包率的碼率控制和接收端基于延遲的碼率控制。如圖1所示。

圖1 GCC算法整體結(jié)構(gòu)

基于丟包率的碼率控制運行在發(fā)送端，依靠RTCP RR報文進(jìn)行工作。WebRTC在發(fā)送端收到來自接收端的RTCP RR報文，根據(jù)其Report Block中攜帶的丟包率信息，動態(tài)調(diào)整發(fā)送端碼率As?；谘舆t的碼率控制運行在接收端，WebRTC根據(jù)數(shù)據(jù)包到達(dá)的時間延遲，通過到達(dá)時間濾波器，估算出網(wǎng)絡(luò)延遲m(t)，然后經(jīng)過過載檢測器判斷當(dāng)前網(wǎng)絡(luò)的擁塞狀況，最后在碼率控制器根據(jù)規(guī)則計算出遠(yuǎn)端估計最大碼率Ar。得到Ar之后，通過RTCP REMB報文返回發(fā)送端。發(fā)送端綜合As、Ar和預(yù)配置的上下限，計算出最終的目標(biāo)碼率A，該碼率會作用到Encoder、RTP和PacedSender等模塊，控制發(fā)送端的碼率。

2 發(fā)送端基于丟包率的碼率控制

GCC算法在發(fā)送端基于丟包率控制發(fā)送碼率，其基本思想是：丟包率反映網(wǎng)絡(luò)擁塞狀況。如果丟包率很小或者為0，說明網(wǎng)絡(luò)狀況良好，在不超過預(yù)設(shè)最大碼率的情況下，可以增大發(fā)送端碼率；反之如果丟包率變大，說明網(wǎng)絡(luò)狀況變差，此時應(yīng)減少發(fā)送端碼率。在其它情況下，發(fā)送端碼率保持不變。

GCC使用的丟包率根據(jù)接收端RTP接收統(tǒng)計信息計算得到，通過RTCP RR報文中返回給發(fā)送端。RTCP RR報文統(tǒng)計接收端RTP接收信息，如Packet Loss，Jitter，DLSR等等，如圖2所示：

圖2 RTCP RR報文結(jié)構(gòu)[5]

發(fā)送端收到RTCP RR報文并解析得到丟包率后，根據(jù)圖3公式計算發(fā)送端碼率：當(dāng)丟包率大于0.1時，說明網(wǎng)絡(luò)發(fā)生擁塞，此時降低發(fā)送端碼率；當(dāng)丟包率小于0.02時，說明網(wǎng)絡(luò)狀況良好，此時增大發(fā)送端碼率；其他情況下，發(fā)送端碼率保持不變。

圖3 GCC基于丟包率的碼率計算公式[4]

最終碼率會作用于Encoder、RTP和PacedSender模塊，用以在編碼器內(nèi)部調(diào)整碼率和平滑發(fā)送端發(fā)送速率。

3 接收端基于延遲的碼率控制

GCC算法在接收端基于數(shù)據(jù)包到達(dá)延遲估計發(fā)送碼率Ar，然后通過RTCP REMB報文反饋到發(fā)送端，發(fā)送端把Ar作為最終目標(biāo)碼率的上限值。其基本思想是： RTP數(shù)據(jù)包的到達(dá)時間延遲m(i)反映網(wǎng)絡(luò)擁塞狀況。當(dāng)延遲很小時，說明網(wǎng)絡(luò)擁塞不嚴(yán)重，可以適當(dāng)增大目標(biāo)碼率；當(dāng)延遲變大時，說明網(wǎng)絡(luò)擁塞變嚴(yán)重，需要減小目標(biāo)碼率；當(dāng)延遲維持在一個低水平時，目標(biāo)碼率維持不變。

基于延時的擁塞控制由三個主要模塊組成：到達(dá)時間濾波器，過載檢查器和速率控制器；除此之外還有過載閾值自適應(yīng)模塊和REMB報文生成模塊，如圖1所示。下面分別論述其工作過程。

3.1 到達(dá)時間濾波器(Arrival-time Filter)

該模塊用以計算相鄰相鄰兩個數(shù)據(jù)包組的網(wǎng)絡(luò)排隊延遲m(i)。數(shù)據(jù)包組定義為一段時間內(nèi)連續(xù)發(fā)送的數(shù)據(jù)包的集合。一系列數(shù)據(jù)包短時間里連續(xù)發(fā)送，這段時間稱為突發(fā)時間，建議突發(fā)時間為5ms。不建議在突發(fā)時間內(nèi)的包間隔時間做度量，而是把它們做為一組來測量。通過相鄰兩個數(shù)據(jù)包組的發(fā)送時間和到達(dá)時間，計算得到組間延遲d (i)。組間延遲示意圖及計算公式如圖4所示：

圖4 組間延遲示意圖

T(i)是第i個數(shù)據(jù)包組中第一個數(shù)據(jù)包的發(fā)送時間，t(i)是第i個數(shù)據(jù)包組中最后一個數(shù)據(jù)包的到達(dá)時間。幀間延遲通過如下公式計算得到：

d(i)?=?t(i)?–?t(i-1)?–?(T(i)?–?T(i-1))????(3.1.1)

公式1.3.1是d(i)的觀測方程。另一方面，d(i)也可由如下狀態(tài)方程得到：

d(i)?=?dL(i)/C(i)?+?w(i)??????????????????(3.1.2)
d(i)?=?dL(i)/C(i)?+?m(i)?+?v(i)???????????(3.1.3)

其中dL(i)表示相鄰兩幀的長度差，C(i)表示網(wǎng)絡(luò)信道容量，m(i)表示網(wǎng)絡(luò)排隊延遲，v(i)表示零均值噪聲。m(i)即是我們要求得的網(wǎng)絡(luò)排隊延遲。通過Kalman Filter可以求得該值。具體計算過程請參考文獻(xiàn)[1][4][6]。

3.2 過載檢測器(Over-use Detector)

該模塊以到達(dá)時間濾波器計算得到的網(wǎng)絡(luò)排隊延遲m(i)為輸入，結(jié)合當(dāng)前閾值gamma_1，判斷當(dāng)前網(wǎng)絡(luò)是否過載。判斷算法如圖5所示[2]。

圖5 過載檢測器偽代碼

算法基于當(dāng)前網(wǎng)絡(luò)排隊延遲m(i)和當(dāng)前閾值gamma_1判斷當(dāng)前網(wǎng)絡(luò)擁塞狀況[2]：當(dāng)m(i) > gamma_1時，算法計算處于當(dāng)前狀態(tài)的持續(xù)時間t(ou) = t(ou) + delta(t)，如果t(ou)大于設(shè)定閾值gamma_2(實際計算中設(shè)置為10ms)，并且m(i) > m(i-1)，則發(fā)出網(wǎng)絡(luò)過載信號Overuse，同時重置t(ou)。如果m(i)小于m(i-1)，即使高于閥值gamma_1也不需要發(fā)出過載信號。當(dāng)m(i) < -gamma_1時，算法認(rèn)為當(dāng)前網(wǎng)絡(luò)處于空閑狀態(tài)，發(fā)出網(wǎng)絡(luò)低載信號Underuse。當(dāng) – gamma_1 <= m(i) <= gamma_1是，算法認(rèn)為當(dāng)前網(wǎng)絡(luò)使用率適中，發(fā)出保持信號Hold。算法隨著時間軸的計算過程可從圖6中看到。

圖6 時間軸上的過載檢測過程

需要注意的是，閥值gamma_1對算法的影響很大，并且閾值gamma_1是自適應(yīng)性的。如果其是靜態(tài)值，會帶來一系列問題，詳見文獻(xiàn)[4]。所以gamma_1需要動態(tài)調(diào)整來達(dá)到良好的表現(xiàn)。這就是圖1中的Adaptive threshould模塊。閾值gamma_1動態(tài)更新的公式如下：

gamma_1(i)?=?gamma_1(i-1)?+?(t(i)-t(i-1))?*?K(i)?*?(|m(i)|-gamma_1(i-1))????(3.2.4)

當(dāng)|m(i)|>gamma_1(i-1)時增加gamma_1(i)，反之減小gamma_1(i)，而當(dāng)|m(i)|– gamma_1(i) >15，建議gamma_1(i)不更新。K(i)為更新系數(shù)，當(dāng)|m(i)|

gamma_1(0)?=?12.5?ms
gamma_2??=?10?ms
K_u?=?0.01
K_d?=?0.00018

3.3 速率控制器(Remote Rate Controller)

該模塊以過載檢測器給出的當(dāng)前網(wǎng)絡(luò)狀態(tài)s為輸入，首先根據(jù)圖7所示的有限狀態(tài)機(jī)判斷當(dāng)前碼率的變化趨勢，然后根據(jù)圖8所示的公式計算目標(biāo)碼率Ar。

圖7 目標(biāo)碼率Ar變化趨勢有限狀態(tài)機(jī)

當(dāng)前網(wǎng)絡(luò)過載時，目標(biāo)碼率處于Decrease狀態(tài)；當(dāng)前網(wǎng)絡(luò)低載時，目標(biāo)碼率處于Hold狀態(tài)；當(dāng)網(wǎng)絡(luò)正常時，處于Decrease狀態(tài)時遷移到Hold狀態(tài)，處于Hold/Increase狀態(tài)時都遷移到Increase狀態(tài)。當(dāng)判斷出碼率變化趨勢后，根據(jù)圖8所示公式進(jìn)行計算目標(biāo)碼率。

圖8 目標(biāo)碼率Ar計算公式

當(dāng)碼率變化趨勢為Increase時，當(dāng)前碼率為上次碼率乘上系數(shù)1.05；當(dāng)碼率變化趨勢為Decrease，當(dāng)前碼率為過去500ms內(nèi)的最大接收碼率乘上系數(shù)0.85。當(dāng)碼率變化趨勢為Hold時，當(dāng)前碼率保持不變。目標(biāo)碼率Ar計算得到之后，下一步把Ar封裝到REMB報文中發(fā)送回發(fā)送端。在REMB報文中，Ar被表示為Ar = M * 2^Exp，其中M封裝在BR Mantissa域，占18位；Exp封裝在BR Exp域，占6位。REMB報文是Payload為206的RTCP報文[7]，格式如圖9所示。

圖9 REMB報文格式

REMB報文每秒發(fā)送一次，當(dāng)Ar(i) < 0.97 * Ar(i-1)時則立即發(fā)送。

3.4 發(fā)送端目標(biāo)碼率的確定

發(fā)送端最終目標(biāo)碼率的確定結(jié)合了基于丟包率計算得到的碼率As和基于延遲計算得到的碼率Ar。此外，在實際實現(xiàn)中還會配置目標(biāo)碼率的上限值和下限值。綜合以上因素，最終目標(biāo)碼率確定如下：

????target_bitrate?=?max(?min(?min(As,?Ar),?Amax),?Amin)????????(3.4.1)

目標(biāo)碼率確定之后，分別設(shè)置到Encoder模塊和PacedSender模塊。

4 總結(jié)

本文在廣泛調(diào)研WebRTC GCC算法的相關(guān)RFC和論文的基礎(chǔ)上，全面深入學(xué)習(xí)GCC算法的理論分析，以此為契機(jī)力圖對WebRTC的QoS有一個全面直觀的認(rèn)識。為將來深入WebRTC源代碼內(nèi)部分析GCC的實現(xiàn)細(xì)節(jié)奠定基礎(chǔ)。

參考文獻(xiàn)

[1] A Google Congestion Control Algorithm for Real-Time Communication.
draft-alvestrand-rmcat-congestion-03
[2] Understanding the Dynamic Behaviour of the Google Congestion Control for RTCWeb.
[3] Experimental Investigation of the Google Congestion Control for Real-Time Flows.
[4] Analysis and Design of the Google Congestion Control for Web Real-time Communication (WebRTC). MMSys’16, May 10-13, 2016, Klagenfurt, Austria
[5] RFC3550: RTP - A Transport Protocol for Real-Time Applications
[6] WebRTC視頻接收緩沖區(qū)基于KalmanFilter的延遲模型.
[7] RTCP message for Receiver Estimated Maximum Bitrate. draft-alvestrand-rmcat-remb-03