本文轉自：直播中累積延時的優化 | www.samirchen.com
對於交互性要求較高的直播業務來說，采集推流端和觀看端的延時太高是不可接受的。在 直播協議的選擇：RTMP vs. HLS 一文中提到了采用 RTMP 協議做直播業務，一般可以將延時控制在 1-3s 或者更低。但是如果在直播中發生卡頓、播放暫停等情況時，也會不斷積累推流端和觀看端的延時。這種累積延時要怎么優化呢？
優化切換前后台帶來的累積延時
在直播場景中，有一種情況是切換前后台造成累積延時。這里舉個例子：在前台時，直播視頻在播放，然后退到后台，此時暫停播放器，音視頻數據繼續緩存，當回到前台時，繼續從剛才退出時的視頻流數據開始播放，而實際的直播現在已經不在這個時間點了。這段前后台切換的時間里，就積累了一段延時。
對於這種延時改怎么處理呢？
-
第一種方案是播放器采用視頻同步音頻的策略，然后退到后台時保持音頻繼續播放（在 iOS 平台需要開啟 App 的 Background Audio 能力來配合）。這樣可以保持音頻一直播放不產生延時，而當回到前台時，視頻同步音頻直接切換到最新時間戳即可。
-
第二種方案是回到前台時重新刷新直播，重連直播流，這樣即可消滅累積延時。但是這種方案的問題是重連直播流的過程需要一定的時間，這樣回到前台時會有卡頓，或者出現黑屏，尤其是當你的首屏加載優化不夠時，這個卡頓或黑屏時間會較長。所以這種方案在你的首屏加載優化的比較好的情況下可以采用。此外，你可以退到后台時截取視頻當前幀貼圖到直播間上，從而當切回前台時，防止黑屏，優化體驗，實踐效果還是不錯的。
優化卡頓帶來的累積延時
在理想的情況下：網絡狀況良好；采集推流端、流媒體服務器、播放端均吞吐正常無阻塞，可以不配置緩沖區。這時候推流端到播放端的延時將會很小，基本上就是網絡傳輸的耗時。
但是在實際情況中，我們多多少少會遇到網絡不佳或網絡抖動的情況，在這種網絡環境下，如果沒有緩沖策略，直播將發生卡頓。為了解決卡頓，通常會根據具體情況在采集推流端、流媒體服務器、播放端增加緩沖策略，而一旦發生緩沖，就意味着推流端到播放端的延時。當卡頓情況多次出現，這樣的延時就會累積。
此外，從 RTMP 協議層面上來講，累積延時本身是它的一個特征，因為 RTMP 是基於 TCP，所以不會丟包，在網絡情況不佳的情況下超時重傳策略、緩沖策略等自然會帶來累積延時。
所以，優化卡頓帶來的累積延時首先是要優化整個直播鏈條的網絡狀況去減少卡頓。從這個角度出發，我們可以采用的策略包括：
- 使用 CDN 分發網絡。
- 合理采用 CDN 邊緣節點推流。
- 推流端、播放端使用 HTTPDNS 選擇網絡狀況最好的節點接入。
- 推流端實現碼率自適應策略，在網絡狀況不佳的情況下，降低推流碼率來降低上行帶寬壓力。
- 流媒體服務器提供多檔位直播流服務，與此同時，播放端實現直播流多檔位切換策略，在網絡狀況不佳的情況下，切換到低檔位直播流來降低下行帶寬壓力。
除了這些外，我們還可以優化各端的緩沖策略來降低累積延時。直播鏈條各端的緩沖區通常都是為了防止網絡抖動以及端上性能抖動產生卡頓，但是各緩沖區的數據越多，通常也意味着累積延時越大。所以在各端上，我們還可以嘗試這些策略：
- 在「卡頓」和「累積延時」這兩項體驗指標上尋找一個平衡點，在各端設置合適的緩沖區大小。
- 在各端實現一些丟幀策略，當緩沖區超過一定閾值時，開始丟幀。
- 在播放端的緩沖區過大時，嘗試斷開重連。