播放器技術(shù)分享（2）：緩沖區(qū)管理

搞音視頻開發(fā)好些年，分享過許多博客文章，比如：前幾年發(fā)布的《FFmpeg Tips》系列，《Android 音頻開發(fā)》系列，《直播疑難雜癥排查》系列等等。最近想把多年來開發(fā)和優(yōu)化播放器的經(jīng)驗也分享出來，同時也考慮把自己業(yè)余時間開發(fā)的基于 ffmpeg 的播放器內(nèi)核開源出來，希望能幫助到音視頻領(lǐng)域的初學(xué)者。第一期文章要推出的內(nèi)容主要涉及到播放器比較核心的幾個技術(shù)點，大概的目錄如下：

1. 播放器技術(shù)分享（1）：架構(gòu)設(shè)計

2. 播放器技術(shù)分享（2）：緩沖區(qū)管理

3. 播放器技術(shù)分享（3）：音畫同步

4. 播放器技術(shù)分享（4）：首開時間

5. 播放器技術(shù)分享（5）：延時優(yōu)化

本篇是系列文章的第二篇，主要聊一聊播放器的緩沖區(qū)管理。

1 概述

在上一篇文章中，我們有提到利用緩沖區(qū)把單線程模型的數(shù)據(jù)流改造為多線程模型，從而可以有效抵抗網(wǎng)絡(luò)和解碼的抖動，防止頻繁卡頓，同時也能充分利用多核 CPU 的計算能力，如下圖所示：

播放器的讀線程，將 IO 和 Parser 模塊輸出的”未解碼“的音視頻數(shù)據(jù)包放到”幀緩沖區(qū)“隊列中，將解碼后的數(shù)據(jù)，存放到”顯示緩沖區(qū)“隊列中。

2 緩沖區(qū)的作用

我們深挖一下，這個 “幀緩沖區(qū)” 和 “顯示緩沖區(qū)” 究竟起到了一個什么作用 ？

2.1 幀緩沖區(qū)

幀緩沖區(qū)，作為“讀線程”和“解碼線程”之間的緩沖池，它主要起到了三個作用：

1. 抵抗網(wǎng)絡(luò)抖動

2. 抵抗解碼抖動

3. 避免被動丟幀導(dǎo)致花屏

假設(shè)沒有“幀緩沖區(qū)”，即：IO -> Parser -> Decoder 整個流程是串行的，那么會有如下潛在問題：

1. IO 網(wǎng)絡(luò)抖動的時候（比如：短暫擁塞，無法讀到數(shù)據(jù)），那么整個數(shù)據(jù)鏈條都會被卡住，Decoder 只能干等著 IO 恢復(fù)

2. Decoder 同樣會出現(xiàn)“抖動”，因為解碼某些復(fù)雜的視頻幀，會耗時比較久，如果 Decoder 卡住，同樣 IO 模塊也只能干等著

3. 因為整個流程是串行的，每一幀都必須 IO -> Parser -> Decoder 走完才會讀取和處理下一幀，那么，當(dāng)網(wǎng)絡(luò)抖動的時候，會出現(xiàn)服務(wù)端的 TCP 協(xié)議棧緩存了較多的數(shù)據(jù)，在網(wǎng)絡(luò)恢復(fù)的時候，下發(fā)到客戶端的時候，因為接收不及時，導(dǎo)致 TCP 發(fā)送隊列爆滿而產(chǎn)生被動丟幀，從而使得后續(xù)因為數(shù)據(jù)不完整導(dǎo)致解碼花屏

2.2 顯示緩沖區(qū)

顯示緩沖區(qū)，作為“解碼線程”和“顯示線程”之間的緩沖池，它主要起到了三個作用：

1. 實現(xiàn) “音畫同步” 的必要條件

2. 抵抗渲染抖動

假設(shè)沒有“顯示緩沖區(qū)”，即：Decoder -> Renderer 整個流程是串行的，那么會有如下潛在問題：

1. 無論是視頻幀還是音頻數(shù)據(jù)，都是解碼完了就立馬送入了渲染模塊，無法添加音畫同步的邏輯處理

2. 如果渲染模塊出現(xiàn)“抖動”，會直接阻塞×××，無法異步去解碼幀緩沖區(qū)中的數(shù)據(jù)，降低了效率

3 “主動緩沖” 與 “被動緩沖”

了解了緩沖區(qū)的作用，我們再看看緩沖區(qū)的數(shù)據(jù)是怎么被填充的 ？

緩沖區(qū)的數(shù)據(jù)填充，主要分為 2 種情況，第一種叫 “主動緩沖”，另一種叫做 “被動緩沖”

主動緩沖：是指播放器主動暫停緩沖區(qū)的數(shù)據(jù)消費，等待數(shù)據(jù)生產(chǎn)者逐漸填充數(shù)據(jù)，直到達(dá)到某種條件再恢復(fù)

