對于交互性要求較高的直播業(yè)務來說，采集推流端和觀看端的延時太高是不可接受的。當采用 RTMP 協(xié)議做直播業(yè)務時，一般可以將延時控制在 1-3s 或者更低。但是如果在直播中發(fā)生卡頓、播放暫停等情況時，也會不斷積累推流端和觀看端的延時。這種累積延時要怎么優(yōu)化呢？

優(yōu)化切換前后臺帶來的累積延時

在直播場景中，有一種情況是切換前后臺造成累積延時。這里舉個例子：在前臺時，直播視頻在播放，然后退到后臺，此時暫停播放器，音視頻數據繼續(xù)緩存，當回到前臺時，繼續(xù)從剛才退出時的視頻流數據開始播放，而實際的直播現在已經不在這個時間點了。這段前后臺切換的時間里，就積累了一段延時。

對于這種延時改怎么處理呢？

第一種方案是播放器采用視頻同步音頻的策略，然后退到后臺時保持音頻繼續(xù)播放（在 iOS 平臺需要開啟 App 的 Background Audio 能力來配合）。這樣可以保持音頻一直播放不產生延時，而當回到前臺時，視頻同步音頻直接切換到最新時間戳即可。

第二種方案是回到前臺時重新刷新直播，重連直播流，這樣即可消滅累積延時。但是這種方案的問題是重連直播流的過程需要一定的時間，這樣回到前臺時會有卡頓，或者出現黑屏，尤其是當你的首屏加載優(yōu)化不夠時，這個卡頓或黑屏時間會較長。所以這種方案在你的首屏加載優(yōu)化的比較好的情況下可以采用。此外，你可以退到后臺時截取視頻當前幀貼圖到直播間上，從而當切回前臺時，防止黑屏，優(yōu)化體驗，實踐效果還是不錯的。

優(yōu)化卡頓帶來的累積延時

在理想的情況下：網絡狀況良好；采集推流端、流媒體服務器、播放端均吞吐正常無阻塞，可以不配置緩沖區(qū)。這時候推流端到播放端的延時將會很小，基本上就是網絡傳輸的耗時。

但是在實際情況中，我們多多少少會遇到網絡不佳或網絡抖動的情況，在這種網絡環(huán)境下，如果沒有緩沖策略，直播將發(fā)生卡頓。為了解決卡頓，通常會根據具體情況在采集推流端、流媒體服務器、播放端增加緩沖策略，而一旦發(fā)生緩沖，就意味著推流端到播放端的延時。當卡頓情況多次出現，這樣的延時就會累積。

此外，從 RTMP 協(xié)議層面上來講，累積延時本身是它的一個特征，因為 RTMP 是基于 TCP，所以不會丟包，在網絡情況不佳的情況下超時重傳策略、緩沖策略等自然會帶來累積延時。

所以，優(yōu)化卡頓帶來的累積延時首先是要優(yōu)化整個直播鏈條的網絡狀況去減少卡頓。從這個角度出發(fā)，我們可以采用的策略包括：

使用 CDN 分發(fā)網絡。合理采用 CDN 邊緣節(jié)點推流。推流端、播放端使用 HTTPDNS 選擇網絡狀況最好的節(jié)點接入。推流端實現碼率自適應策略，在網絡狀況不佳的情況下，降低推流碼率來降低上行帶寬壓力。流媒體服務器提供多檔位直播流服務，與此同時，播放端實現直播流多檔位切換策略，在網絡狀況不佳的情況下，切換到低檔位直播流來降低下行帶寬壓力。

除了這些外，我們還可以優(yōu)化各端的緩沖策略來降低累積延時。直播鏈條各端的緩沖區(qū)通常都是為了防止網絡抖動以及端上性能抖動產生卡頓，但是各緩沖區(qū)的數據越多，通常也意味著累積延時越大。所以在各端上，我們還可以嘗試這些策略：

在「卡頓」和「累積延時」這兩項體驗指標上尋找一個平衡點，在各端設置合適的緩沖區(qū)大小。在各端實現一些丟幀策略，當緩沖區(qū)超過一定閾值時，開始丟幀。在播放端的緩沖區(qū)過大時，嘗試斷開重連。