網(wǎng)絡(luò)的波動帶來的卡頓直接影響著用戶的體驗，在WebRTC中設(shè)計了一套基于延遲和丟包反饋的擁塞機制（GCC）和帶寬調(diào)節(jié)策略來保證延遲、質(zhì)量和網(wǎng)路速度之間平衡。

在視頻通信的技術(shù)領(lǐng)域WebRTC已成為主流的技術(shù)標準，WebRTC包涵了諸多優(yōu)秀的技術(shù)，譬如：音頻數(shù)字信號處理技術(shù)（AEC, NS, AGC）、編解碼技術(shù)、實時傳輸技術(shù)、P2P技術(shù)等，這些技術(shù)目的都是為了實現(xiàn)更好實時音視頻方案。但是在高分辨率視頻通信過程中，通信時延、圖像質(zhì)量下降和丟包卡頓是經(jīng)常發(fā)生的事，甚至在WiFi環(huán)境下，一次視頻重發(fā)的網(wǎng)絡(luò)風(fēng)暴可以引起WiFi網(wǎng)絡(luò)間歇性中斷，通信延遲和圖像質(zhì)量之間存在的排斥關(guān)系是實時視頻過程中的主要矛盾。

分析WebRTC是如何解決這個矛盾之前，先來看看我們在在線教育互動的生產(chǎn)環(huán)境統(tǒng)計到的視頻延遲和人感官的關(guān)系，大致如下：

也就是說，通信過程中最好將視頻延遲控制在800毫秒以內(nèi)。除了延遲，視頻圖像質(zhì)量也是個對人感官產(chǎn)生差異的關(guān)鍵因素，我們以640x480分辨率每秒24幀的H264編碼情況下視頻碼率和人感官之間的關(guān)系（這組數(shù)據(jù)是我們通過小范圍線上用戶投票打分的數(shù)據(jù)）：

從上面的描述可以知道視頻質(zhì)量保持在一個可讓人接受的質(zhì)量范圍是需要比較大的帶寬碼率支持的，如果加上控制延遲，則更需要網(wǎng)絡(luò)有很好速度和穩(wěn)定性。但是很不幸，我們現(xiàn)階段的移動網(wǎng)絡(luò)和家用WiFi并不是我們想象中的那么好，很難做到在實時視頻通信中一個讓人非常滿意的程度。為了解決以上幾個問題，WebRTC設(shè)計了一套基于延遲和丟包反饋的擁塞機制（GCC）和帶寬調(diào)節(jié)策略來保證延遲、質(zhì)量和網(wǎng)路速度之間平衡，這是一個持續(xù)循環(huán)過程，如下圖：

圖1：擁塞控制循環(huán)示意圖

1）estimator通過RTCP的feedback反饋過來的包到達延遲增量和丟包率信息計算出網(wǎng)絡(luò)擁塞狀態(tài)并評估出適合當(dāng)前網(wǎng)絡(luò)傳輸?shù)拇a率，根據(jù)這個碼率改變視頻編碼器碼率，然后改變pacer的碼率

2）pacer會根據(jù)這個碼率改變pacer的網(wǎng)絡(luò)發(fā)送速度和padding比例，并用新的網(wǎng)絡(luò)發(fā)送速度來定時觸發(fā)發(fā)包事件。

3）sender收到pacer的發(fā)送事件，進行RTP報文發(fā)送。

4）receiver接收到RTP報文，進行arrival time統(tǒng)計和丟包統(tǒng)計

5）feedback定時對receiver統(tǒng)計的信息進行RTCP編碼，并反饋到發(fā)送端的estimator進行新一輪的碼率評估。

以上是整個WebRTC擁塞控制和帶寬調(diào)節(jié)過程，下面這個示意圖是這個過程涉及到WebRTC內(nèi)部模塊關(guān)系。

圖2：WebRTC的擁塞控制模塊關(guān)系圖

需要說明的是紅框中基于接收端的kalman filter帶寬評估模型已經(jīng)在新版本的WebRTC中不采用了，只做了向前版本兼容，新版本的WebRTC都是采用發(fā)送端的trendline濾波器來做延遲帶寬評估，本文中重點是介紹基于trendline濾波的評估模型，下面依次來分析WebRTC的這五個過程。

