直播應用中，RTMP和HLS基本上可以覆蓋所有客戶端觀看

HLS主要是延時比較大，RTMP主要優勢在于延時低。

一、應用場景

低延時應用場景包括：

互動式直播：譬如2013年大行其道的美女主播，游戲直播等等

各種主播，流媒體分發給用戶觀看。用戶可以文字聊天和主播互動。

視頻會議：我們要是有同事出差在外地，就用視頻會議開內部會議。

其實會議1秒延時無所謂，因為人家講完話后，其他人需要思考，

思考的延時也會在1秒左右。當然如果用視頻會議吵架就不行。

其他：監控，直播也有些地方需要對延遲有要求，

互聯網上RTMP協議的延遲基本上能夠滿足要求。

二、RTMP和延時

1. RTMP的特點如下：

1) Adobe支持得很好：

RTMP實際上是現在編碼器輸出的工業標準協議，基本上所有的編碼器（攝像頭之類）都支持RTMP輸出。

原因在于PC市場巨大，PC主要是Windows，Windows的瀏覽器基本上都支持flash，

Flash又支持RTMP支持得非常好。

2) 適合長時間播放：

因為RTMP支持的很完善，所以能做到flash播放RTMP流長時間不斷流，

當時測試是100萬秒，即10天多可以連續播放。

對于商用流媒體應用，客戶端的穩定性當然也是必須的，否則最終用戶看不了還怎么玩？

我就知道有個教育客戶，最初使用播放器播放http流，需要播放不同的文件，結果就總出問題，

如果換成服務器端將不同的文件轉換成RTMP流，客戶端就可以一直播放；

該客戶走RTMP方案后，經過CDN分發，沒聽說客戶端出問題了。

3）延遲較低：

比起YY的那種UDP私有協議，RTMP算延遲大的（延遲在1-3秒），

比起HTTP流的延時（一般在10秒以上）RTMP算低延時。

一般的直播應用，只要不是電話類對話的那種要求，RTMP延遲是可以接受的。

在一般的視頻會議應用中，RTMP延時也能接受，原因是別人在說話的時候我們一般在聽，

實際上1秒延時沒有關系，我們也要思考（話說有些人的CPU處理速度還沒有這么快）。

4) 有累積延遲：

技術一定要知道弱點，RTMP有個弱點就是累積誤差，原因是RTMP基于TCP不會丟包。

所以當網絡狀態差時，服務器會將包緩存起來，導致累積的延遲；

待網絡狀況好了，就一起發給客戶端。

這個的對策就是，當客戶端的緩沖區很大，就斷開重連。

2. HLS低延時

主要有人老是問這個問題，如何降低HLS延遲。

HLS解決延時，就像是爬到楓樹上去捉魚，奇怪的是還有人喊，看那，有魚。

你說是怎么回事?

我只能說你在參與謙哥的魔術表演，錯覺罷了。

如果你真的確信有，請用實際測量的圖片來展示出來，參考下面延遲的測量。

3. RTMP延遲的測量

如何測量延時，是個很難的問題，

不過有個行之有效的方法，就是用手機的秒表，可以比較精確的對比延時。

經過測量發現，在網絡狀況良好時：

. RTMP延時可以做到0.8秒左右。

. 多級邊緣節點不會影響延遲（和SRS同源的某CDN的邊緣服務器可以做到）

. Nginx-Rtmp延遲有點大，估計是緩存的處理，多進程通信導致？

. GOP是個硬指標，不過SRS可以關閉GOP的cache來避免這個影響.

. 服務器性能太低，也會導致延遲變大，服務器來不及發送數據。

. 客戶端的緩沖區長度也影響延遲。

. 譬如flash客戶端的NetStream.bufferTime設置為10秒，那么延遲至少10秒以上。

4. GOP-Cache

什么是GOP？就是視頻流中兩個I幀的時間距離。

GOP有什么影響？

Flash（解碼器）只有拿到GOP才能開始解碼播放。

也就是說，服務器一般先給一個I幀給Flash。

可惜問題來了，假設GOP是10秒，也就是每隔10秒才有關鍵幀，

如果用戶在第5秒時開始播放，會怎么樣？

第一種方案：等待下一個I幀，

也就是說，再等5秒才開始給客戶端數據。

這樣延遲就很低了，總是實時的流。

問題是：等待的這5秒，會黑屏，現象就是播放器卡在那里，什么也沒有，

有些用戶可能以為死掉了，就會刷新頁面。

總之，某些客戶會認為等待關鍵幀是個不可饒恕的錯誤，延時有什么關系？

我就希望能快速啟動和播放視頻，最好打開就能放！