低延時直播應用
直播應用中,RTMP和HLS基本上可以覆蓋所有客戶端觀看,HLS主要是延時比較大,RTMP主要優(yōu)勢在于延時低。
應用場景
低延時應用場景包括:
互動式直播:譬如2013年大行其道的美女主播,游戲直播等等各種主播,流媒體分發(fā)給用戶觀看。用戶可以文字聊天和主播互動。視頻會議:SRS的DEMO就有視頻會議應用,我們要是有同事出差在外地,就用這個視頻會議開內(nèi)部會議。其實會議1秒延時無所謂,因為人家講完話后,其他人需要思考,思考的延時也會在1秒左右。當然如果用視頻會議吵架就不行。其他:監(jiān)控,直播也有些地方需要對延遲有要求,互聯(lián)網(wǎng)上RTMP協(xié)議的延遲基本上能夠滿足要求。 RTMP和延時
RTMP的特點如下:
Adobe支持得很好:RTMP實際上是現(xiàn)在編碼器輸出的工業(yè)標準協(xié)議,基本上所有的編碼器(攝像頭之類)都支持RTMP輸出。原因在于PC市場巨大,PC主要是Windows,Windows的瀏覽器基本上都支持flash,F(xiàn)lash又支持RTMP支持得灰常好。適合長時間播放:因為RTMP支持的很完善,所以能做到flash播放RTMP流長時間不斷流,當時測試是100萬秒,即10天多可以連續(xù)播放。對于商用流媒體應用,客戶端的穩(wěn)定性當然也是必須的,否則最終用戶看不了還怎么玩?我就知道有個教育客戶,最初使用播放器播放http流,需要播放不同的文件,結(jié)果就總出問題,如果換成服務(wù)器端將不同的文件轉(zhuǎn)換成RTMP流,客戶端就可以一直播放;該客戶走RTMP方案后,經(jīng)過CDN分發(fā),沒聽說客戶端出問題了。延遲較低:比起YY的那種UDP私有協(xié)議,RTMP算延遲大的(延遲在1-3秒),比起HTTP流的延時(一般在10秒以上)RTMP算低延時。一般的直播應用,只要不是電話類對話的那種要求,RTMP延遲是可以接受的。在一般的視頻會議(參考SRS的視頻會議延時)應用中,RTMP延時也能接受,原因是別人在說話的時候我們一般在聽,實際上1秒延時沒有關(guān)系,我們也要思考(話說有些人的CPU處理速度還沒有這么快)。有累積延遲:技術(shù)一定要知道弱點,RTMP有個弱點就是累積誤差,原因是RTMP基于TCP不會丟包。所以當網(wǎng)絡(luò)狀態(tài)差時,服務(wù)器會將包緩存起來,導致累積的延遲;待網(wǎng)絡(luò)狀況好了,就一起發(fā)給客戶端。這個的對策就是,當客戶端的緩沖區(qū)很大,就斷開重連。當然SRS也提供配置。 HLS低延時
主要有人老是問這個問題,如何降低HLS延遲。
HLS解決延時,就像是爬到楓樹上去捉魚,奇怪的是還有人喊,看那,有魚。你說是怎么回事。
我只能說你在參與謙哥的魔術(shù)表演,錯覺罷了。
如果你真的確信有,請用實際測量的圖片來展示出來,參考下面延遲的測量。
RTMP延遲的測量
如何測量延時,是個很難的問題,不過有個行之有效的方法,就是用手機的秒表,可以比較精確的對比延時。參考:RTMP延時測量
經(jīng)過測量發(fā)現(xiàn),在網(wǎng)絡(luò)狀況良好時:
RTMP延時可以做到0.8秒左右(SRS也可以)。多級邊緣節(jié)點不會影響延遲(和SRS同源的某CDN的邊緣服務(wù)器可以做到)Nginx-Rtmp延遲有點大,估計是緩存的處理,多進程通信導致?GOP是個硬指標,不過SRS可以關(guān)閉GOP的cache來避免這個影響,參考后面的配置方法。服務(wù)器性能太低,也會導致延遲變大,服務(wù)器來不及發(fā)送數(shù)據(jù)??蛻舳说木彌_區(qū)長度也影響延遲。譬如flash客戶端的NetStream.bufferTime設(shè)置為10秒,那么延遲至少10秒以上。 GOP-Cache
什么是GOP?就是視頻流中兩個I幀的時間距離。
GOP有什么影響?Flash(解碼器)只有拿到GOP才能開始解碼播放。也就是說,服務(wù)器一般先給一個I幀給Flash??上栴}來了,假設(shè)GOP是10秒,也就是每隔10秒才有關(guān)鍵幀,如果用戶在第5秒時開始播放,會怎么樣?
第一種方案:等待下一個I幀,也就是說,再等5秒才開始給客戶端數(shù)據(jù)。這樣延遲就很低了,總是實時的流。問題是:等待的這5秒,會黑屏,現(xiàn)象就是播放器卡在那里,什么也沒有,有些用戶可能以為死掉了,就會刷新頁面??傊?,某些客戶會認為等待關(guān)鍵幀是個不可饒恕的錯誤,延時有什么關(guān)系?我就希望能快速啟動和播放視頻,最好打開就能放!
第二種方案:馬上開始放,放什么呢?你肯定知道了,放前一個I幀。也就是說,服務(wù)器需要總是cache一個gop,這樣客戶端上來就從前一個I幀開始播放,就可以快速啟動了。問題是:延遲自然就大了。
有沒有好的方案?有!至少有兩種:
編碼器調(diào)低GOP,譬如0.5秒一個GOP,這樣延遲也很低,也不用等待。壞處是編碼器壓縮率會降低,圖像質(zhì)量沒有那么好。服務(wù)器提供配置,可以選擇前面兩個方案之一:SRS就這么做,有個gop_cache配置項,on就會馬上播放,off就低延遲。
SRS的配置項:
#?the?listen?ports,?split?by?space. listen??????????????1935; vhost?__defaultVhost__?{ ????#?whether?cache?the?last?gop. ????#?if?on,?cache?the?last?gop?and?dispatch?to?client, ????#???to?enable?fast?startup?for?client,?client?play?immediately. ????#?if?off,?send?the?latest?media?data?to?client, ????#???client?need?to?wait?for?the?next?Iframe?to?decode?and?show?the?video. ????#?set?to?off?if?requires?min?delay; ????#?set?to?on?if?requires?client?fast?startup. ????#?default:?on ????gop_cache???????on; }
備注:參考conf/full.conf的min.delay.com配置。
累積延遲
除了GOP-Cache,還有一個有關(guān)系,就是累積延遲。SRS可以配置直播隊列的長度,服務(wù)器會將數(shù)據(jù)放在直播隊列中,如果超過這個長度就清空到最后一個I幀:
vhost?your_vhost?{ ????#?the?max?live?queue?length?in?seconds. ????#?if?the?messages?in?the?queue?exceed?the?max?length,? ????#?drop?the?old?whole?gop. ????#?default:?30 ????queue_length????10; }
當然這個不能配置太小,譬如GOP是1秒,queue_length是1秒,這樣會導致有1秒數(shù)據(jù)就清空,會導致跳躍。
有更好的方法?有的。延遲基本上就等于客戶端的緩沖區(qū)長度,因為延遲大多由于網(wǎng)絡(luò)帶寬低,服務(wù)器緩存后一起發(fā)給客戶端,現(xiàn)象就是客戶端的緩沖區(qū)變大了,譬如NetStream.BufferLength=5秒,那么說明緩沖區(qū)中至少有5秒數(shù)據(jù)。
處理累積延遲的最好方法,是客戶端檢測到緩沖區(qū)有很多數(shù)據(jù)了,如果可以的話,就重連服務(wù)器。當然如果網(wǎng)絡(luò)一直不好,那就沒有辦法了。
低延時配置
考慮GOP-Cache和累積延遲,推薦的低延時配置如下(參考min.delay.com):
#?the?listen?ports,?split?by?space. listen??????????????1935; vhost?__defaultVhost__?{ ????#?whether?cache?the?last?gop. ????#?if?on,?cache?the?last?gop?and?dispatch?to?client, ????#???to?enable?fast?startup?for?client,?client?play?immediately. ????#?if?off,?send?the?latest?media?data?to?client, ????#???client?need?to?wait?for?the?next?Iframe?to?decode?and?show?the?video. ????#?set?to?off?if?requires?min?delay; ????#?set?to?on?if?requires?client?fast?startup. ????#?default:?on ????gop_cache???????off; ????#?the?max?live?queue?length?in?seconds. ????#?if?the?messages?in?the?queue?exceed?the?max?length,? ????#?drop?the?old?whole?gop. ????#?default:?30 ????queue_length????10; }
當然,服務(wù)器的性能也要考慮,不可以讓一個SRS進程跑太高帶寬,一般CPU在80%以下不會影響延遲。