1 estimator

estimator的功能就是通過接收端反饋過來的包到達時刻信息、丟包信息和REMB信息進行當(dāng)前網(wǎng)絡(luò)狀態(tài)的碼率評估，WebRTC擁塞控制有兩部分：基于延遲的擁塞控制和基于丟包的擁塞控制，它是一個盡力而為的擁塞控制算法，犧牲了擁塞控制的公平性換取盡量大的吞吐量。從設(shè)計結(jié)構(gòu)來描述向它輸入延遲和丟包信息，它就會輸出一個適應(yīng)當(dāng)前網(wǎng)絡(luò)狀態(tài)的碼率值。示意圖如下：

圖3：WebRTC的CC estimator輸入與輸出

從上圖可以看出，estimator基于延遲的擁塞控制是通過trendline濾波再進行過載判斷，最后根據(jù)過載情況進行aimd碼率調(diào)控評估出一個bwe bitrate碼率，這個碼率會合丟包評估出來的碼率和remb來決定最后的碼率。

1.1 基于延遲的擁塞控制

基于延遲的擁塞控制是通過每組包的到達時間的延遲差（delta delay）的增長趨勢來判斷網(wǎng)絡(luò)是否過載，如果過載進行碼率下調(diào)，如果處于平衡范圍維持當(dāng)前碼率，如果是網(wǎng)絡(luò)承載不飽滿進行碼率上調(diào)。這里有幾個關(guān)鍵技術(shù):包組延遲評估、濾波器趨勢判斷、過載檢測和碼率調(diào)節(jié)。

1.1.1 包組與延遲

WebRTC在評估延遲差的時候不是對每個包進行估算，而是采用了包組間進行延遲評估，這符合視頻傳輸（視頻幀是需要切分成多個UDP包）的特點，也減少了頻繁計算帶來的誤差。那么什么是包組呢？就是距包組中第一個包的發(fā)送時刻t0小于5毫秒發(fā)送的所有的包成為一組，第一個超過5毫秒的包作為下一個包組第一個包。為了更好的說明包組和延遲間的關(guān)系，先來看示意圖：

圖4：包組與延遲示意圖

上圖中有兩個包組G1和G2, 其中第100號包與103號包的時間差小于5毫秒，那么100 ~ 103被劃作一個包組。104與100之間時間超過5毫秒，那么104就是G2的第一個包，它與105、106、107劃作一個包組。知道了包組的概念，那么我們怎么通過包組的延遲信息得到濾波器要的評估參數(shù)呢？濾波器需要的三個參數(shù)：發(fā)送時刻差值（delta_timestamp）、到達時刻差值(delta_arrival)和包組數(shù)據(jù)大小差值(delta_size)。從上圖可以得出：

1.1.2 濾波器

我們通過包組信息計算到了delta_timestamp、delta_arrival和delta_size,那么下一步就是進行數(shù)據(jù)濾波來評估延遲增長趨勢。在WebRTC實現(xiàn)了兩種濾波器來進行延遲增長趨勢的評估，分別是：kalman filter和trendline filter, 從圖2中我們知道kalman filter是運行在接收端的，我在這里以不做介紹，有興趣的可以參考https://www.jianshu.com/p/bb34995c549a。

這里介紹trendline filter，我們知道如果平穩(wěn)網(wǎng)速下傳輸數(shù)據(jù)的延遲時間就是數(shù)據(jù)大小除以速度，如果這數(shù)據(jù)塊很大，超過恒定網(wǎng)速下延遲上限，這意味著要它要占用其他后續(xù)數(shù)據(jù)塊的傳輸時間，那么如此往復(fù)，網(wǎng)絡(luò)就產(chǎn)生了延遲和擁塞。Trendline filter通過到達時間差、發(fā)送時間差和數(shù)據(jù)大小來得到一個趨勢增長值，如果這個值越大說明網(wǎng)絡(luò)延遲越來越嚴重，如果這個值越小，說明延遲逐步下降。以下是計算這個值的過程。

