為什麼奇藝要把 iPad 客戶端上的 MP4 流改為 TS 流呢?TS 相對於 MP4 有什麼優勢呢? | 知乎問答精選

 

A-A+

為什麼奇藝要把 iPad 客戶端上的 MP4 流改為 TS 流呢?TS 相對於 MP4 有什麼優勢呢?

2018年08月06日 知乎問答精選 暫無評論 閱讀 8 ℃ 次

為什麼奇藝要把 iPad 客戶端上的 MP4 流改為 TS 流呢?TS 相對於 MP4 有什麼優勢呢?

【Rio的回答(75票)】:

你說的應該是 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 流媒體服務器的網絡廣播台的網頁應用(預想是給 apple4.us 做 Livecast 的,就是聽眾只需要訪問一個網頁就能夠幾乎實時聽到訪談節目),採用的正是 HTTP Live Streaming 的思路。通過對 MP3 音頻流進行幀切分,基本能做到連續播放。唯一問題是瀏覽器不支持 TS 格式, < audio > 標籤在兩段 MP3 之前切換時會破音。這樣只能對談話類內容適用,如果播放連續的音樂有時候會聽出破綻。

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

[1]:?en.wikipedia.org/wiki

[2]:?arstechnica.com/apple

【trueice的回答(3票)】:

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流

【杜嵩的回答(1票)】:

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

【derrick的回答(1票)】:

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

【花滿樓的回答(1票)】:

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

【沈悅的回答(0票)】:

流媒體協議一共三種: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支持還可以。不知現在如何了。

【周昌的回答(0票)】:

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

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

【clonepig的回答(0票)】:

android ice cream也已經原生支持 hls.而且 使用ts切片方式 可以很容易實現流加密處理。mp4新規範實際已經支持無縫拼接,真正流媒體封裝器。

【劉孛的回答(0票)】:

Apple推HLS,Adobe推HDS,微軟推SmoothStreaming,Google在Android上從了Apple,在Chrome上據說是要推「更好的」DASH,FMP4現在也能實現流化播放,Adobe和微軟的都是基於FMP4的。

其實是寡頭們故意營造的壁壘而已,要在Apple的玩具上實現最佳體驗,肯定是得按Apple的遊戲規則來,與技術優劣無關。

如果非要分個高下,我會說是SmoothStreaming,Silverlight雖然死了,但是這個東東已經順利的坐上了Windows 8的頭等艙。微軟現在雖然被搞得比較狼狽,但是老底子在那裡,論東西精細度,還是它的強。

【孔凡的回答(1票)】:

一樓的給的太多了,簡單的說:就是在不增加設備和運營成本的情況下提升用戶體驗.

【彭寧的回答(0票)】:

一樓的正解,但是TS主要問題在於同等碼率下不及有效載荷不及MP4, 所以不及MP4清晰

標籤:-Rio -愛奇藝 -網絡視頻 -緩存 -流媒體 -MPEG2-TS -HTTP-Live-Streaming


相關資源:





給我留言