視頻直播技術（三）：低延時直播經驗總結

解決低延遲問題的核心思想：NO BUFFER

低延遲：顧名思義，就是讓播放端和推流端的時間差越小越好，那麼如何作到低延遲呢，一個詞歸納：no buffer

首先說明一下視頻流的流向：推流端--->CDN服務器--->拉流端

1. 推流端 nobuffer，也就是保證推流端緩存的buffer最小。這樣基本上保證在推流端出現網絡抖動或者忽然變差的狀況下，可以捨棄已經緩存的buffer，繼續推新生成好的視頻幀。這樣保證了，在網絡端開始傳輸的時候的視頻內容是最新的。

2. CDN nobuffer，針對性的調整CDN的配置，讓CDN服務器緩存的GOP儘量的少，這樣保證拉流端獲取到的是最新的內容。

3. 拉流端 nobuffer，既然推流和中轉的CDN都設置了nobuffer，那麼拉流端設置nobuffer的意義，應該不須要作過多的解釋了吧。

記住一點：低延遲問題的解決不是一端的事情，三端的配置都會對延遲的效果產生影響。

拉流端（基於IjkPlayer）低延時直播的經驗：

在直播的過程當中，有首開延時和內容延時。首開延時，基本能夠控制在100ms左右；基於RTMP播放的內容延遲根據CDN的狀況，基本上會在2~5秒左右。而由於RTMP是基於TCP協議的，因此在播放的過程當中會受到網絡條件的影響，形成延遲增長的狀況。經過了解直播流的推流和拉流相關的知識，能夠知道，根據推流端（推流策略）與服務器（緩存策略）不一樣的控制的設定，咱們極可能拿到幾秒以前的內容（甚至十幾秒），能夠經過對比拉流端與推流端的內容便可得知。而這些內容，在拉流端會把CDN服務器緩存的數據拉取過來，這時buffer queue變大。那麼，buffer queue越大，拉流端與推流端的延時越大。

拉流端影響延時的核心緣由： buffer queue 變大，拉流端播放的內容和推流端相差時延增長。

解決辦法：

1. 控制max_buffer_size，合理設置max_buffer_size，使得拉流端不會緩存太長時間的內容（通過測試，發現不是很實用，由於內容延時只有追趕或者丟棄當前播放的內容，快速跳播到最新數據才能達到低延時播放）

2. 使用倍速播放，快速消耗Buffer Queue，在消耗到合理的區間後，進行正常播放（監聽並動態控制buffer queue，此方案要求設備的解碼性能可以支撐）。

3. 使用丟包（丟幀）策略。策略說明：

• 有音頻流和視頻流，或者只有音頻流狀況下，當audioq達到必定的duration，就丟掉前面一部分數據包，由於默認是AV_SYNC_AUDIO_MASTER，視頻會追上來。
• 只有視頻流狀況，當videoq達到必定的duration，就丟掉前面一部分數據包。

下面是我在解決低延遲問題的時候，參考的丟包（丟幀）策略相關文章：ijkplayer丟幀的處理方案 、jkplay播放直播流延時控制小結。