先計算單個包組傳輸增長的延遲，可以記作：

然后做每個包組的疊加延遲,可以記作：

在通過累積延遲計算一個均衡平滑延遲值，alpha=0.9可以記作：

然后統(tǒng)一對累計延遲和均衡平滑延遲再求平均，分別記作：

我們將第i個包組的傳輸持續(xù)時間記作:

趨勢斜率分子值為：

趨勢斜率分母值為：

最終的趨勢值為：

1.1.3過載檢測

在計算得到trendline值后WebRTC通過動態(tài)閾值gamma_1進行判斷擁塞程度，trendline乘以周期包組個數(shù)就是m_i,以下是判斷擁塞程度的偽代碼：

通過以上偽代碼就可以判斷出當(dāng)前網(wǎng)絡(luò)負載狀態(tài)是否發(fā)生了過載，如果發(fā)生過載，WebRTC是通過一個有限狀態(tài)機來進行網(wǎng)絡(luò)狀態(tài)遷徙，關(guān)于狀態(tài)機細節(jié)可以參看下圖：

圖5:過載檢測狀態(tài)機

從上圖可以看出，網(wǎng)絡(luò)狀態(tài)機的狀態(tài)遷徙是由于網(wǎng)絡(luò)過載狀態(tài)發(fā)生了變化，所以狀態(tài)遷徙作為了aimd帶寬調(diào)節(jié)的觸發(fā)事件，aimd根據(jù)當(dāng)前所處的網(wǎng)絡(luò)狀態(tài)進行帶寬調(diào)節(jié)，其過程是處于Hold狀態(tài)表示維持當(dāng)前碼率，處于Decr狀態(tài)表示需要進行碼率遞減，處于Incr狀態(tài)需要進行碼率遞增。那他們是怎么遞增和遞減的呢？WebRTC引入了aimd算法解決這個問題。

1.1.4 AIMD碼率調(diào)節(jié)

aimd的全稱是Additive Increase Multiplicative Decrease，意思是：和式增加，積式減少。aimd controller是TCP底層的碼率調(diào)節(jié)概念，但是WebRTC并沒有完全照搬TCP的機制，而是設(shè)計了套自己的算法，用公式表示為：

如果處于Incr狀態(tài)，增加碼率的方式分為兩種：一種是通信會話剛剛開始，相當(dāng)于TCP慢啟動，它會進行一個倍數(shù)增加，當(dāng)前使用的碼率乘以系數(shù)，系數(shù)是1.08；如果是持續(xù)在通信狀態(tài)，其增加的碼率值是當(dāng)前碼率在一個RTT時間周期所能傳輸?shù)臄?shù)據(jù)速率。

如果處于Decrease狀態(tài)，遞減原則是:過去500ms時間窗內(nèi)的最大acked bitrate乘上系數(shù)0.85,acked bitrate通過feedback反饋過來的報文序號查找本地發(fā)送列表就可以得到。

aimd根據(jù)上面的規(guī)則最終計算到的碼率就是基于延遲擁塞評估到的bwe bitrate碼率。

1.2基于丟包的擁塞控制

除了延遲因素外，WebRTC還會根據(jù)網(wǎng)絡(luò)的丟包率進行擁塞控制碼率調(diào)節(jié)，描述如下：

解釋下上面的公式：

當(dāng)丟包率>2%時，這個時候會將碼率（base bitrate）增長5%,這個碼率(base bitrate)并不是當(dāng)前及時碼率，而是單位時間窗周期內(nèi)出現(xiàn)的最小碼率,WebRTC將這個時間窗周期設(shè)置在1000毫秒內(nèi)。因為loss fraction是從接收端反饋過來的，中間會有時間差，這樣做的目的是防止網(wǎng)絡(luò)間歇性統(tǒng)計造成的網(wǎng)絡(luò)碼率增長過快而網(wǎng)絡(luò)反復(fù)波動。

當(dāng) 2% < 丟包率 < 10%,維持當(dāng)前的碼率值

