低延時(shí)直播應(yīng)用

直播應(yīng)用中，RTMP和HLS基本上可以覆蓋所有客戶端觀看，HLS主要是延時(shí)比較大，RTMP主要優(yōu)勢(shì)在于延時(shí)低。

應(yīng)用場(chǎng)景

低延時(shí)應(yīng)用場(chǎng)景包括：

互動(dòng)式直播：譬如2013年大行其道的美女主播，游戲直播等等各種主播，流媒體分發(fā)給用戶觀看。用戶可以文字聊天和主播互動(dòng)。視頻會(huì)議：SRS的DEMO就有視頻會(huì)議應(yīng)用，我們要是有同事出差在外地，就用這個(gè)視頻會(huì)議開內(nèi)部會(huì)議。其實(shí)會(huì)議1秒延時(shí)無(wú)所謂，因?yàn)槿思抑v完話后，其他人需要思考，思考的延時(shí)也會(huì)在1秒左右。當(dāng)然如果用視頻會(huì)議吵架就不行。其他：監(jiān)控，直播也有些地方需要對(duì)延遲有要求，互聯(lián)網(wǎng)上RTMP協(xié)議的延遲基本上能夠滿足要求。 RTMP和延時(shí)

RTMP的特點(diǎn)如下：

Adobe支持得很好：RTMP實(shí)際上是現(xiàn)在編碼器輸出的工業(yè)標(biāo)準(zhǔn)協(xié)議，基本上所有的編碼器（攝像頭之類）都支持RTMP輸出。原因在于PC市場(chǎng)巨大，PC主要是Windows，Windows的瀏覽器基本上都支持flash，F(xiàn)lash又支持RTMP支持得灰常好。適合長(zhǎng)時(shí)間播放：因?yàn)镽TMP支持的很完善，所以能做到flash播放RTMP流長(zhǎng)時(shí)間不斷流，當(dāng)時(shí)測(cè)試是100萬(wàn)秒，即10天多可以連續(xù)播放。對(duì)于商用流媒體應(yīng)用，客戶端的穩(wěn)定性當(dāng)然也是必須的，否則最終用戶看不了還怎么玩？我就知道有個(gè)教育客戶，最初使用播放器播放http流，需要播放不同的文件，結(jié)果就總出問(wèn)題，如果換成服務(wù)器端將不同的文件轉(zhuǎn)換成RTMP流，客戶端就可以一直播放；該客戶走RTMP方案后，經(jīng)過(guò)CDN分發(fā)，沒聽說(shuō)客戶端出問(wèn)題了。延遲較低：比起YY的那種UDP私有協(xié)議，RTMP算延遲大的（延遲在1-3秒），比起HTTP流的延時(shí)（一般在10秒以上）RTMP算低延時(shí)。一般的直播應(yīng)用，只要不是電話類對(duì)話的那種要求，RTMP延遲是可以接受的。在一般的視頻會(huì)議（參考SRS的視頻會(huì)議延時(shí)）應(yīng)用中，RTMP延時(shí)也能接受，原因是別人在說(shuō)話的時(shí)候我們一般在聽，實(shí)際上1秒延時(shí)沒有關(guān)系，我們也要思考（話說(shuō)有些人的CPU處理速度還沒有這么快）。有累積延遲：技術(shù)一定要知道弱點(diǎn)，RTMP有個(gè)弱點(diǎn)就是累積誤差，原因是RTMP基于TCP不會(huì)丟包。所以當(dāng)網(wǎng)絡(luò)狀態(tài)差時(shí)，服務(wù)器會(huì)將包緩存起來(lái)，導(dǎo)致累積的延遲；待網(wǎng)絡(luò)狀況好了，就一起發(fā)給客戶端。這個(gè)的對(duì)策就是，當(dāng)客戶端的緩沖區(qū)很大，就斷開重連。當(dāng)然SRS也提供配置。 HLS低延時(shí)

主要有人老是問(wèn)這個(gè)問(wèn)題，如何降低HLS延遲。

HLS解決延時(shí)，就像是爬到楓樹上去捉魚，奇怪的是還有人喊，看那，有魚。你說(shuō)是怎么回事。

我只能說(shuō)你在參與謙哥的魔術(shù)表演，錯(cuò)覺罷了。

如果你真的確信有，請(qǐng)用實(shí)際測(cè)量的圖片來(lái)展示出來(lái)，參考下面延遲的測(cè)量。

RTMP延遲的測(cè)量

如何測(cè)量延時(shí)，是個(gè)很難的問(wèn)題，不過(guò)有個(gè)行之有效的方法，就是用手機(jī)的秒表，可以比較精確的對(duì)比延時(shí)。參考：RTMP延時(shí)測(cè)量

