互動直播中，HLS協議的選用會有什麼考慮？

02-02

近兩年，互動直播越來越火，對於HLS標準協議複雜，延時過長，很多創業型公司都不選用HLS協議，直接使用RTMP或者HTTP FLV ，這個對於移動端特別是iOS 的用戶來說，具體的影響可能會有哪些？大家都是怎麼考慮這個的呢？

github上有個國人的流媒體伺服器的項目，叫srs，有興趣的同學可以上去研究一番哦。

--2016/09/08更

----------------------------

瀉藥。

1. hls的問題主要就是延時久。我在實驗室用nginx加rtmp module搭建的流媒體伺服器，開啟hls測量，區域網下延時30秒或者更多。主要是hls本質上是把視頻流切塊，每塊固定長度。伺服器接收流，轉碼，保存，切塊，再分發給客戶端，這裡就延時的原因。一般的低延時優化是在切塊做文章：縮短I幀間距。此時壓縮率降低，你的帶寬又得上去了。當然，像hls、dash這樣的協議，很多高校都在研究做優化（包括我的實驗室）擼paper，所以要發展，就再等等吧。

2. 至於題目問的創業公司都在用rtmp，主要是rtmp是主流呀，支持度又好，延時小。其實創業公司肯定以業務為主，技術為業務服務，要搞直播網站，買fms，wowza，搭一下集群就能跑啦，還不錯，那還躺hls做甚。創業公司大多不是技術主導的（除開公司的創始理念是技術），記住這句話。

3. 最後，30秒或者一分鐘就真的慢了嗎？看nba總決賽常常是外面叫了，我這邊還神馬都沒有。嗚嗚。看你延時的容忍度是多少吧。

先放個測試結果

同樣的播放流，在0丟包的情況下：
RTMP: 延遲 3s，相對於APP，延遲 1s。

HLS: 延遲 15s，相對於APP，延遲 13s。

做互動直播，延時大於1s的，玩個屁啊。一般人說話，幾百毫秒的延時是無感知的。大於1s了，你聽起來會覺得怪怪的，老是要等著對方回應。

RTMP是基於TCP的協議，可靠、但延時不可控。0丟包，也就是網路狀況極其好時，延時能達到1s。真正落地應用，有幾個人的網能達到這樣。

想要低達幾百毫秒的延時，只能用UDP。我司就是這麼做的，延時可低到200ms。但是UDP不可靠，所以要靠抗丟包策略補足。

Google發布的Quic協議就是基於UDP的，今年Google IO大會上發布的視頻軟體Duo，就是基於Quic開發的。

有人看我就再寫寫抗丟包策略。

謝邀。

hls由於協議本身存在的時間緩衝，不太適合做實時互動。較適合電視轉播之類的業務。

做互動的話，rtmp是比較好的選擇。

話說MPEG-DASH(HTML MSE)

謝邀~

利益相關：即構，專業視頻直播技術供應商

首先區分http-flv、hls和rtmp這三種協議。

hls是切片傳輸，每隔一段時間傳輸一次數據。這樣的方式直接導致了其直播延遲大到業界難以忍受。根據即構的數據，即使切片時間只有1s，都有至少10s左右的延遲。不過有一個好處，hls傳輸的文件可以網頁播放。

與之相比，rtmp的延遲就小得多。因為是遠程讀取伺服器數據，所以可以把延遲壓到200~300ms。（即構數據，網路ok，技術ok，不搞什麼奇奇怪怪極端測試的情況下，其他家能否有這個延遲就不敢保證了）並且， RTMP賦予開發端更多的掌控力，語音視頻通信的質量更加可控。可惜，不能網頁播放，得專門開發一個app。

hls太慢，rtmp網頁播不了，於是又出來一個http-flv傳輸。http-flv和rtmp差不多，其實就是往app或瀏覽器里嵌入一個flash

player播放，延遲能夠比肩rtmp。但既然播放器是定死的，渲染的質量就沒辦法控制了，各種新奇百怪的花樣也很難玩出來。

回到提主的問題，其實這個不用太擔心。大部分提供語音視頻技術的公司，三種協議都會提供。（切換一下罷了，分分鐘的事。當然，調試如果出了問題，也分分鐘玩死你……）所以，並非說http-flv和rtmp主流，hls就活不下去了，主要看需求。

現在直播需求主要集中在移動端，從即構的數據來看，pc玩直播的比例很小。大部分用戶都自行開發app的，所以選擇rtmp或udp私有協議的占多數。（比如花椒，映客，一直播這些即構科技的客戶）但也有客戶既要手機app播放，又要網頁播放，還得電腦播放，也沒問題，我們hls、rtmp和http-flv全給你搞出來都行。

當然，如果希望用戶體驗最優，直接開發一款app，使用rtmp還是最好的選擇。不過，如果對延遲有變態一般的需求，也可以來了解下即構的黑科技私有協議。延遲到100ms以下，當初測試的時候，延遲壓得喪心病狂，我幾乎要給組裡的牛人跪了……

RTMP、FLV、HLS，各有各自適用的場景。HLS不適於互動，適合於分享至微信、網頁的用戶來觀看。

hls對移動h5瀏覽器的支持較好，但同時也延遲較大。移動端播放前需要產生三個分片，每個分片至少得是一個GOP。一個GOP即使是2秒，也意味著這個環節耗費了6秒的延時。