前言

如果網絡是理想的，即無丟包，無抖動，低延時，那么接收到一幀完整數據就直接播放，效果也一定會非常好。但是實際的網絡總是復雜的，尤其無線網絡。如果還是這樣直接播放，網絡稍微變差，視頻就會卡頓，出現馬賽克等。所以，在接收端對接收的數據做一個緩沖是很有必要的。
緩沖一定是以延時作為代價的，延時越大，對抖動的過濾效果越好。一個優秀的視頻jitterbuffer，不僅要能夠對丟包、亂序、延時到達等異常情況做處理，而且還要能夠讓視頻平穩的播放，盡可能的避免出現明顯的加速播放和緩慢播放。
主流的實時音視頻框架基本都會實現jitterbuffer功能，諸如webrtc、doubango等。webrtc的jitterbuffer相當優秀，按照功能分類的話，可以分為jitter和buffer。buffer主要對丟包、亂序、延時到達等異常情況做處理，還會和NACK、FEC、FIR等QOS相互配合。jitter主要根據當前幀的大小和延時評估出jitter delay，再結合decode delay、render delay以及音視頻同步延時，得到render time，來控制平穩的渲染視頻幀。

下面將分別對jitter和buffer做介紹。

buffer

buffer運行機制圖

buffer對接收到的rtp包的處理流程如下：

• 第一次接收到一個視頻包，從freeframes隊列中彈出一個空frame塊，用來放置這個包。
• 之后每次接收到一個RTP包，根據時間戳在incompleteframes和decodableframes中尋找，看是否已經接收到過相同時間戳的包，如果找到，則彈出該frame塊，否則，從freeframes彈出一個空frame。
• 根據包的序列號，找到應該插入frame的位置，并更新state。其中state有empty、incomplete、decodable和complete，empty為沒有數據的狀態，incomplete為至少有一個包的狀態，decodable為可解碼狀態，complete為這一幀所有數據都已經到齊。decodable會根據decode_error_mode 有不同的規則，QOS的不同策略會設置不同的decode_error_mode ，包含kNoErrors、kSelectiveErrors以及kWithErrors。decode_error_mode 就決定了解碼線程從buffer中取出來的幀是否包含錯誤，即當前幀是否有丟包。
• 根據不同的state將frame幀 push回到隊列中去。其中state為incomplete時，push到incompleteframes隊列，decodable和complete狀態的frame，push回到decodableframes隊列中。
• freeframes隊列有初始size，freeframes隊列為空時，會增加隊列size，但有最大值。也會定期從incompleteframes和decodable隊列中清除一些過時的frame，push到freeframes隊列。
• 解碼線程取出frame,解碼完成之后，push回freeframes隊列。

jitterbuffer與QOS策略聯系緊密，比如，incompleteframes和decodable隊列清除一些frame之后，需要FIR（關鍵幀請求），根據包序號檢測到丟包之后要NACK（丟包重傳）等。

jitter

所謂jitter就是一種抖動。具體如何解釋呢？從源地址發送到目標地址，會發生不一樣的延遲，這樣的延遲變動就是jitter。
jitter會帶來什么影響？jitter會讓音視頻的播放不平穩，如音頻的顫音，視頻的忽快忽慢。那么如何對抗jitter呢？增加延時。需要增加一個因為jitter而存在的delay，即jitterdelay。

更新jitterdelay

其中，frameDelayMS指的是一幀數據因為分包和網絡傳輸所造成的延時總和,幀間延遲。具體如下圖，即RTP1和RTP2到達Receiver的時間差。

幀間延遲

framesizeBytes指當前幀數據大小，incompleteFrame指是否為完整的幀，UpdateEstimate為根據這三個參數來更新jitterdelay的模塊，這個模塊為核心模塊，其中會用到卡爾曼濾波對幀間延遲進行濾波。

JitterDelay = theta[0] * (MaxFS – AvgFS) + [noiseStdDevs * sqrt(varNoise) – noiseStdDevOffset]

其中theta[0]是信道傳輸速率的倒數，MaxFS是自會話開始以來所收到的最大幀大小，AvgFS表示平均幀大小。noiseStdDevs表示噪聲系數2.33，varNoise表示噪聲方差，noiseStdDevOffset是噪聲扣除常數30。UpdateEstimate會不斷地對varNoise等進行更新。

在得到jitterdelay之后，通過jitterdelay+ decodedelay + renderdelay，再確保大于音視頻同步的延時，加上當前系統時間得到rendertime，這樣就可以控制播放時間。控制播放，也就間接控制了buffer的大小。

取幀，解碼播放

取幀解碼播放

本文只介紹jitterbuffer相關內容，所以這里只詳細介紹取幀這一步。
解碼線程會一直從buffer中尋找期望的數據，這里說的期望的分為必須完整的和可以不完整的。如果期望的是完整的，那就要從decodableframes隊列取出狀態為complete的frame，如果期望的數據可以是不完整的，就要從decodableframes和incompleteframes隊列取出數據。取數據之前，總是先去找到數據的時間戳，然后計算完jitterdelay和渲染時間，再經過一段時間的延時（這個延時為渲染時間減去當前時間、decode delay和render delay）之后再去取得數據，傳遞到解碼，渲染。
取完整的幀時，有一個最大等待時間，即當前buffer中沒有完整的幀，那么可以等待一段時間，以期望在這段時間里，可以出現完整的幀。

后記

從上述原理可以看出，webrtc中的接收buffer并非是固定的，而是根據網絡波動等因素隨時變化的。jitter則是為了對抗網絡波動造成的抖動，使得視頻能夠平穩播放。
那么，jitterbuffer是否存在可以優化的空間呢？jitterbuffer已經較為優秀，但我們可以通過調整里面的一些策略，來使的視頻質量更好。比如，增大緩沖區，因為jitterbuffer是動態的，直接增大freeframes的size是無效的，只能通過調整延時，來增大緩沖區。再比如，調整等待時間，以期望獲得更多完整的幀。再如，配合NACK，FIR、FEC等QOS策略，來對抗丟包。
當然，這都是以犧牲延時為代價的。總之，要在延時和丟包、抖動之間做出平衡。

jitterbuffer和帶寬預測是不相關的，各自執行。