RTMP直播應(yīng)用與延時(shí)分析
- 2016-12-23 08:45:00
- admin 原創(chuàng)
- 5387
低延時(shí)應(yīng)用場(chǎng)景包括:
. 互動(dòng)式直播:譬如當(dāng)前大行其道的各種網(wǎng)紅直播,美女主播,游戲直播等等
各種主播,流媒體分發(fā)給用戶觀看。用戶可以文字聊天和主播互動(dòng)。
. 視頻會(huì)議:我們要是有同事出差在外地,就用視頻會(huì)議開內(nèi)部會(huì)議。
其實(shí)會(huì)議1秒延時(shí)無所謂,因?yàn)槿思抑v完話后,其他人需要思考,
思考的延時(shí)也會(huì)在1秒左右。當(dāng)然如果用視頻會(huì)議吵架就不行。
. 其他:監(jiān)控,直播也有些地方需要對(duì)延遲有要求,
互聯(lián)網(wǎng)上RTMP協(xié)議的延遲基本上能夠滿足要求。
二、RTMP和延時(shí)
1. RTMP的特點(diǎn)如下:
1) Adobe支持得很好:
RTMP實(shí)際上是現(xiàn)在編碼器輸出的工業(yè)標(biāo)準(zhǔn)協(xié)議,基本上所有的編碼器(攝像頭之類)都支持RTMP輸出。原因在于PC市場(chǎng)巨大,PC主要是Windows,Windows的瀏覽器基本上都支持flash, Flash又支持RTMP支持得非常好。
2) 適合長(zhǎng)時(shí)間播放:
因?yàn)镽TMP支持的很完善,所以能做到flash播放RTMP流長(zhǎng)時(shí)間不斷流, 當(dāng)時(shí)測(cè)試是100萬秒,即10天多可以連續(xù)播放。 對(duì)于商用流媒體應(yīng)用,客戶端的穩(wěn)定性當(dāng)然也是必須的,否則最終用戶看不了還怎么玩? 我就知道有個(gè)教育客戶,最初使用播放器播放http流,需要播放不同的文件,結(jié)果就總出問題,如果換成服務(wù)器端將不同的文件轉(zhuǎn)換成RTMP流,客戶端就可以一直播放;
該客戶走RTMP方案后,經(jīng)過CDN分發(fā),沒聽說客戶端出問題了。
3)延遲較低:
比起YY的那種UDP私有協(xié)議,RTMP算延遲大的(延遲在1-3秒), 比起HTTP流的延時(shí)(一般在10秒以上)RTMP算低延時(shí)。 一般的直播應(yīng)用,只要不是電話類對(duì)話的那種要求,RTMP延遲是可以接受的。 在一般的視頻會(huì)議應(yīng)用中,RTMP延時(shí)也能接受,原因是別人在說話的時(shí)候我們一般在聽, 實(shí)際上1秒延時(shí)沒有關(guān)系,我們也要思考(話說有些人的CPU處理速度還沒有這么快)。
4) 有累積延遲:
技術(shù)一定要知道弱點(diǎn),RTMP有個(gè)弱點(diǎn)就是累積誤差,原因是RTMP基于TCP不會(huì)丟包。 所以當(dāng)網(wǎng)絡(luò)狀態(tài)差時(shí),服務(wù)器會(huì)將包緩存起來,導(dǎo)致累積的延遲; 待網(wǎng)絡(luò)狀況好了,就一起發(fā)給客戶端。
這個(gè)的對(duì)策就是,當(dāng)客戶端的緩沖區(qū)很大,就斷開重連。當(dāng)然有些流媒體服務(wù)器考慮了這個(gè)問題,當(dāng)緩沖了規(guī)定時(shí)間的數(shù)據(jù)都沒有發(fā)走后,就可以清空緩沖區(qū),相當(dāng)于把這些過期的數(shù)據(jù)丟掉。
2. HLS低延時(shí)
主要有人老是問這個(gè)問題,如何降低HLS延遲。HLS解決延時(shí),就像是爬到楓樹上去捉魚,奇怪的是還有人喊,看那,有魚。你說是怎么回事?
我只能說你在參與謙哥的魔術(shù)表演,錯(cuò)覺罷了。如果你真的確信有,請(qǐng)用實(shí)際測(cè)量的圖片來展示出來,參考下面延遲的測(cè)量。
3. RTMP延遲的測(cè)量
如何測(cè)量延時(shí),是個(gè)很難的問題,不過有個(gè)行之有效的方法,就是用手機(jī)的秒表,可以比較精確的對(duì)比延時(shí)。
經(jīng)過測(cè)量發(fā)現(xiàn),在網(wǎng)絡(luò)狀況良好時(shí):
. RTMP延時(shí)可以做到0.8秒左右。
. 多級(jí)邊緣節(jié)點(diǎn)不會(huì)影響延遲(和SRS同源的某CDN的邊緣服務(wù)器可以做到)
. Nginx-Rtmp延遲有點(diǎn)大,估計(jì)是緩存的處理,多進(jìn)程通信導(dǎo)致?
. GOP是個(gè)硬指標(biāo),不過SRS可以關(guān)閉GOP的cache來避免這個(gè)影響.
. 服務(wù)器性能太低,也會(huì)導(dǎo)致延遲變大,服務(wù)器來不及發(fā)送數(shù)據(jù)。
. 客戶端的緩沖區(qū)長(zhǎng)度也影響延遲。
譬如flash客戶端的NetStream.bufferTime設(shè)置為10秒,那么延遲至少10秒以上。
4. GOP-Cache
什么是GOP?就是視頻流中兩個(gè)I幀的時(shí)間距離。
GOP有什么影響?
Flash(解碼器)只有拿到GOP才能開始解碼播放。也就是說,服務(wù)器一般先給一個(gè)I幀給Flash。可惜問題來了,假設(shè)GOP是10秒,也就是每隔10秒才有關(guān)鍵幀,如果用戶在第5秒時(shí)開始播放,會(huì)怎么樣?
第一種方案:等待下一個(gè)I幀,
也就是說,再等5秒才開始給客戶端數(shù)據(jù)。
這樣延遲就很低了,總是實(shí)時(shí)的流。
問題是:等待的這5秒,會(huì)黑屏,現(xiàn)象就是播放器卡在那里,什么也沒有,
有些用戶可能以為死掉了,就會(huì)刷新頁面。
總之,某些客戶會(huì)認(rèn)為等待關(guān)鍵幀是個(gè)不可饒恕的錯(cuò)誤,延時(shí)有什么關(guān)系?
我就希望能快速啟動(dòng)和播放視頻,最好打開就能放!
第二種方案:馬上開始放,
放什么呢?你肯定知道了,放前一個(gè)I幀。
也就是說,服務(wù)器需要總是cache一個(gè)gop,
這樣客戶端上來就從前一個(gè)I幀開始播放,就可以快速啟動(dòng)了。
問題是:延遲自然就大了。
有沒有更好的解決方案呢,有,就是服務(wù)器cache一個(gè)I幀,當(dāng)客戶接入后,直接就可以播放,然后再吧之前I幀和當(dāng)前數(shù)據(jù)包的時(shí)間戳該一致,這樣就會(huì)加快播放了,這樣就能實(shí)現(xiàn)即延時(shí)低,又能快速接入播放。目前Aoku Media Server流媒體服務(wù)系統(tǒng)就這樣實(shí)現(xiàn)的。
5. 累積延遲
除了GOP-Cache,還有一個(gè)有關(guān)系,就是累積延遲。
服務(wù)器可以配置直播隊(duì)列的長(zhǎng)度,服務(wù)器會(huì)將數(shù)據(jù)放在直播隊(duì)列中,如果超過這個(gè)長(zhǎng)度就清空到最后一個(gè)I幀:
當(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秒,那么說明緩沖區(qū)中至少有5秒數(shù)據(jù)。
處理累積延遲的最好方法,是客戶端檢測(cè)到緩沖區(qū)有很多數(shù)據(jù)了,如果可以的話,就重連服務(wù)器。
當(dāng)然如果網(wǎng)絡(luò)一直不好,那就沒有辦法了。
發(fā)表評(píng)論
文章分類
聯(lián)系我們
聯(lián)系人: | 北極星通公司 |
---|---|
電話: | 010-56545416 |
傳真: | 010-82896426 |
Email: | support@bjsin.cn |
QQ: | 35338585 |
微信: | Aoku2017 | QQ群:241759321 |
地址: | 北京市中關(guān)村生命科學(xué)園創(chuàng)意園3-3-103 |