被動緩沖：是指數(shù)據(jù)的消費速度趕不上生產(chǎn)速度，從而被動滯留了數(shù)據(jù)在緩沖區(qū)中

主動緩沖，多用于點播場景，為了降低頻繁卡頓，在開始播放視頻之前，會主動 buffering 一段時間（比如：10s）的數(shù)據(jù)，再開始播放。當(dāng)緩沖區(qū)內(nèi)的數(shù)據(jù)因為網(wǎng)絡(luò)抖動等原因消耗完了，會再次啟動 buffering，如此循環(huán)。

如圖所示，假設(shè)播放器緩沖區(qū)內(nèi)的數(shù)據(jù)低于 Low 這個水位點后，會主動暫停播放，啟動 buffering 過程直到緩沖區(qū)中的數(shù)據(jù)達(dá)到 M 水位值。

被動緩沖，多出現(xiàn)在直播場景，可能有 2 種原因：

1. 手機等設(shè)備的解碼性能不足，比如軟解 1080P 的高清視頻，導(dǎo)致視頻的解碼和渲染的速度趕不上視頻的讀取速度，導(dǎo)致數(shù)據(jù)堆積在“幀緩沖區(qū)”

2. 網(wǎng)絡(luò)的頻繁抖動，導(dǎo)致客戶端無法及時拿到數(shù)據(jù)進行解碼渲染，當(dāng)網(wǎng)絡(luò)恢復(fù)后，數(shù)據(jù)會迅速下發(fā)下來，但播放器已沒有辦法再快速消費掉（因為播放的速率是固定的，除非添加追幀的邏輯，后續(xù)文章會詳細(xì)介紹）

4 緩沖區(qū)的大小怎么定 ？

理解了緩沖區(qū)的作用，那這兩個緩沖區(qū)的大小如何制定呢 ？首先，我們需要知道這兩個緩沖區(qū)大小究竟影響或者決定了什么 ？

1. 緩沖區(qū)越大 -> 抗抖動能力越強

2. 緩沖區(qū)越大 -> 內(nèi)存占用越高

3. 緩沖區(qū)越大 -> 播放延時越大

由此可見，緩沖區(qū)也不是越大越好，需要根據(jù)實際的使用場景來決定。

“顯示緩沖區(qū)” 其實是 解碼線程 和 渲染線程 之間的橋梁，由于解碼和渲染的抖動并不頻繁，所以并不需要特別大的緩沖區(qū)，最低 3 幀左右即可，一幀在生產(chǎn)，一幀在消費，還有一幀在緩沖區(qū)中待命。

而 “幀緩沖區(qū)” 是用來抵抗網(wǎng)絡(luò)抖動的，網(wǎng)絡(luò)抖動往往是比較頻繁的，抖動的時間也有時會比較久一些，所以 “幀緩沖區(qū)” 相對要設(shè)置得大一點，但以不過于影響內(nèi)存和播放延時為前提。

對于直播場景，為了防止 “被動丟幀”，往往 “幀緩沖區(qū)” 默認(rèn)是設(shè)置為 “無限大” 的，當(dāng)檢測到緩沖區(qū)達(dá)到一定閾值后，啟動一些諸如主動丟幀或者倍數(shù)播放的方式，來快速消耗掉緩沖的內(nèi)容，從而降低內(nèi)存和延時。

5 緩沖區(qū)何時會主動清空 ？

有如下幾種場景，播放器會主動清空緩沖區(qū)內(nèi)的數(shù)據(jù)：

1. 播放器重置

2. 播放進度條被拖動

3. 消除累積延時

4. 系統(tǒng)內(nèi)存告警

6 IJKPlayer 的緩沖區(qū)管理

ijkplayer 使用非常廣泛，這里以它為例看看播放器緩沖區(qū)的真實案例是怎么樣的 ？

1. 播放器打開后，緩沖 100ms，再開始播放

2. 如果遇到了卡頓（緩沖區(qū)為空），則暫停播放，緩沖到 1000ms，再開始播放

  3. 如果再次遇到卡頓，則緩沖到 2000ms 再播，依次類推，直到 5000ms

可以看出，它的緩沖區(qū)的最大閾值是逐步遞增上去的，這是一個非常棒的用戶體驗優(yōu)化，因為如果用戶網(wǎng)絡(luò)不是那么差的話，不用第一次緩沖就等 5s 了

7 總結(jié)

播放器的緩沖區(qū)管理，就分享到這里了，如有疑問的小伙伴歡迎來信 lujun.hust@gmail.com 交流。另外，也歡迎大家關(guān)注我的新浪微博 @盧_俊 或者 微信公眾號 @Jhuster 獲取最新的文章和資訊。