當(dāng) 丟包率 >= 10%, 按丟包率進行當(dāng)前碼率遞減，等到新的碼率值

丟包率決策出來的碼率（base bitrate）只是一個參考值，WebRTC實際采用的帶寬是base bitrate、remb bitrate和bwe bitrate中的最小值，這個最小值作為estimator最終評估出來的碼率

2 pacer

在estimator根據(jù)網(wǎng)絡(luò)狀態(tài)決策出新的通信碼率（target bitrate），它會將這個碼率設(shè)置到pacer當(dāng)中，要求pacer按照新的碼率來計算發(fā)包頻率。因為在視頻通信中，單幀視頻可能有上百KB,如果是當(dāng)視頻幀被編碼器編碼出來后，就立即進行RTP打包發(fā)送，瞬時會發(fā)送大量的數(shù)據(jù)到網(wǎng)絡(luò)上，可能會引起網(wǎng)絡(luò)衰減和通信惡化。WebRTC引入pacer，pacer會根據(jù)estimator評估出來的碼率，按照最小單位時間（5ms）做時間分片進行遞進發(fā)送數(shù)據(jù)，避免瞬時對網(wǎng)絡(luò)的沖擊。pacer的目的就是讓視頻數(shù)據(jù)按照評估碼率均勻的分布在各個時間片里發(fā)送，所以在弱網(wǎng)的WiFi環(huán)境，pacer是個非常重要的關(guān)鍵步驟。以下WebRTC中pacer的模型關(guān)系：

圖6：pacer模型圖

WebRTC中pacer的流程比較清晰，分為三步：

1）如果一幀圖像被編碼和RTP切分打包后，先會將RTP報文存在待發(fā)送的隊列中，并將報文元數(shù)據(jù)(packet id, size, timestamp, 重傳標示)送到pacer queue進行排隊等待發(fā)送，插入隊列的元數(shù)據(jù)會進行優(yōu)先級排序。

2）pacer timer會觸發(fā)一個定時任務(wù)事件來計算budget，budget會算出當(dāng)前時間片網(wǎng)絡(luò)可以發(fā)送多少數(shù)據(jù)，然后從pacer queue當(dāng)中取出報文元數(shù)據(jù)進行網(wǎng)絡(luò)發(fā)送。

3）如果pacer queue沒有更多待發(fā)送的報文，但budget卻還可以發(fā)送更多的數(shù)據(jù)，這個時候pacer會進行padding報文補充。

從上面的步驟描述中可以看出pacer有幾個關(guān)鍵技術(shù)：pace queue、padding、budget。

2.1 pace queue與優(yōu)先級

pace queue是一個基于優(yōu)先級排序的多維鏈表，它并不是一個先進先出的fifo,而是一個按優(yōu)先級排序的list。

報文優(yōu)先級規(guī)則

1）優(yōu)先級高的報文排在fifo的前面，低的排在后面。

2）優(yōu)先級是最先判斷報文的QoS等級，等級越小的優(yōu)先級越高

3）其次是判斷重發(fā)標示，重發(fā)的報文比普通報文的優(yōu)先級更高

4）再次是判斷視頻幀timestamp，越早的視頻幀優(yōu)先級更高。

pacer每次觸發(fā)發(fā)送事件時是先從queue的最前面取出優(yōu)先級最高的報文進行發(fā)送，這樣做的目的是讓視頻在傳輸?shù)倪^程中延遲盡量小，重傳的報文盡快能到達防止等待卡頓。pace queue還可以設(shè)置最大延遲，如果超過最大延遲，會計算queue中數(shù)據(jù)發(fā)送所需要的碼率，并且會把這個碼率替代target bitrate作為budget參考碼率來加速發(fā)送。

2.2 budget

budget是個評估單位時間內(nèi)可以發(fā)送多少數(shù)據(jù)量的一個機制，因為pacer是會根據(jù)pace timer定時來觸發(fā)發(fā)送檢查。Budget會根據(jù)評估出來的參考碼率計算這次定時事件能發(fā)送多少字節(jié)，可以表示為：

