直播應(yīng)用中朝聋，RTMP和HLS基本上可以覆蓋所有客戶端觀看
HLS主要是延時比較大竹海，RTMP主要優(yōu)勢在于延時低。
一、應(yīng)用場景
低延時應(yīng)用場景包括：
互動式直播：譬如2013年大行其道的美女主播帅刀，游戲直播等等
各種主播，流媒體分發(fā)給用戶觀看掂铐。用戶可以文字聊天和主播互動芒澜。
視頻會議：我們要是有同事出差在外地，就用視頻會議開內(nèi)部會議卧须。
其實(shí)會議1秒延時無所謂另绩，因?yàn)槿思抑v完話后儒陨，其他人需要思考，
思考的延時也會在1秒左右笋籽。當(dāng)然如果用視頻會議吵架就不行蹦漠。
其他：監(jiān)控，直播也有些地方需要對延遲有要求车海，
互聯(lián)網(wǎng)上RTMP協(xié)議的延遲基本上能夠滿足要求笛园。
二、RTMP和延時
1. RTMP的特點(diǎn)如下：
1) Adobe支持得很好：
RTMP實(shí)際上是現(xiàn)在編碼器輸出的工業(yè)標(biāo)準(zhǔn)協(xié)議侍芝，基本上所有的編碼器（攝像頭之類）都支持RTMP輸出研铆。
原因在于PC市場巨大，PC主要是Windows竭贩，Windows的瀏覽器基本上都支持flash蚜印，
Flash又支持RTMP支持得非常好。
2)適合長時間播放：
因?yàn)镽TMP支持的很完善留量，所以能做到flash播放RTMP流長時間不斷流窄赋，
當(dāng)時測試是100萬秒，即10天多可以連續(xù)播放楼熄。
對于商用流媒體應(yīng)用忆绰，客戶端的穩(wěn)定性當(dāng)然也是必須的，否則最終用戶看不了還怎么玩可岂？
我就知道有個教育客戶错敢，最初使用播放器播放http流，需要播放不同的文件缕粹，結(jié)果就總出問題稚茅，
如果換成服務(wù)器端將不同的文件轉(zhuǎn)換成RTMP流，客戶端就可以一直播放平斩；
該客戶走RTMP方案后亚享，經(jīng)過CDN分發(fā)，沒聽說客戶端出問題了绘面。
3）延遲較低：
比起YY的那種UDP私有協(xié)議欺税，RTMP算延遲大的（延遲在1-3秒），
比起HTTP流的延時（一般在10秒以上）RTMP算低延時揭璃。
一般的直播應(yīng)用晚凿，只要不是電話類對話的那種要求，RTMP延遲是可以接受的瘦馍。
在一般的視頻會議應(yīng)用中歼秽，RTMP延時也能接受，原因是別人在說話的時候我們一般在聽情组，
實(shí)際上1秒延時沒有關(guān)系哲银，我們也要思考（話說有些人的CPU處理速度還沒有這么快）扛吞。
4)有累積延遲：
技術(shù)一定要知道弱點(diǎn)，RTMP有個弱點(diǎn)就是累積誤差荆责，原因是RTMP基于TCP不會丟包。
所以當(dāng)網(wǎng)絡(luò)狀態(tài)差時亚脆，服務(wù)器會將包緩存起來做院，導(dǎo)致累積的延遲；
待網(wǎng)絡(luò)狀況好了濒持，就一起發(fā)給客戶端键耕。
這個的對策就是，當(dāng)客戶端的緩沖區(qū)很大柑营，就斷開重連屈雄。
2. HLS低延時
主要有人老是問這個問題，如何降低HLS延遲官套。
HLS解決延時酒奶，就像是爬到楓樹上去捉魚，奇怪的是還有人喊奶赔，看那惋嚎，有魚。
你說是怎么回事?
我只能說你在參與謙哥的魔術(shù)表演站刑，錯覺罷了另伍。
如果你真的確信有，請用實(shí)際測量的圖片來展示出來绞旅，參考下面延遲的測量摆尝。
3. RTMP延遲的測量
如何測量延時，是個很難的問題因悲，
不過有個行之有效的方法堕汞，就是用手機(jī)的秒表，可以比較精確的對比延時囤捻。
經(jīng)過測量發(fā)現(xiàn)臼朗，在網(wǎng)絡(luò)狀況良好時：
. RTMP延時可以做到0.8秒左右。
.多級邊緣節(jié)點(diǎn)不會影響延遲（和SRS同源的某CDN的邊緣服務(wù)器可以做到）
.
Nginx-Rtmp延遲有點(diǎn)大蝎土，估計(jì)是緩存的處理视哑，多進(jìn)程通信導(dǎo)致？
. GOP是個硬指標(biāo)誊涯，不過SRS可以關(guān)閉GOP的cache來避免這個影響.
.服務(wù)器性能太低挡毅，也會導(dǎo)致延遲變大，服務(wù)器來不及發(fā)送數(shù)據(jù)暴构。
.客戶端的緩沖區(qū)長度也影響延遲跪呈。
.譬如flash客戶端的NetStream.bufferTime設(shè)置為10秒段磨，那么延遲至少10秒以上。
4.
GOP-Cache
什么是GOP耗绿？就是視頻流中兩個I幀的時間距離苹支。
GOP有什么影響？
Flash（解碼器）只有拿到GOP才能開始解碼播放误阻。
也就是說债蜜，服務(wù)器一般先給一個I幀給Flash。
可惜問題來了究反，假設(shè)GOP是10秒寻定，也就是每隔10秒才有關(guān)鍵幀，
如果用戶在第5秒時開始播放精耐，會怎么樣狼速？
第一種方案：等待下一個I幀，
也就是說卦停，再等5秒才開始給客戶端數(shù)據(jù)向胡。
這樣延遲就很低了，總是實(shí)時的流沫浆。
問題是：等待的這5秒捷枯，會黑屏，現(xiàn)象就是播放器卡在那里专执，什么也沒有淮捆，
有些用戶可能以為死掉了，就會刷新頁面本股。
總之攀痊，某些客戶會認(rèn)為等待關(guān)鍵幀是個不可饒恕的錯誤，延時有什么關(guān)系拄显？
我就希望能快速啟動和播放視頻苟径，最好打開就能放！
第二種方案：馬上開始放
放什么呢躬审？
你肯定知道了棘街，放前一個I幀。
也就是說承边，服務(wù)器需要總是cache一個gop遭殉，
這樣客戶端上來就從前一個I幀開始播放，就可以快速啟動了博助。
問題是：延遲自然就大了险污。
有沒有好的方案？
有！至少有兩種：
編碼器調(diào)低GOP蛔糯，譬如0.5秒一個GOP拯腮，這樣延遲也很低，也不用等待蚁飒。
壞處是編碼器壓縮率會降低动壤，圖像質(zhì)量沒有那么好。
5.累積延遲
除了GOP-Cache飒箭，還有一個有關(guān)系狼电，就是累積延遲。
服務(wù)器可以配置直播隊(duì)列的長度弦蹂，服務(wù)器會將數(shù)據(jù)放在直播隊(duì)列中，
如果超過這個長度就清空到最后一個I幀：
當(dāng)然這個不能配置太小强窖，
譬如GOP是1秒凸椿，queue_length是1秒，這樣會導(dǎo)致有1秒數(shù)據(jù)就清空翅溺，會導(dǎo)致跳躍脑漫。
有更好的方法？有的咙崎。
延遲基本上就等于客戶端的緩沖區(qū)長度优幸，因?yàn)檠舆t大多由于網(wǎng)絡(luò)帶寬低，
服務(wù)器緩存后一起發(fā)給客戶端褪猛，現(xiàn)象就是客戶端的緩沖區(qū)變大了网杆，
譬如NetStream.BufferLength=5秒，那么說明緩沖區(qū)中至少有5秒數(shù)據(jù)伊滋。
處理累積延遲的最好方法碳却，是客戶端檢測到緩沖區(qū)有很多數(shù)據(jù)了，如果可以的話笑旺，就重連服務(wù)器昼浦。
當(dāng)然如果網(wǎng)絡(luò)一直不好，那就沒有辦法了筒主。
