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