WebRTC的JitterBuff介紹

前言如果網(wǎng)絡(luò)是理想的，即無(wú)丟包、無(wú)抖動(dòng)、低延時(shí)，那么接收到一幀完整數(shù)據(jù)就直接播放，效果一定會(huì)非常好。但是實(shí)際的網(wǎng)絡(luò)往往很復(fù)雜，尤其是無(wú)線網(wǎng)絡(luò)。如果還是這樣直接播放，網(wǎng)絡(luò)稍微變差，視頻就會(huì)卡頓，出現(xiàn)馬賽克等異常情況。所以，在接收端對(duì)接收的數(shù)據(jù)做一個(gè)緩沖是很有必要的。?緩沖一定是以延時(shí)作為代價(jià)的，延時(shí)越大，對(duì)抖動(dòng)的過(guò)濾效果越好。一個(gè)優(yōu)秀的視頻jitterbuffer，不僅要能夠?qū)G包、亂序、延時(shí)到達(dá)等異常情況進(jìn)行處理，而且還要能夠讓視頻平穩(wěn)的播放，盡可能的避免出現(xiàn)明顯的加速播放和緩慢播放。?主流的實(shí)時(shí)音視頻框架基本都會(huì)實(shí)現(xiàn)jitterbuffer功能，諸如WebRTC、doubango等。WebRTC的jitterbuffer相當(dāng)優(yōu)秀，按照功能分類(lèi)的話，可以分為jitter和buffer。buffer主要對(duì)丟包、亂序、延時(shí)到達(dá)等異常情況進(jìn)行處理，還會(huì)和NACK、FEC、FIR等QOS相互配合。jitter主要根據(jù)當(dāng)前幀的大小和延時(shí)評(píng)估出jitter delay，再結(jié)合decode delay、render delay以及音視頻同步延時(shí)，得到render time，來(lái)控制平穩(wěn)的渲染視頻幀。?下面將分別對(duì)jitter和buffer做介紹。?Buffer

buffer運(yùn)行機(jī)制圖?buffer對(duì)接收到的rtp包的主要處理操作如下：

第一次接收到一個(gè)視頻包，從freeframes隊(duì)列中彈出一個(gè)空f(shuō)rame塊，用來(lái)放置這個(gè)包。

之后每次接收到一個(gè)RTP包，根據(jù)時(shí)間戳在incompleteframes和decodableframes中尋找，看是否已經(jīng)接收到過(guò)相同時(shí)間戳的包，如果找到，則彈出該frame塊，否則，從freeframes彈出一個(gè)空f(shuō)rame。

根據(jù)包的序列號(hào)，找到應(yīng)該插入frame的位置，并更新state。其中state有empty、incomplete、decodable和complete，empty為沒(méi)有數(shù)據(jù)的狀態(tài)，incomplete為至少有一個(gè)包的狀態(tài)，decodable為可解碼狀態(tài)，complete為這一幀所有數(shù)據(jù)都已經(jīng)到齊。decodable會(huì)根據(jù)decode_error_mode 有不同的規(guī)則，QOS的不同策略會(huì)設(shè)置不同的decode_error_mode ，包含kNoErrors、kSelectiveErrors以及kWithErrors。decode_error_mode 就決定了解碼線程從buffer中取出來(lái)的幀是否包含錯(cuò)誤，即當(dāng)前幀是否有丟包。

根據(jù)不同的state將frame幀push回到隊(duì)列中去。其中state為incomplete時(shí)，push到incompleteframes隊(duì)列，decodable和complete狀態(tài)的frame，push回到decodableframes隊(duì)列中。

freeframes隊(duì)列有初始size，freeframes隊(duì)列為空時(shí)，會(huì)增加隊(duì)列size，但有最大值。也會(huì)定期從incompleteframes和decodable隊(duì)列中清除一些過(guò)時(shí)的frame，push到freeframes隊(duì)列。

解碼線程取出frame,解碼完成之后，push回freeframes隊(duì)列。

?jitterbuffer與QOS策略聯(lián)系緊密，比如，incompleteframes和decodable隊(duì)列清除一些frame之后，需要FIR（關(guān)鍵幀請(qǐng)求），根據(jù)包序號(hào)檢測(cè)到丟包之后要NACK（丟包重傳）等。?Jitter所謂jitter就是一種抖動(dòng)。具體如何解釋呢？從源地址發(fā)送到目標(biāo)地址，會(huì)發(fā)生不一樣的延遲，這樣的延遲變動(dòng)就是jitter。?jitter會(huì)帶來(lái)什么影響？jitter會(huì)讓音視頻的播放不平穩(wěn)，如音頻的顫音，視頻的忽快忽慢。那么如何對(duì)抗jitter呢？增加延時(shí)。需要增加一個(gè)因?yàn)閖itter而存在的delay，即jitterdelay。