經(jīng)過(guò)測(cè)量發(fā)現(xiàn)，在網(wǎng)絡(luò)狀況良好時(shí)：

RTMP延時(shí)可以做到0.8秒左右（SRS也可以）。多級(jí)邊緣節(jié)點(diǎn)不會(huì)影響延遲（和SRS同源的某CDN的邊緣服務(wù)器可以做到）Nginx-Rtmp延遲有點(diǎn)大，估計(jì)是緩存的處理，多進(jìn)程通信導(dǎo)致？GOP是個(gè)硬指標(biāo)，不過(guò)SRS可以關(guān)閉GOP的cache來(lái)避免這個(gè)影響，參考后面的配置方法。服務(wù)器性能太低，也會(huì)導(dǎo)致延遲變大，服務(wù)器來(lái)不及發(fā)送數(shù)據(jù)?？蛻舳说木彌_區(qū)長(zhǎng)度也影響延遲。譬如flash客戶端的NetStream.bufferTime設(shè)置為10秒，那么延遲至少10秒以上。 GOP-Cache

什么是GOP？就是視頻流中兩個(gè)I幀的時(shí)間距離。

GOP有什么影響？Flash（解碼器）只有拿到GOP才能開始解碼播放。也就是說(shuō)，服務(wù)器一般先給一個(gè)I幀給Flash。可惜問(wèn)題來(lái)了，假設(shè)GOP是10秒，也就是每隔10秒才有關(guān)鍵幀，如果用戶在第5秒時(shí)開始播放，會(huì)怎么樣？

第一種方案：等待下一個(gè)I幀，也就是說(shuō)，再等5秒才開始給客戶端數(shù)據(jù)。這樣延遲就很低了，總是實(shí)時(shí)的流。問(wèn)題是：等待的這5秒，會(huì)黑屏，現(xiàn)象就是播放器卡在那里，什么也沒有，有些用戶可能以為死掉了，就會(huì)刷新頁(yè)面?？傊承┛蛻魰?huì)認(rèn)為等待關(guān)鍵幀是個(gè)不可饒恕的錯(cuò)誤，延時(shí)有什么關(guān)系？我就希望能快速啟動(dòng)和播放視頻，最好打開就能放！

第二種方案：馬上開始放，放什么呢？你肯定知道了，放前一個(gè)I幀。也就是說(shuō)，服務(wù)器需要總是cache一個(gè)gop，這樣客戶端上來(lái)就從前一個(gè)I幀開始播放，就可以快速啟動(dòng)了。問(wèn)題是：延遲自然就大了。

有沒有好的方案？有！至少有兩種：

編碼器調(diào)低GOP，譬如0.5秒一個(gè)GOP，這樣延遲也很低，也不用等待。壞處是編碼器壓縮率會(huì)降低，圖像質(zhì)量沒有那么好。服務(wù)器提供配置，可以選擇前面兩個(gè)方案之一：SRS就這么做，有個(gè)gop_cache配置項(xiàng)，on就會(huì)馬上播放，off就低延遲。

SRS的配置項(xiàng)：

#?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，還有一個(gè)有關(guān)系，就是累積延遲。SRS可以配置直播隊(duì)列的長(zhǎng)度，服務(wù)器會(huì)將數(shù)據(jù)放在直播隊(duì)列中，如果超過(guò)這個(gè)長(zhǎng)度就清空到最后一個(gè)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;
}

當(dāng)然這個(gè)不能配置太小，譬如GOP是1秒，queue_length是1秒，這樣會(huì)導(dǎo)致有1秒數(shù)據(jù)就清空，會(huì)導(dǎo)致跳躍。

有更好的方法？有的。延遲基本上就等于客戶端的緩沖區(qū)長(zhǎng)度，因?yàn)檠舆t大多由于網(wǎng)絡(luò)帶寬低，服務(wù)器緩存后一起發(fā)給客戶端，現(xiàn)象就是客戶端的緩沖區(qū)變大了，譬如NetStream.BufferLength=5秒，那么說(shuō)明緩沖區(qū)中至少有5秒數(shù)據(jù)。

處理累積延遲的最好方法，是客戶端檢測(cè)到緩沖區(qū)有很多數(shù)據(jù)了，如果可以的話，就重連服務(wù)器。當(dāng)然如果網(wǎng)絡(luò)一直不好，那就沒有辦法了。

低延時(shí)配置

考慮GOP-Cache和累積延遲，推薦的低延時(shí)配置如下（參考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;
}

當(dāng)然，服務(wù)器的性能也要考慮，不可以讓一個(gè)SRS進(jìn)程跑太高帶寬，一般CPU在80%以下不會(huì)影響延遲。