delta time是上次檢查時間點和這次檢查時間點的時間差。

target bitrate是pacer的參考碼率，是由estimator根據(jù)網(wǎng)絡(luò)狀態(tài)評估出來的。

remain_bytes每次觸發(fā)發(fā)包時會減去發(fā)送報文的長度size,如果remain_bytes > 0，繼續(xù)從pace queue中取下一個報文進行發(fā)送，直到remain_bytes <=0 或者 pace queue沒有更多的報文。

2.3 pacer延遲

那么肯定有人會有疑問pacer queue和budget進定量計算來發(fā)送網(wǎng)絡(luò)報文，相當(dāng)于cache等待發(fā)送，難道不會引起延遲嗎？可以肯定的說會引起延遲，但延遲不嚴重。pacer產(chǎn)生的延遲可以表示為：

假如評估出來的碼率是10mbps, 一個視頻關(guān)鍵幀的大小是300KB,那么這個關(guān)鍵幀造成的pacer delay是240毫秒。從實際應(yīng)用觀察到的關(guān)鍵幀引起的pace delay在200 ~ 400毫秒之間，這個值相對于視頻傳輸來說是比較大的，但是不嚴重。WebRTC為了減少這個延遲，會評估出盡量大的bitrate。那么怎么評估出盡量大的碼率呢？從前面的estimator描述中我們知道要發(fā)送出盡量多的數(shù)據(jù)才能評估盡量大的碼率，但是視頻編碼器不會發(fā)送多余的數(shù)據(jù)，所以WebRTC引入了padding機制來保障發(fā)送盡量大的數(shù)據(jù)來探測網(wǎng)絡(luò)帶寬上限。

2.4 padding

pace padding除了保障能pace delay盡量小外，它可以讓有限的帶寬獲得盡可能好的視頻質(zhì)量。padding的工作原理很簡單，就是在單位時間片內(nèi)把budget還剩余的空閑用padding數(shù)據(jù)填滿。我個人認為padding只是適合點對點通信，一旦涉及到多點分發(fā)，會因為padding占用很多服務(wù)轉(zhuǎn)發(fā)帶寬，這并不是一件好事情。

3 sender

WebRTC的發(fā)送模塊和擁塞控制控制相關(guān)的主要是增加了附加的RTP擴展來攜帶便宜接收端統(tǒng)計丟包率和延遲間隔的信息、配合pacer的發(fā)包策略、帶寬分配和FEC策略的信息。

3.1 RTP擴展

WebRTC為了配合接收端進行延遲包序列和丟包統(tǒng)計做了下列擴展：

transport sequence傳輸通道的只增sequence，每次發(fā)送報文時自增長，配合接收端統(tǒng)計丟包、通過反饋這個sequence可以計算得到發(fā)包的時刻。

TransmissionOffset 發(fā)送報文的相對時刻，這個相對時刻值t是發(fā)送報文的絕對時刻T1和視頻幀時間戳T0差值。早期的WebRTC是在接收端進行estimate bitrate，所以過載判斷是在接收端完成的，這個值就是為了kalman filter計算發(fā)包造成的延遲用的，新版本還攜帶這個值以便低版本的WebRTC能兼容。

3.2 packet cache

packet cache是一個key/value結(jié)構(gòu)的包緩沖池，視頻幀在進行RTP分片打包后不會立即發(fā)送出去，而是要等待pacer的發(fā)送信號進行發(fā)送。所以打包后會按[id,packet]鍵值對插入到packet cache中。一般packet cache會保存600個分片報文，最大9600個，插入新的會將最舊的報文刪除，packet cache這樣做的目的除了配合pacer發(fā)送外，也為了后面響應(yīng)nack的丟包重傳。

3.3 NACK與丟包重傳

圖7:RTP NACK過程的示意圖

