直播應用中，rtmp和hls基本上可以覆蓋所有客戶端**，hls主要是延時比較大，rtmp主要優勢在於延時低。
低延時應用場景包括：
rtmp的特點如下：
主要有人老是問這個問題，如何降低hls延遲。
hls解決延時，就像是爬到楓樹上去捉魚，奇怪的是還有人喊，看那，有魚。你說是怎麼回事。
我只能說你在參與謙哥的魔術表演，錯覺罷了。
如果你真的確信有，請用實際測量的來展示出來，參考下面延遲的測量。
如何測量延時，是個很難的問題，不過有個行之有效的方法，就是用手機的秒錶，可以比較精確的對比延時。參考：rtmp延時測量
經過測量發現，在網路狀況良好時：
有沒有好的方案？有！至少有兩種：
srs的配置項：
# the listen ports, split by space.listen 1935;
vhost __defaultvhost__
備註：參考conf/full.conf的min.delay.com配置。
除了gop-cache，還有乙個有關係，就是累積延遲。srs可以配置直播佇列的長度，伺服器會將資料放在直播佇列中，如果超過這個長度就清空到最後乙個i幀：
vhost your_vhost
當然這個不能配置太小，譬如gop是1秒，queue_length是1秒，這樣會導致有1秒資料就清空，會導致跳躍。
有更好的方法？有的。延遲基本上就等於客戶端的緩衝區長度，因為延遲大多由於網路頻寬低，伺服器快取後一起發給客戶端，現象就是客戶端的緩衝區變大了，譬如netstream.bufferlength=5秒，那麼說明緩衝區中至少有5秒資料。
處理累積延遲的最好方法，是客戶端檢測到緩衝區有很多資料了，如果可以的話，就重連伺服器。當然如果網路一直不好，那就沒有辦法了。
考慮gop-cache和累積延遲，推薦的低延時配置如下（參考min.delay.com）：
# the listen ports, split by space.listen 1935;
vhost __defaultvhost__
當然，伺服器的效能也要考慮，不可以讓乙個srs程序跑太高頻寬，一般cpu在80%以下不會影響延遲。
低延時互動直播雙十一優惠活動
如果由於對從庫的查詢壓力過大，導致從庫cpu消耗過大，導致延遲，這種情況可以多加幾個從庫，分庫分表當然也是乙個解法。什麼情況下說需要分庫分表呢，就是你主庫更新量太大了，大到mysql開啟了並行複製都撐不住的時候，可能需要考慮，這個話題比較複雜，大家可以搜一些文章。明晚直播預告 直播互動福利 每晚.隨...
RTMP直播應用與延時分析
直播應用中，rtmp和hls基本上可以覆蓋所有客戶端 hls主要是延時比較大，rtmp主要優勢在於延時低。低延時應用場景包括 互動式直播 譬如2013年大行其道的美女主播，遊戲直播等等 各種主播，流 分發給使用者 使用者可以文字聊天和主播互動。其實會議1秒延時無所謂，因為人家講完話後，其他人需要思考...
RTMP直播應用與延時分析
直播應用中，rtmp和hls基本上可以覆蓋所有客戶端 hls主要是延時比較大，rtmp主要優勢在於延時低。低延時應用場景包括 互動式直播 譬如2013年大行其道的美女主播，遊戲直播等等 各種主播，流 分發給使用者 使用者可以文字聊天和主播互動。其實會議1秒延時無所謂，因為人家講完話後，其他人需要思考...