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

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

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

1 GCC算法綜述

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

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

圖1 GCC算法整體結構

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

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

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

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

圖2 RTCP RR報文結構[5]

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

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

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

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

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

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

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

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

圖4 組間延遲示意圖

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

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)表示網絡信道容量，m(i)表示網絡排隊延遲，v(i)表示零均值噪聲。m(i)即是我們要求得的網絡排隊延遲。通過Kalman Filter可以求得該值。具體計算過程請參考文獻[1][4][6]。

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

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

圖5 過載檢測器偽代碼

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

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

需要注意的是，閥值gamma_1對算法的影響很大，并且閾值gamma_1是自適應性的。如果其是靜態(tài)值，會帶來一系列問題，詳見文獻[4]。所以gamma_1需要動態(tài)調整來達到良好的表現(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)

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

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

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

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

圖8 目標碼率Ar計算公式

當碼率變化趨勢為Increase時，當前碼率為上次碼率乘上系數(shù)1.05；當碼率變化趨勢為Decrease，當前碼率為過去500ms內的最大接收碼率乘上系數(shù)0.85。當碼率變化趨勢為Hold時，當前碼率保持不變。目標碼率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ā)送一次，當Ar(i) < 0.97 * Ar(i-1)時則立即發(fā)送。

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

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

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

目標碼率確定之后，分別設置到Encoder模塊和PacedSender模塊。

4 總結

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

參考文獻

[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