更新jitterdelay圖?其中，frameDelayMS指的是一幀數(shù)據(jù)因?yàn)榉职途W(wǎng)絡(luò)傳輸所造成的延時(shí)總和、幀間延遲。具體如下圖，即RTP1和RTP2到達(dá)Receiver的時(shí)間差。

幀間延遲圖?framesizeBytes指當(dāng)前幀數(shù)據(jù)大小，incompleteFrame指是否為完整的幀，UpdateEstimate為根據(jù)這三個(gè)參數(shù)來(lái)更新jitterdelay的模塊，這個(gè)模塊為核心模塊，其中會(huì)用到卡爾曼濾波對(duì)幀間延遲進(jìn)行濾波。?JitterDelay =theta[0] * (MaxFS – AvgFS) + [noiseStdDevs * sqrt(varNoise) –noiseStdDevOffset]?其中theta[0]是信道傳輸速率的倒數(shù)，MaxFS是自會(huì)話開(kāi)始以來(lái)所收到的最大幀大小，AvgFS表示平均幀大小。noiseStdDevs表示噪聲系數(shù)2.33，varNoise表示噪聲方差，noiseStdDevOffset是噪聲扣除常數(shù)30。UpdateEstimate會(huì)不斷地對(duì)varNoise等進(jìn)行更新。?在得到j(luò)itterdelay之后，通過(guò)jitterdelay+ decodedelay +renderdelay，再確保大于音視頻同步的延時(shí)，加上當(dāng)前系統(tǒng)時(shí)間得到rendertime，這樣就可以控制播放時(shí)間?？刂撇シ?，也就間接控制了buffer的大小。
?取幀，解碼播放

取幀解碼播放圖?本文只介紹jitterbuffer相關(guān)內(nèi)容，所以這里只詳細(xì)介紹取幀這一步。?解碼線程會(huì)一直從buffer中尋找期望的數(shù)據(jù)，這里說(shuō)的期望的數(shù)據(jù)分為必須完整的和可以不完整的。如果期望的數(shù)據(jù)是完整的，那就要從decodableframes隊(duì)列取出狀態(tài)為complete的frame，如果期望的數(shù)據(jù)可以是不完整的，就要從decodableframes和incompleteframes隊(duì)列取出數(shù)據(jù)。取數(shù)據(jù)之前，總是先去找到數(shù)據(jù)的時(shí)間戳，然后計(jì)算完jitterdelay和渲染時(shí)間，再經(jīng)過(guò)一段時(shí)間的延時(shí)（這個(gè)延時(shí)為渲染時(shí)間減去當(dāng)前時(shí)間、decodedelay和render delay）之后再去取得數(shù)據(jù)，傳遞到解碼，渲染。?取完整的幀時(shí)，有一個(gè)最大等待時(shí)間，即當(dāng)前buffer中沒(méi)有完整的幀，那么可以等待一段時(shí)間，以期望在這段時(shí)間里，可以出現(xiàn)完整的幀。?后記從上述原理可以看出，WebRTC中的接收buffer并非是固定的，而是根據(jù)網(wǎng)絡(luò)波動(dòng)等因素隨時(shí)變化的。jitter則是為了對(duì)抗網(wǎng)絡(luò)波動(dòng)造成的抖動(dòng)，使得視頻能夠平穩(wěn)播放。?那么，jitterbuffer是否存在可以?xún)?yōu)化的空間呢？jitterbuffer已經(jīng)較為優(yōu)秀，但我們可以通過(guò)調(diào)整里面的一些策略，來(lái)使視頻質(zhì)量更好。比如，增大緩沖區(qū)，因?yàn)閖itterbuffer是動(dòng)態(tài)的，直接增大freeframes的size是無(wú)效的，只能通過(guò)調(diào)整延時(shí)，來(lái)增大緩沖區(qū)。再比如，調(diào)整等待時(shí)間，以期望獲得更多完整的幀。再如，配合NACK，F(xiàn)IR、FEC等QOS策略，來(lái)對(duì)抗丟包。?當(dāng)然，這都是以犧牲延時(shí)為代價(jià)的。總之，要在延時(shí)和丟包、抖動(dòng)之間做出平衡。