HLS與RTMP ,RTSP對比

你說的應該是 HTTP Live Streaming [1] 吧。這個是 Apple 爲了提高流播效率開發的技術，特點是將流媒體切分爲若干 TS 片段（比如每10秒一段），然後通過一個擴展的 m3u 列表文件將這些 TS 片段集中起來供客戶端播放器接收。

這樣做相比使用 RTSP 協議的好處在於，一旦切分完成，之後的分發過程完全不需要額外使用任何專門軟件，普通的網絡服務器即可，大大降低了 CDN 邊緣服務器的配置要求，可以使用任何現成的 CDN。分發使用的協議是最常見 HTTP，代理服務器對這個協議的緩存優化相當成熟，而很少有代理服務器對 RTSP 的進行緩存優化。這對播放（軟）實時視頻有相當大的優勢，因爲這樣分發後，對源服務器的負載壓力小得多。

對於非實時視頻，同樣的好處也是存在的：如果你要在一段長達一小時的視頻中跳轉，如果使用單個 MP4 格式的視頻文件，並且也是用 HTTP 協議，那麼需要代理服務器支持 HTTP range request 以獲取大文件中的一部分。不是所有的代理服務器都對此有良好的支持。而 HTTP Live Streaming 則只需要根據列表文件中的時間軸找出對應的 TS 片段下載即可，不需要 range request，對代理服務器的要求小很多。所有代理服務器都支持小文件的高效緩存。

此外，HTTP Live Streaming 還有一個巨大優勢：自適應碼率流播（adaptive streaming）。效果就是客戶端會根據網絡狀況自動選擇不同碼率的視頻流，條件允許的情況下使用高碼率，網絡繁忙的時候使用低碼率，並且自動在二者間隨意切換。這對移動設備網絡狀況不穩定的情況下保障流暢播放非常有幫助。實現方法是服務器端提供多碼率視頻流，並且在列表文件中註明，播放器根據播放進度和下載速度自動調整。

至於爲什麼要用 TS 而不是 MP4，這是因爲兩個 TS 片段可以無縫拼接，播放器能連續播放，而 MP4 文件由於編碼方式的原因，兩段 MP4 不能無縫拼接，播放器連續播放兩個 MP4 文件會出現破音和畫面間斷，影響用戶體驗。

前兩年我嘗試過一個基於 HTML5 < audio > 標籤 + CBR MP3 格式 + Icecast 流媒體服務器的網絡廣播臺的網頁應用（預想是給 http://apple4.us 做 Livecast 的，就是聽衆只需要訪問一個網頁就能夠幾乎實時聽到訪談節目），採用的正是 HTTP Live Streaming 的思路。通過對 MP3 音頻流進行幀切分，基本能做到連續播放。唯一問題是瀏覽器不支持 TS 格式， < audio > 標籤在兩段 MP3 之前切換時會破音。這樣只能對談話類內容適用，如果播放連續的音樂有時候會聽出破綻。

iOS 設備上啓用 HTTP Live Streaming 非常簡單，也是蘋果官方推薦的方式。Adobe 的 Flash 流媒體服務器的新版本也要支持這個技術的 [2]。這樣普及開來是好事，用戶體驗更好、網絡壓

[1]: http://en.wikipedia.org/wiki/HTTP_Live_Streaming
[2]: http://arstechnica.com/apple/news/2011/04/adobe-throws-in-towel-adopts-http-live-streaming-for-ios.ars

2011-05-24 13 條評論

trueice，trueice

4 票，來自 Beo、知乎用戶、JasonChang 更多

mp4比較土，不是流式文件，必須有索引才能任意seek，因此adobe和微軟紛紛支持基於f4v afra box和ismv (fragmented mp4)的http streaming，可惜apple不支持。。
其實flv也是流式文件，比其它格式更簡單，apple同樣不支持。。。

目前各家只好都去支持MPEG-TS了，還是apple nb

另外，用TS做流媒體封裝還有一個好處，就是不需要加載索引再播放，大大減少了首次載入的延遲
如果片子比較長，mp4文件的索引相當大，影響用戶體驗（雖然標準支持moov tag壓縮，目前沒有什麼好的壓縮工具，客戶端也不都一定支持），這也是爲什麼apple推薦長片用ts流，qiyi也換成了ts流

2011-05-27 4 條評論

杜嵩，曾絕望得寫過視頻網站框架的程序員

1 票，來自蔣頔斐

TS比MP4更方便緩存，便於提高邊際緩存服務器性能；隨着Android 3.0發佈，Pantos(m3u8/ts)正在成爲事實標準。

2011-05-24 6 條評論

derrick，混互聯網的

1 票，來自梁峯

apple強制要求10分鐘以上視頻使用http live streaming

2011-05-24 4 條評論

花滿樓，陽光燦爛的日子

1 票，來自梁峯

apple審覈嚴格要求的，超過10分鐘的視頻只能用http live streaming，否則上不了架。

2011-05-25 1 條評論

劉孛，P2P,流媒體

1 票，來自知乎用戶

Apple推HLS，Adobe推HDS，微軟推SmoothStreaming，Google在Android上從了Apple，在Chrome上據說是要推“更好的”DASH，FMP4現在也能實現流化播放，Adobe和微軟的都是基於FMP4的。
其實是寡頭們故意營造的壁壘而已，要在Apple的玩具上實現最佳體驗，肯定是得按Apple的遊戲規則來，與技術優劣無關。
如果非要分個高下，我會說是SmoothStreaming，Silverlight雖然死了，但是這個東東已經順利的坐上了Windows 8的頭等艙。微軟現在雖然被搞得比較狼狽，但是老底子在那裏，論東西精細度，還是它的強。

2012-07-21 1 條評論

沈悅，程序員

流媒體協議一共三種：rtmp，rtsp，http live streaming(apple和adobe各一種)
rtmp是adobe的，rtsp android native支持，http live streaming(以下簡稱hls)當然是apple主打，後來adobe也終於開竅支持了。
rtmp和rtsp都要求特殊的服務器，例如rtmp要求FMS/red5, rtsp要求darwin等，hls只要普通的server，其好處一樓說的很清楚了。
類似於adaptive streaming的技術hls和rtmp都有，rtsp好像沒有。
針對帶寬壓力，rtmp支持rtmfp協議以利用p2p，不知hls有沒有。
本身iphone/ipad肯定支持hls/container/video codec格式的解碼硬件加速，android也支持rtsp/container/video codec格式的解碼硬件加速，至於rtmp/flv/sorenson h.263等，很悲催的mobile設備上無法硬件加速，所以性能不咋地。所以正常人支持mobile設備播放時，會選擇rtsp/mp4/h.264@android or http/ts/h.264@ios
請問一樓，針對pc平臺如何使用hls來實現audio/video live streaming？我以前記得HTML5雖然有audio/video tag，但對實時流媒體的支持不咋地，只是對VOD支持還可以。不知現在如何了。

2012-03-14 1 條評論

周昌，程序開發愛好者

實時流媒體還有一類對延時要求較爲嚴格的應用：視頻監控和視頻通話。這類流媒體採用HLS明顯是不合適的，一般採用HTTP progressive streaming，Android在4.0開始支持這種流媒體格式。能夠支持HPS的容器必須是流式的，如FLV, MKV, Android將支持WEM(即MKV)容器，攜帶VP8視頻格式。

因此選擇流媒體傳輸方式還有一個就是 HPS .