低延遲:顧名思義,就是讓播放端和推流端的時間差越小越好,那麼如何作到低延遲呢,一個詞歸納:no buffer緩存
首先說明一下視頻流的流向:推流端--->CDN服務器--->拉流端服務器
1. 推流端 nobuffer,也就是保證推流端緩存的buffer最小。這樣基本上保證在推流端出現網絡抖動或者忽然變差的狀況下,可以捨棄已經緩存的buffer,繼續推新生成好的視頻幀。這樣保證了,在網絡端開始傳輸的時候的視頻內容是最新的。網絡
2. CDN nobuffer,針對性的調整CDN的配置,讓CDN服務器緩存的GOP儘量的少,這樣保證拉流端獲取到的是最新的內容。ide
3. 拉流端 nobuffer,既然推流和中轉的CDN都設置了nobuffer,那麼拉流端設置nobuffer的意義,應該不須要作過多的解釋了吧。性能
記住一點:低延遲問題的解決不是一端的事情,三端的配置都會對延遲的效果產生影響。測試
在直播的過程當中,有首開延時和內容延時。首開延時,基本能夠控制在100ms左右;基於RTMP播放的內容延遲根據CDN的狀況,基本上會在2~5秒左右。而由於RTMP是基於TCP協議的,因此在播放的過程當中會受到網絡條件的影響,形成延遲增長的狀況。經過了解直播流的推流和拉流相關的知識,能夠知道,根據推流端(推流策略)與服務器(緩存策略)不一樣的控制的設定,咱們極可能拿到幾秒以前的內容(甚至十幾秒),能夠經過對比拉流端與推流端的內容便可得知。而這些內容,在拉流端會把CDN服務器緩存的數據拉取過來,這時buffer queue變大。那麼,buffer queue越大,拉流端與推流端的延時越大。spa
拉流端影響延時的核心緣由: buffer queue 變大,拉流端播放的內容和推流端相差時延增長。視頻
解決辦法:get
1. 控制max_buffer_size,合理設置max_buffer_size,使得拉流端不會緩存太長時間的內容(通過測試,發現不是很實用,由於內容延時只有追趕或者丟棄當前播放的內容,快速跳播到最新數據才能達到低延時播放)直播
2. 使用倍速播放,快速消耗Buffer Queue,在消耗到合理的區間後,進行正常播放(監聽並動態控制buffer queue,此方案要求設備的解碼性能可以支撐)。
3. 使用丟包(丟幀)策略。策略說明:
下面是我在解決低延遲問題的時候,參考的丟包(丟幀)策略相關文章:ijkplayer丟幀的處理方案 、jkplay播放直播流延時控制小結。