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

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

0 ~ 400毫秒	人感覺(jué)不到視頻在通信過(guò)程中的延遲
400 ~ 800毫秒	人能感覺(jué)到輕微延遲，但不影響通信互動(dòng)
800毫秒以上	人能感覺(jué)到延遲而且影響通信互動(dòng)

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

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

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

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

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

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

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

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

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

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

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

　　先計算單個(gè)包組傳輸增長(cháng)的延遲，可以記作：

 

　　然后做每個(gè)包組的疊加延遲，可以記作：

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

 

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

　　我們將第i個(gè)包組的傳輸持續時(shí)間記作：

　　趨勢斜率分子值為：

　　趨勢斜率分母值為：

　　最終的趨勢值為：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　delta time是上次檢查時(shí)間點(diǎn)和這次檢查時(shí)間點(diǎn)的時(shí)間差。

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

　　remain_bytes每次觸發(fā)發(fā)包時(shí)會(huì )減去發(fā)送報文的長(cháng)度size,如果remain_bytes > 0，繼續從pace queue中取下一個(gè)報文進(jìn)行發(fā)送，直到remain_bytes <=0 或者 pace queue沒(méi)有更多的報文。

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

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

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

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

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

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

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

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

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

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

　　FEC bitrate到底應該設置多大呢？它先根據feedback中反饋過(guò)來(lái)的丟包率（loss fraction）來(lái)確定使用哪一種FEC，在根據每中FEC和丟包率來(lái)確定FEC使用的碼率，但需要滿(mǎn)足一下條件：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　總之，WebRTC的擁塞控制存在反應慢、怕抖動(dòng)的特性，但是這塊也是WebRTC改進(jìn)最為頻繁的模塊，幾乎每個(gè)版本都有新的改進(jìn)。要徹底解決這樣的問(wèn)題，需要從視頻編碼器和網(wǎng)絡(luò )傳輸進(jìn)行融合來(lái)解決，以后我用單獨的篇幅來(lái)介紹下這樣的解決方案。

　　袁榮喜，學(xué)霸君資深架構師，16年的C程序員，善于構建高性能服務(wù)系統和系統性能調優(yōu)，擅長(cháng)P2P通信網(wǎng)絡(luò )、TCP/IP通信協(xié)議棧和鑒權加密技術(shù)，2015年加入學(xué)霸君，負責構建學(xué)霸君的智能路由實(shí)時(shí)音視頻傳輸系統和網(wǎng)絡(luò )，解決音視頻通信的實(shí)時(shí)性的問(wèn)題。

　　辛鋒，工程碩士，目前在萍鄉學(xué)院電子工程專(zhuān)業(yè)從事教育工作，18年教育教學(xué)經(jīng)驗，對機電控制、芯片編程、控制理論和人工智能有深入的研究。

　　LiveVideoStackCon 2018是音視頻技術(shù)領(lǐng)域的綜合技術(shù)大會(huì )，今年是在10月19-20日在北京舉行。大會(huì )共設立16個(gè)專(zhuān)題，預計邀請超過(guò)80位技術(shù)專(zhuān)家。如果你在某一領(lǐng)域獨當一面，歡迎申請成為L(cháng)iveVideoStackCon 2018的講師，讓你的經(jīng)驗幫到更多人，你可以通過(guò)speaker@livevideostack.com 提交演講信息。了解大會(huì )更多詳情，請點(diǎn)擊『閱讀原文』訪(fǎng)問(wèn)LiveVideoStackCon 2018官網(wǎng)，即刻享受6折優(yōu)惠。