前言
如果網(wǎng)絡(luò)是理想的蒜哀，即無丟包，無抖動，低延時撵儿，那么接收到一幀完整數(shù)據(jù)就直接播放乘客，效果也一定會非常好。但是實際的網(wǎng)絡(luò)總是復(fù)雜的淀歇，尤其無線網(wǎng)絡(luò)易核。如果還是這樣直接播放，網(wǎng)絡(luò)稍微變差浪默，視頻就會卡頓牡直，出現(xiàn)馬賽克等。所以纳决，在接收端對接收的數(shù)據(jù)做一個緩沖是很有必要的碰逸。
緩沖一定是以延時作為代價的，延時越大阔加，對抖動的過濾效果越好饵史。一個優(yōu)秀的視頻jitterbuffer，不僅要能夠?qū)G包胜榔、亂序胳喷、延時到達等異常情況做處理，而且還要能夠讓視頻平穩(wěn)的播放夭织，盡可能的避免出現(xiàn)明顯的加速播放和緩慢播放吭露。
主流的實時音視頻框架基本都會實現(xiàn)jitterbuffer功能，諸如webrtc尊惰、doubango等讲竿。webrtc的jitterbuffer相當(dāng)優(yōu)秀，按照功能分類的話择浊，可以分為jitter和buffer戴卜。buffer主要對丟包、亂序琢岩、延時到達等異常情況做處理投剥，還會和NACK、FEC担孔、FIR等QOS相互配合江锨。jitter主要根據(jù)當(dāng)前幀的大小和延時評估出jitter delay，再結(jié)合decode delay糕篇、render delay以及音視頻同步延時啄育，得到render time，來控制平穩(wěn)的渲染視頻幀拌消。
下面將分別對jitter和buffer做介紹挑豌。
buffer
buffer對接收到的rtp包的處理流程如下：
- 第一次接收到一個視頻包，從freeframes隊列中彈出一個空frame塊，用來放置這個包氓英。
- 之后每次接收到一個RTP包侯勉，根據(jù)時間戳在incompleteframes和decodableframes中尋找，看是否已經(jīng)接收到過相同時間戳的包铝阐，如果找到址貌，則彈出該frame塊，否則徘键，從freeframes彈出一個空frame练对。
- 根據(jù)包的序列號，找到應(yīng)該插入frame的位置吹害，并更新state螟凭。其中state有empty、incomplete它呀、decodable和complete赂摆，empty為沒有數(shù)據(jù)的狀態(tài)，incomplete為至少有一個包的狀態(tài)钟些，decodable為可解碼狀態(tài)，complete為這一幀所有數(shù)據(jù)都已經(jīng)到齊绊谭。decodable會根據(jù)decode_error_mode 有不同的規(guī)則政恍，QOS的不同策略會設(shè)置不同的decode_error_mode ，包含kNoErrors达传、kSelectiveErrors以及kWithErrors篙耗。decode_error_mode 就決定了解碼線程從buffer中取出來的幀是否包含錯誤，即當(dāng)前幀是否有丟包宪赶。
- 根據(jù)不同的state將frame幀 push回到隊列中去宗弯。其中state為incomplete時，push到incompleteframes隊列搂妻，decodable和complete狀態(tài)的frame蒙保，push回到decodableframes隊列中。
- freeframes隊列有初始size欲主，freeframes隊列為空時邓厕，會增加隊列size，但有最大值扁瓢。也會定期從incompleteframes和decodable隊列中清除一些過時的frame详恼，push到freeframes隊列。
- 解碼線程取出frame,解碼完成之后引几，push回freeframes隊列昧互。
jitterbuffer與QOS策略聯(lián)系緊密，比如，incompleteframes和decodable隊列清除一些frame之后敞掘，需要FIR（關(guān)鍵幀請求）叽掘，根據(jù)包序號檢測到丟包之后要NACK（丟包重傳）等。
jitter
所謂jitter就是一種抖動渐逃。具體如何解釋呢够掠？從源地址發(fā)送到目標(biāo)地址，會發(fā)生不一樣的延遲茄菊，這樣的延遲變動就是jitter疯潭。
jitter會帶來什么影響？jitter會讓音視頻的播放不平穩(wěn)面殖，如音頻的顫音竖哩，視頻的忽快忽慢。那么如何對抗jitter呢脊僚？增加延時相叁。需要增加一個因為jitter而存在的delay，即jitterdelay辽幌。
其中增淹，frameDelayMS指的是一幀數(shù)據(jù)因為分包和網(wǎng)絡(luò)傳輸所造成的延時總和,幀間延遲。具體如下圖乌企，即RTP1和RTP2到達Receiver的時間差虑润。
framesizeBytes指當(dāng)前幀數(shù)據(jù)大小，incompleteFrame指是否為完整的幀加酵，UpdateEstimate為根據(jù)這三個參數(shù)來更新jitterdelay的模塊拳喻，這個模塊為核心模塊，其中會用到卡爾曼濾波對幀間延遲進行濾波猪腕。
JitterDelay = theta[0] * (MaxFS – AvgFS) + [noiseStdDevs * sqrt(varNoise) – noiseStdDevOffset]
其中theta[0]是信道傳輸速率的倒數(shù)冗澈，MaxFS是自會話開始以來所收到的最大幀大小，AvgFS表示平均幀大小陋葡。noiseStdDevs表示噪聲系數(shù)2.33亚亲，varNoise表示噪聲方差，noiseStdDevOffset是噪聲扣除常數(shù)30腐缤。UpdateEstimate會不斷地對varNoise等進行更新朵栖。
在得到j(luò)itterdelay之后，通過jitterdelay+ decodedelay + renderdelay柴梆，再確保大于音視頻同步的延時陨溅，加上當(dāng)前系統(tǒng)時間得到rendertime，這樣就可以控制播放時間绍在∶派龋控制播放雹有，也就間接控制了buffer的大小。
取幀臼寄，解碼播放
本文只介紹jitterbuffer相關(guān)內(nèi)容霸奕，所以這里只詳細(xì)介紹取幀這一步。
解碼線程會一直從buffer中尋找期望的數(shù)據(jù)吉拳，這里說的期望的分為必須完整的和可以不完整的质帅。如果期望的是完整的，那就要從decodableframes隊列取出狀態(tài)為complete的frame留攒，如果期望的數(shù)據(jù)可以是不完整的煤惩，就要從decodableframes和incompleteframes隊列取出數(shù)據(jù)。取數(shù)據(jù)之前炼邀，總是先去找到數(shù)據(jù)的時間戳魄揉，然后計算完jitterdelay和渲染時間，再經(jīng)過一段時間的延時（這個延時為渲染時間減去當(dāng)前時間拭宁、decode delay和render delay）之后再去取得數(shù)據(jù)洛退，傳遞到解碼，渲染杰标。
取完整的幀時兵怯，有一個最大等待時間，即當(dāng)前buffer中沒有完整的幀腔剂，那么可以等待一段時間摇零，以期望在這段時間里，可以出現(xiàn)完整的幀桶蝎。
后記
從上述原理可以看出，webrtc中的接收buffer并非是固定的谅畅，而是根據(jù)網(wǎng)絡(luò)波動等因素隨時變化的登渣。jitter則是為了對抗網(wǎng)絡(luò)波動造成的抖動，使得視頻能夠平穩(wěn)播放毡泻。
那么胜茧，jitterbuffer是否存在可以優(yōu)化的空間呢？jitterbuffer已經(jīng)較為優(yōu)秀仇味，但我們可以通過調(diào)整里面的一些策略呻顽，來使的視頻質(zhì)量更好。比如丹墨，增大緩沖區(qū)廊遍，因為jitterbuffer是動態(tài)的，直接增大freeframes的size是無效的贩挣，只能通過調(diào)整延時喉前，來增大緩沖區(qū)没酣。再比如，調(diào)整等待時間卵迂，以期望獲得更多完整的幀裕便。再如，配合NACK见咒，F(xiàn)IR偿衰、FEC等QOS策略，來對抗丟包改览。
當(dāng)然下翎，這都是以犧牲延時為代價的∈逊瑁總之漏设，要在延時和丟包、抖動之間做出平衡今妄。
jitterbuffer和帶寬預(yù)測是不相關(guān)的郑口，各自執(zhí)行。
