RTMP直播應用與延時分析

直播應用中，rtmp和hls基本上可以覆蓋所有客戶端**，

hls主要是延時比較大，rtmp主要優勢在於延時低。

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

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

你說是怎麼回事?

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

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

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

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

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

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

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

. nginx-rtmp延遲有點大，估計是快取的處理，多程序通訊導致？

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

. 伺服器效能太低，也會導致延遲變大，伺服器來不及傳送資料。

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

譬如flash客戶端的netstream.buffertime設定為10秒，那麼延遲至少10秒以上。

除了gop-cache，還有乙個有關係，就是累積延遲。

伺服器可以配置直播佇列的長度，伺服器會將資料放在直播佇列中，

如果超過這個長度就清空到最後乙個i幀：

當然這個不能配置太小，

譬如gop是1秒，queue_length是1秒，這樣會導致有1秒資料就清空，會導致跳躍。

有更好的方法？有的。

延遲基本上就等於客戶端的緩衝區長度，因為延遲大多由於網路頻寬低，

伺服器快取後一起發給客戶端，現象就是客戶端的緩衝區變大了，

譬如netstream.bufferlength=5秒，那麼說明緩衝區中至少有5秒資料。

處理累積延遲的最好方法，是客戶端檢測到緩衝區有很多資料了，如果可以的話，就重連伺服器。

當然如果網路一直不好，那就沒有辦法了。

直播應用中，rtmp和hls基本上可以覆蓋所有客戶端 hls主要是延時比較大，rtmp主要優勢在於延時低。低延時應用場景包括互動式直播譬如2013年大行其道的美女主播，遊戲直播等等各種主播，流分發給使用者使用者可以文字聊天和主播互動。其實會議1秒延時無所謂，因為人家講完話後，其他人需要思考...