WebRTC在評估到收發(fā)端之間RTT延遲比較小的時候會采用NACK來進行丟包補償，NACK是一個請求重發(fā)過程，其流程如上圖所示。這個過程有一個問題是在網(wǎng)絡(luò)抖動和丟包很厲害的情況下有可能造成同一時刻收到很多NACK的重傳請求，發(fā)送端瞬間把這些重傳請求放入pacer中進行重發(fā)，這樣pacer的延遲會增大，而且pace的參考碼率會隨著pace queue的延遲控制變的很大而出現(xiàn)間歇性網(wǎng)絡(luò)風(fēng)暴。WebRTC在處理NACK重傳時設(shè)計了一個重傳碼率控制器,其設(shè)計原理是通過統(tǒng)計單位時間窗口周期中發(fā)送的字節(jié)數(shù)據(jù)來限流，如果這個時間窗內(nèi)發(fā)送的數(shù)據(jù)的碼率大于estimator評估的碼率，不進行當(dāng)前NACK請求的重傳，等待下一個NACK。

3.4 FEC與碼率分配

WebRTC應(yīng)對丟包時除了NACK方式，在收發(fā)端之間RTT很大時候會開啟FEC來進行丟包補償，我們在這里不介紹FEC具體算法，只介紹FEC的碼率分配策略。從整個通信機制我們很容易得出這樣一個共識：

FEC bitrate到底應(yīng)該設(shè)置多大呢？它先根據(jù)feedback中反饋過來的丟包率(loss fraction)來確定使用哪一種FEC，在根據(jù)每中FEC和丟包率來確定FEC使用的碼率，但需要滿足一下條件:

feedback的碼率被設(shè)定為target bitrate的5%,WebRTC是通過控制feekback的頻率來進行調(diào)控分配的。padding bitrate是通過pacer queue和budget來控制的。Target bitrate減去這些碼率之和就是給視頻編碼器的碼率。每次estimator評估出來碼率后，會先進行這些計算得到最后的video bitrate,并將這個值作為編碼器的編碼碼率，以此來達到防止擁塞的目的。

4 receiver

receiver模塊的工作相對來說比較簡單，它就做三件事情:記錄每個報文的到達時刻(arrival timestamp)、丟包率(lost fraction)和receiver bitrate。早期的WebRTC提供了圖2紅框當(dāng)中kalman filter評估碼率的評估器，因為kalman filter怕抖動特性且需要借助remb心跳進行反饋，remb的反饋周期是1秒，在收發(fā)端網(wǎng)絡(luò)間歇性斷開或者大抖動下，容易失效，所以WebRTC采用了在發(fā)送端進行估算，整個邏輯也更加簡便。

4.1 報文到達時間

圖8：到達報文統(tǒng)計圖

上圖是一個統(tǒng)計RTP報文到達時刻的序列圖，圖中的seq是RTP擴展中的transport sequence,接收端用一個k/v（[seq,arrival timestamp]）鍵值對數(shù)據(jù)結(jié)構(gòu)來保存最近500毫秒未反饋的到達時刻信息,通過時間窗口周期來進行淘汰老的到達時刻記錄。

4.2 丟包率計算

丟包率計算過程是這樣的，我們把上次統(tǒng)計丟包率時刻的最大sequence記著prev_seq, 把當(dāng)前收到的最大sequence記著cur_seq,當(dāng)前統(tǒng)計丟失的報文記著count，WebRTC在RTCP中描述丟包率采用的是uint8，為了保證精確度將256記著100%的丟包率，那么很容易得：

這里需要提的是WebRTC在統(tǒng)計報文是否丟失是通過sequence的連續(xù)性和網(wǎng)絡(luò)的jitter時間來確定的，只有落在jitter抖動范圍之外的丟包才是算是作丟包。

4.3 接收碼率統(tǒng)計

接收端碼率統(tǒng)計采用的是最近單位時間窗（1000毫秒）周期內(nèi)收到的的字節(jié)數(shù)來計算，WebRTC設(shè)計了一個1毫秒為最小單位的窗口數(shù)組來進行統(tǒng)計,每個最小單位是數(shù)字，這個數(shù)字是在這個時刻收到的網(wǎng)絡(luò)數(shù)據(jù)大小，大致的示意圖如下：

圖9：接收碼率統(tǒng)計示意圖

