實(shí)時(shí)流媒體應(yīng)用的最大特點(diǎn)是實(shí)時(shí)性坦敌，而延遲是實(shí)時(shí)性的最大敵人酵镜。從媒體收發(fā)端來講隘擎，媒體數(shù)據(jù)的處理速度是造成延遲的重要原因殴穴；而從傳輸角度來講，網(wǎng)絡(luò)擁塞則是造成延遲的最主要原因货葬。網(wǎng)絡(luò)擁塞可能造成數(shù)據(jù)包丟失采幌，也可能造成數(shù)據(jù)傳輸時(shí)間變長，延遲增大宝惰。</br>
擁塞控制是實(shí)時(shí)流媒體應(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ā)送端碼率寝衫。</br>
本文是關(guān)于WebRTC擁塞控制算法GCC的上半部分，主要集中于對算法的理論分析拐邪，力圖對WebRTC的QoS有一個(gè)全面直觀的認(rèn)識慰毅。在下半部分，將深入WebRTC源代碼內(nèi)部扎阶，仔細(xì)分析GCC的實(shí)現(xiàn)細(xì)節(jié)汹胃。</br>
1 GCC算法綜述
</br>
</br>Google關(guān)于GCC的RFC文檔在文獻(xiàn)[1]，該RFC目前處于草案狀態(tài)东臀，還沒有成為IETF的正式RFC着饥。此外，Google陸續(xù)發(fā)布了一系列論文[2][3][4]來論述該算法的實(shí)現(xiàn)細(xì)節(jié)惰赋，以及其在Google Hangouts宰掉、WebRTC等產(chǎn)品中的應(yīng)用。本文主要根據(jù)這些文檔資料，從理論上學(xué)習(xí)GCC算法轨奄。</br>
GCC算法分兩部分：發(fā)送端基于丟包率的碼率控制和接收端基于延遲的碼率控制孟害。如圖1所示。
基于丟包率的碼率控制運(yùn)行在發(fā)送端挪拟，依靠RTCP RR報(bào)文進(jìn)行工作挨务。WebRTC在發(fā)送端收到來自接收端的RTCP RR報(bào)文，根據(jù)其Report Block中攜帶的丟包率信息玉组，動(dòng)態(tài)調(diào)整發(fā)送端碼率As耘子。基于延遲的碼率控制運(yùn)行在接收端球切，WebRTC根據(jù)數(shù)據(jù)包到達(dá)的時(shí)間延遲谷誓，通過到達(dá)時(shí)間濾波器，估算出網(wǎng)絡(luò)延遲m(t)吨凑，然后經(jīng)過過載檢測器判斷當(dāng)前網(wǎng)絡(luò)的擁塞狀況捍歪，最后在碼率控制器根據(jù)規(guī)則計(jì)算出遠(yuǎn)端估計(jì)最大碼率Ar。得到Ar之后鸵钝，通過RTCP REMB報(bào)文返回發(fā)送端糙臼。發(fā)送端綜合As、Ar和預(yù)配置的上下限恩商，計(jì)算出最終的目標(biāo)碼率A变逃，該碼率會作用到Encoder、RTP和PacedSender等模塊怠堪，控制發(fā)送端的碼率揽乱。</br>
2 發(fā)送端基于丟包率的碼率控制
</br>
</br>GCC算法在發(fā)送端基于丟包率控制發(fā)送碼率，其基本思想是：丟包率反映網(wǎng)絡(luò)擁塞狀況粟矿。如果丟包率很小或者為0凰棉，說明網(wǎng)絡(luò)狀況良好，在不超過預(yù)設(shè)最大碼率的情況下陌粹，可以增大發(fā)送端碼率撒犀；反之如果丟包率變大，說明網(wǎng)絡(luò)狀況變差掏秩，此時(shí)應(yīng)減少發(fā)送端碼率或舞。在其它情況下，發(fā)送端碼率保持不變蒙幻。</br>
GCC使用的丟包率根據(jù)接收端RTP接收統(tǒng)計(jì)信息計(jì)算得到映凳，通過RTCP RR報(bào)文中返回給發(fā)送端。RTCP RR報(bào)文統(tǒng)計(jì)接收端RTP接收信息杆煞，如Packet Loss魏宽，Jitter，DLSR等等决乎，如圖2所示：</br>
發(fā)送端收到RTCP RR報(bào)文并解析得到丟包率后队询，根據(jù)圖3公式計(jì)算發(fā)送端碼率：當(dāng)丟包率大于0.1時(shí)，說明網(wǎng)絡(luò)發(fā)生擁塞构诚，此時(shí)降低發(fā)送端碼率蚌斩；當(dāng)丟包率小于0.02時(shí)，說明網(wǎng)絡(luò)狀況良好范嘱，此時(shí)增大發(fā)送端碼率送膳；其他情況下，發(fā)送端碼率保持不變丑蛤。</br>
最終碼率會作用于Encoder叠聋、RTP和PacedSender模塊，用以在編碼器內(nèi)部調(diào)整碼率和平滑發(fā)送端發(fā)送速率受裹。</br>
3 接收端基于延遲的碼率控制
</br>
</br>GCC算法在接收端基于數(shù)據(jù)包到達(dá)延遲估計(jì)發(fā)送碼率Ar碌补，然后通過RTCP REMB報(bào)文反饋到發(fā)送端，發(fā)送端把Ar作為最終目標(biāo)碼率的上限值棉饶。其基本思想是： RTP數(shù)據(jù)包的到達(dá)時(shí)間延遲m(i)反映網(wǎng)絡(luò)擁塞狀況厦章。當(dāng)延遲很小時(shí)，說明網(wǎng)絡(luò)擁塞不嚴(yán)重照藻，可以適當(dāng)增大目標(biāo)碼率袜啃；當(dāng)延遲變大時(shí)，說明網(wǎng)絡(luò)擁塞變嚴(yán)重幸缕，需要減小目標(biāo)碼率群发；當(dāng)延遲維持在一個(gè)低水平時(shí)，目標(biāo)碼率維持不變发乔。</br>
基于延時(shí)的擁塞控制由三個(gè)主要模塊組成：到達(dá)時(shí)間濾波器也物，過載檢查器和速率控制器；除此之外還有過載閾值自適應(yīng)模塊和REMB報(bào)文生成模塊列疗，如圖1所示滑蚯。下面分別論述其工作過程。</br>
3.1 到達(dá)時(shí)間濾波器(Arrival-time Filter)
</br>
</br>該模塊用以計(jì)算相鄰相鄰兩個(gè)數(shù)據(jù)包組的網(wǎng)絡(luò)排隊(duì)延遲m(i)抵栈。數(shù)據(jù)包組定義為一段時(shí)間內(nèi)連續(xù)發(fā)送的數(shù)據(jù)包的集合告材。一系列數(shù)據(jù)包短時(shí)間里連續(xù)發(fā)送，這段時(shí)間稱為突發(fā)時(shí)間古劲，建議突發(fā)時(shí)間為5ms斥赋。不建議在突發(fā)時(shí)間內(nèi)的包間隔時(shí)間做度量，而是把它們做為一組來測量产艾。通過相鄰兩個(gè)數(shù)據(jù)包組的發(fā)送時(shí)間和到達(dá)時(shí)間疤剑，計(jì)算得到組間延遲d (i)滑绒。組間延遲示意圖及計(jì)算公式如圖4所示：</br>
T(i)是第i個(gè)數(shù)據(jù)包組中第一個(gè)數(shù)據(jù)包的發(fā)送時(shí)間，t(i)是第i個(gè)數(shù)據(jù)包組中最后一個(gè)數(shù)據(jù)包的到達(dá)時(shí)間隘膘。幀間延遲通過如下公式計(jì)算得到：</br>
d(i) = t(i) – t(i-1) – (T(i) – T(i-1)) (3.1.1)
公式1.3.1是d(i)的觀測方程疑故。另一方面，d(i)也可由如下狀態(tài)方程得到：</br>
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ò)排隊(duì)延遲，v(i)表示零均值噪聲管钳。m(i)即是我們要求得的網(wǎng)絡(luò)排隊(duì)延遲钦铁。通過Kalman Filter可以求得該值。具體計(jì)算過程請參考文獻(xiàn)[1][4][6]才漆。</br>
3.2 過載檢測器(Over-use Detector)
</br>
</br>該模塊以到達(dá)時(shí)間濾波器計(jì)算得到的網(wǎng)絡(luò)排隊(duì)延遲m(i)為輸入牛曹，結(jié)合當(dāng)前閾值gamma_1，判斷當(dāng)前網(wǎng)絡(luò)是否過載醇滥。判斷算法如圖5所示[2]躏仇。</br>
算法基于當(dāng)前網(wǎng)絡(luò)排隊(duì)延遲m(i)和當(dāng)前閾值gamma_1判斷當(dāng)前網(wǎng)絡(luò)擁塞狀況[2]：當(dāng)m(i) > gamma_1時(shí)，算法計(jì)算處于當(dāng)前狀態(tài)的持續(xù)時(shí)間t(ou) = t(ou) + delta(t)腺办，如果t(ou)大于設(shè)定閾值gamma_2(實(shí)際計(jì)算中設(shè)置為10ms)焰手，并且m(i) > m(i-1)，則發(fā)出網(wǎng)絡(luò)過載信號Overuse怀喉，同時(shí)重置t(ou)书妻。如果m(i)小于m(i-1)，即使高于閥值gamma_1也不需要發(fā)出過載信號躬拢。當(dāng)m(i) < -gamma_1時(shí)躲履，算法認(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菱蔬。算法隨著時(shí)間軸的計(jì)算過程可從圖6中看到篷帅。</br>
需要注意的是，閥值gamma_1對算法的影響很大拴泌，并且閾值gamma_1是自適應(yīng)性的魏身。如果其是靜態(tài)值，會帶來一系列問題蚪腐，詳見文獻(xiàn)[4]箭昵。所以gamma_1需要?jiǎng)討B(tài)調(diào)整來達(dá)到良好的表現(xiàn)。這就是圖1中的Adaptive threshould模塊回季。閾值gamma_1動(dòng)態(tài)更新的公式如下：</br>
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)時(shí)增加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(i-1)時(shí)K(i) = K_d，否則K(i) = K_u诅病。同時(shí)建議gamma_1(i)控制在[6,600]區(qū)間。太小的值會導(dǎo)致探測器過于敏感粥烁。建議增加系數(shù)要大于減少系數(shù)K_u > K_d贤笆。文獻(xiàn)[1]給出的建議值如下：</br>
gamma_1(0) = 12.5 ms
gamma_2 = 10 ms
K_u = 0.01
K_d = 0.00018
3.3 速率控制器(Remote Rate Controller)
</br>
</br>該模塊以過載檢測器給出的當(dāng)前網(wǎng)絡(luò)狀態(tài)s為輸入，首先根據(jù)圖7所示的有限狀態(tài)機(jī)判斷當(dāng)前碼率的變化趨勢讨阻，然后根據(jù)圖8所示的公式計(jì)算目標(biāo)碼率Ar芥永。</br>
當(dāng)前網(wǎng)絡(luò)過載時(shí)，目標(biāo)碼率處于Decrease狀態(tài)钝吮；當(dāng)前網(wǎng)絡(luò)低載時(shí)埋涧，目標(biāo)碼率處于Hold狀態(tài)；當(dāng)網(wǎng)絡(luò)正常時(shí)奇瘦，處于Decrease狀態(tài)時(shí)遷移到Hold狀態(tài)棘催，處于Hold/Increase狀態(tài)時(shí)都遷移到Increase狀態(tài)。當(dāng)判斷出碼率變化趨勢后耳标，根據(jù)圖8所示公式進(jìn)行計(jì)算目標(biāo)碼率醇坝。</br>
當(dāng)碼率變化趨勢為Increase時(shí)，當(dāng)前碼率為上次碼率乘上系數(shù)1.05次坡；當(dāng)碼率變化趨勢為Decrease呼猪，當(dāng)前碼率為過去500ms內(nèi)的最大接收碼率乘上系數(shù)0.85。當(dāng)碼率變化趨勢為Hold時(shí)砸琅，當(dāng)前碼率保持不變宋距。目標(biāo)碼率Ar計(jì)算得到之后，下一步把Ar封裝到REMB報(bào)文中發(fā)送回發(fā)送端症脂。在REMB報(bào)文中谚赎，Ar被表示為Ar = M * 2^Exp，其中M封裝在BR Mantissa域诱篷，占18位沸版；Exp封裝在BR Exp域，占6位兴蒸。REMB報(bào)文是Payload為206的RTCP報(bào)文[7]视粮，格式如圖9所示。</br>
REMB報(bào)文每秒發(fā)送一次橙凳，當(dāng)Ar(i) < 0.97 * Ar(i-1)時(shí)則立即發(fā)送蕾殴。</br>
3.4 發(fā)送端目標(biāo)碼率的確定
</br>
</br>發(fā)送端最終目標(biāo)碼率的確定結(jié)合了基于丟包率計(jì)算得到的碼率As和基于延遲計(jì)算得到的碼率Ar笑撞。此外，在實(shí)際實(shí)現(xiàn)中還會配置目標(biāo)碼率的上限值和下限值钓觉。綜合以上因素茴肥，最終目標(biāo)碼率確定如下：</br>
target_bitrate = max( min( min(As, Ar), Amax), Amin) (3.4.1)
目標(biāo)碼率確定之后，分別設(shè)置到Encoder模塊和PacedSender模塊荡灾。</br>
4 總結(jié)
</br>
</br>本文在廣泛調(diào)研WebRTC GCC算法的相關(guān)RFC和論文的基礎(chǔ)上瓤狐，全面深入學(xué)習(xí)GCC算法的理論分析，以此為契機(jī)力圖對WebRTC的QoS有一個(gè)全面直觀的認(rèn)識批幌。為將來深入WebRTC源代碼內(nèi)部分析GCC的實(shí)現(xiàn)細(xì)節(jié)奠定基礎(chǔ)础锐。</br>
</br>
</br>
參考文獻(xiàn)
</br>
[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的延遲模型.
http://www.reibang.com/p/bb34995c549a
[7] RTCP message for Receiver Estimated Maximum Bitrate. draft-alvestrand-rmcat-remb-03
