【轉載】WebRTC基於GCC的擁塞控制(上) - 算法分析

實時流媒體應用的最大特色是實時性，而延遲是實時性的最大敵人。從媒體收發端來說，媒體數據的處理速度是形成延遲的重要緣由；而從傳輸角度來說，網絡擁塞則是形成延遲的最主要緣由。網絡擁塞可能形成數據包丟失，也可能形成數據傳輸時間變長，延遲增大。

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

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

1 GCC算法綜述

Google關於GCC的RFC文檔在文獻[1]，該RFC目前處於草案狀態，尚未成爲IETF的正式RFC。此外，Google陸續發佈了一系列論文[2][3][4]來論述該算法的實現細節，以及其在Google Hangouts、WebRTC等產品中的應用。本文主要根據這些文檔資料，從理論上學習GCC算法。

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

圖1 GCC算法總體結構

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

2 發送端基於丟包率的碼率控制

GCC算法在發送端基於丟包率控制發送碼率，其基本思想是：丟包率反映網絡擁塞情況。若是丟包率很小或者爲0，說明網絡情況良好，在不超過預設最大碼率的狀況下，能夠增大發送端碼率；反之若是丟包率變大，說明網絡情況變差，此時應減小發送端碼率。在其它狀況下，發送端碼率保持不變。

GCC使用的丟包率根據接收端RTP接收統計信息計算獲得，經過RTCP RR報文中返回給發送端。RTCP RR報文統計接收端RTP接收信息，如Packet Loss，Jitter，DLSR等等，如圖2所示：

圖2 RTCP RR報文結構[5]

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

 

 

最終碼率會做用於Encoder、RTP和PacedSender模塊，用以在編碼器內部調整碼率和平滑發送端發送速率。

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

GCC算法在接收端基於數據包到達延遲估計發送碼率Ar，而後經過RTCP REMB報文反饋到發送端，發送端把Ar做爲最終目標碼率的上限值。其基本思想是： RTP數據包的到達時間延遲m(i)反映網絡擁塞情況。當延遲很小時，說明網絡擁塞不嚴重，能夠適當增大目標碼率；當延遲變大時，說明網絡擁塞變嚴重，須要減少目標碼率；當延遲維持在一個低水平時，目標碼率維持不變。

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

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

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

T(i)是第i個數據包組中第一個數據包的發送時間，t(i)是第i個數據包組中最後一個數據包的到達時間。幀間延遲經過以下公式計算獲得：

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

公式1.3.1是d(i)的觀測方程。另外一方面，d(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(ou) = t(ou) + delta(t)，若是t(ou)大於設定閾值gamma_2(實際計算中設置爲10ms)，而且m(i) > m(i-1)，則發出網絡過載信號Overuse，同時重置t(ou)。若是m(i)小於m(i-1)，即便高於閥值gamma_1也不須要發出過載信號。當m(i) < -gamma_1時，算法認爲當前網絡處於空閒狀態，發出網絡低載信號Underuse。當 – gamma_1 <= m(i) <= gamma_1是，算法認爲當前網絡使用率適中，發出保持信號Hold。算法隨着時間軸的計算過程可從圖6中看到。

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

須要注意的是，閥值gamma_1對算法的影響很大，而且閾值gamma_1是自適應性的。若是其是靜態值，會帶來一系列問題，詳見文獻[4]。因此gamma_1須要動態調整來達到良好的表現。這就是圖1中的Adaptive threshould模塊。閾值gamma_1動態更新的公式以下：

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)爲更新系數，當|m(i)|<gamma_1(i-1)時K(i) = K_d，不然K(i) = K_u。同時建議gamma_1(i)控制在[6,600]區間。過小的值會致使探測器過於敏感。建議增長係數要大於減小系數K_u > K_d。文獻[1]給出的建議值以下：

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

3.3 速率控制器(Remote Rate Controller)

該模塊以過載檢測器給出的當前網絡狀態s爲輸入，首先根據圖7所示的有限狀態機判斷當前碼率的變化趨勢，而後根據圖8所示的公式計算目標碼率Ar。

圖7 目標碼率Ar變化趨勢有限狀態機

 

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

圖8 目標碼率Ar計算公式

 

當碼率變化趨勢爲Increase時，當前碼率爲上次碼率乘上係數1.05；當碼率變化趨勢爲Decrease，當前碼率爲過去500ms內的最大接收碼率乘上係數0.85。當碼率變化趨勢爲Hold時，當前碼率保持不變。目標碼率Ar計算獲得以後，下一步把Ar封裝到REMB報文中發送回發送端。在REMB報文中，Ar被表示爲Ar = M * 2^Exp，其中M封裝在BR Mantissa域，佔18位；Exp封裝在BR Exp域，佔6位。REMB報文是Payload爲206的RTCP報文[7]，格式如圖9所示。

圖9 REMB報文格式

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

3.4 發送端目標碼率的肯定

發送端最終目標碼率的肯定結合了基於丟包率計算獲得的碼率As和基於延遲計算獲得的碼率Ar。此外，在實際實現中還會配置目標碼率的上限值和下限值。綜合以上因素，最終目標碼率肯定以下：

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

目標碼率肯定以後，分別設置到Encoder模塊和PacedSender模塊。

4 總結

本文在普遍調研WebRTC GCC算法的相關RFC和論文的基礎上，全面深刻學習GCC算法的理論分析，以此爲契機力圖對WebRTC的QoS有一個全面直觀的認識。爲未來深刻WebRTC源代碼內部分析GCC的實現細節奠基基礎。

做者：weizhenwei 連接：http://www.jianshu.com/p/0f7ee0e0b3be 來源：簡書 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。