計算碼率只需要將紅框中所有的數(shù)字加起來，當(dāng)時間發(fā)生改變后，就紅框就向右移動并且填寫新時刻接收到的數(shù)據(jù)大小，等下一個統(tǒng)計時刻既可。

5 feedback

前面介紹的estimator依賴于feedback反饋的報文到達時刻和丟包率來進評估碼率的，也就是說feedback需要將這些信息及時反饋給接收端，主要是記錄的報文到達時刻、通道丟包率和remb帶寬。因為報文到達時刻和丟包率統(tǒng)計都是多個數(shù)據(jù)項，WebRTC利用了report block來進行編碼存放。為了有效的利用RTCP的report block空間，WebRTC采用了相對時間轉(zhuǎn)換和位壓縮算法來對到達時間序列做編碼壓縮。

除了report編碼，feedback的周期也很重要，如果是單純的remb反饋，一般是1秒一次反饋。但如果是需要反饋報文的到達時間，它會根據(jù)占用5%的target bitrate來計算發(fā)送feedback的時間間隔，計算流程如下：

feedback interval需要滿足一個條件：50ms < interval < 250ms,這個條件中的 50ms< internal是為了防止interval太小造成發(fā)送feedback太過頻繁而消耗網(wǎng)絡(luò)性能，而interval < 250ms是為了防止feedback頻次太低造成estimator反應(yīng)遲鈍。

6 總結(jié)

以上就是WebRTC擁塞控制和碼率調(diào)節(jié)策略的5個過程，里面涉及到很多傳輸相關(guān)的技術(shù)，我在這里也是簡單介紹了下其工作原理，很多細節(jié)的并沒有描述出來，也很難描述出來，有興趣的同學(xué)可以翻看WebRTC的源代碼。如果覺得webRTC代碼費勁，我照虎畫貓將WebRTC的擁塞控制用C重新實現(xiàn)了個簡易版本,但是去掉了padding，可到https://github.com/yuanrongxi/razor下載。

6.1 效果

WebRTC的GCC在網(wǎng)絡(luò)適應(yīng)上表現(xiàn)還是比較良好的，既然兼顧延遲，也能兼顧丟包，網(wǎng)絡(luò)發(fā)生擁塞時在2 ~ 3秒內(nèi)能評估出相對的碼率來適應(yīng)當(dāng)前的網(wǎng)絡(luò)狀態(tài)，但是會造成短時間的卡頓。對于網(wǎng)絡(luò)發(fā)生間歇性丟包，在2秒左右能將傳輸碼率適配到當(dāng)前網(wǎng)絡(luò)狀態(tài)。它在網(wǎng)絡(luò)相對穩(wěn)定且延遲較大的網(wǎng)絡(luò)進行高分辨率傳輸時，視頻很穩(wěn)定，適合長距離延遲穩(wěn)定的網(wǎng)絡(luò)環(huán)境。在弱網(wǎng)環(huán)境下，WebRTC容易將碼率降到很低而造成圖像失真。

6.2 網(wǎng)絡(luò)大抖動

對于亂序和抖動WebRTC的擁塞控制顯得有點無力，如果抖動超過rtt*2/3時，基于kalman filter的帶寬評估機制不起作用（不知道是不是我用錯了）；基于trendline濾波的評估機制波動很大，敏感度不夠，不能完全反應(yīng)當(dāng)前的網(wǎng)絡(luò)過載狀態(tài)，尤其是在終端Wi-Fi擁擠的情況下，比較容易造成間歇性風(fēng)暴。

6.3 延遲問題

WebRTC的pacer在傳輸大分辨率視頻時，關(guān)鍵幀會引起大約200毫秒的延時，尤其是在移動4G網(wǎng)絡(luò)下這個問題更加明顯，?？低?/u>工程師鄭鵬提出了用H.264的intre_refresh模式來應(yīng)對，在測試過程中確實比較適合WebRTC用來減少關(guān)鍵幀造成的延遲，但是intre_refresh是普通模式編碼CPU的3倍左右，而且很多移動設(shè)備的編碼器不一定支持。