HTTP Live Streaming

posted by 生活小白 on 3月 13, 2019 No Comments

CDN（Content Delivery Network）

在現今的網路環境，基於CDN（Content Delivery Network）來提供串流服務已成主流，而當中更分有「直播」與「點播」這兩大類別。
直播 指的是和內容來源同步播放，僅維持一定的時間差，像電視頻道或是實況轉播的節目，都是採用直播的形式。在直播的情況下，內容無法快轉或倒轉，只能隨著時間播放。（以前的直播是透過P2P的即時串流來做到）
點播 跟直播不同，點播的內容都是早在之前就儲好的檔案，並不像直播內容那樣都是由直播內容來源即時的產生。也因此，二者運用的技術會有所差異。

HLS（HTTP Live Streaming）

HLS（HTTP Live Streaming）HLS就是一種基於HTTP協定之上的串流協定，而且可適用於即時的直播用途。而這個HTML5 串流媒體協定是由Apple所提出的，現在雖然尚未成為IETF的標準，但是因為主流的平臺，諸如iOS/Android等重要的手持裝置平臺，皆已支援，使得它儼然成為在業界流通的準標準了。

HTTP的基本運作

按一般來說，HTTP的基本運作原則，就是一個請求可以取得一個檔案。倘若想要取得一個不知道長度有多長的檔案，像即時的串流就是如此，它很有可能不只是不知道有多長，甚至，它不會有結束。但是，有些多媒體檔案格式，在串流內容還沒結束時，形同檔案沒有完成，接收端也可能無法正確的剖析及使用。

HLS的分段串流應用

而HLS則是將串流的內容切割成一個個短的片段，例如，如果是影音內容的話，就把內容切割成約十秒左右的片段。不一定要切成十秒，究竟要切成幾秒，還可以考慮其他的因素。通常，這十秒的片段的格式其容器（container）格式為MPEG-TS，所包裝的視訊格式為H.264 ，而音訊格式為AAC。因此，整個影音的內容，就會被切割成許許多多的小片段。
當支援HLS的播放器要播放時，是從一個 .M3U8格式的播放清單開始，在這個播放清單中，會有一連串的MPEG-TS檔案的網址。此時，播放器只需要逐一的取出每個MPEG-TS檔案的網址，並且透過HTTP協定持續取得每一個MPEG-TS檔案，就能夠持續的播放整個串流的內容。
另外，它亦可以對播放清單做一定程度的預儲，使得前一個MPEG-TS播放完成時，下一個MPEG-TS已經準備好了，達到流暢的播放。若是預儲的份量夠，則可以提供足夠的緩衝效果。
雖說是「即時」但也不那麼的完全「即時」。因為，整個內容來源就算很快的完成格式的轉換、壓縮、及切割，客戶端也要載入起碼一個MPEG-TS，之後才能播放，也就是說，起碼也要再等十秒（若是單一個MPEG-TS切割成十秒的話），才能看到直播的內容。可在絕大多數的應用情境，都可以接受一定程度的直播延遲，這使得HLS有機會成為網路串流直播的主要選項。

CDN的快速擴展執行規模

當串流內容經過如上所描述的一連串程序，產生一個個MPEG-TS檔案之後，即可將它們送至CDN之上，接著再利用CDN的機制，將不同客戶端的來源，分配至不同的快取伺服器。如此一來，客戶端可以更就近、快速取得檔案，而流量也都不需要集中在特定的伺服器或機房，而可以分散掉，而分散化就是得到規模可擴充性的主要手段之一。
此外，同一個內容，還可以被編碼成不同的位元率（bitrate），也就是會提供不同的品質。因為透過網路連接上串流服務的客戶端，可能會有各種不同可能的連線頻寬，針對不同連線頻寬的客戶端，就可以藉此提供不同的品質，使得它們都可以流暢的觀看。當然除了按客戶的選擇之外，播放過程中影片可因應客戶端連線頻寬變化而執行品質調整。
倘若只有HLS，最終還是必須面臨傳統集中式架構的問題，即頻寬使用集中、無法分散的缺點。但正如前面所述及的，選擇了HTTP，等於選擇了為HTTP所開發出來的各種擴展規模的技術，包括CDN在內，有了優秀的規模可擴充性。（加上 HTTP 的通透性也比較好, 通用於大部分的防火牆，只要沒有刻意阻擋都可以正常瀏覽）

針對點播的HLS+CDN技術組合

使用靜態檔案部署於CDN的方式，來提供點播的檔案，例如使用 .MP4 做為容器格式，內含H.264 及AAC格式的視訊及音訊。這也行的通，但是MP4 的容器格式對播放器來說，需要多花點時間，才能取得相關的一些索引資訊，因此，在載入時間上就不像HLS那樣的短。在播放時，需要更多的時間才能開始收看。此外，這種方式在CDN上，會比HLS成本更高。
但HLS也並非毫無缺點，舉例來說，MPEG-TS格式的額外負擔比較重，因此，會提高整體傳輸時所需的位元率。

HDS (HＴＴＰ Dynamic Streaming)

除了上述的協定之外，Adobe 也為了自家的 Flash 媒體播放制定了個媒體伺服器，使用同為 Adobe 自定的 HTTP Dynamic Streaming(HDS)，以MP4壓縮影音媒體，並透過HTTP協定傳輸，而它跟HLS最大的分別就在於HDS是必須透過Flash才能播放， HLS 則不需要。
不過話雖如此，最新版的 Flash Media Server 將增加 HLS 協定, 讓 iOS(iPhone) 可以用 UIWebView 播放影片, 附檔名是 .f4m，以後也不需要再作額外的格式轉換便可直接播放。

Flash 將在網絡上絕跡

自2010年Steve Jobs公然地拒絕在行動裝置上支援Flash功能，並Flash提出了好幾項技術面的質疑，而時至今天我們也終於深深體會到Flash在行動裝置上的支援不足、即時串流效能低、經常出現安全漏洞等，首當其衝的改革者以Google及Amazon為頭，多間大型科技公司也陸續棄用Flash技術，轉投HTML5的懷抱，當中最關鍵地推動這場革新是以下所列出的幾個協定方案。

1.MediaSource Extensions

Adaptive Bitrate (ABR) streaming 為營造出一個最流暢的視覺體驗，提供了不同的畫質選擇，最多可調整出佔檔案半成以上的緩衝空間，以省減網絡傳輸上負擔。另外，MediaSource Extensions同時支援XBox,PS4, Chromecase 等不同的串流媒體。

2. VP9 video codec

HTML5所提供的VP9 video codec，讓影片質素再次提升，平均可減省35% bandwidth的佔有量，同時輕巧的檔案亦較容易達到4K與HD（60FPS）的效果（比平常的運轉速度快15-80%）。

3. Encrypted Media Extensions and Common Encryption

以前我們的影音平台僅局限於Flash,Silverlight與Access, PlayReady這樣的規格組合，而現在的Encrypted Media Extensions則打破傳統，讓諸如YouTube的網上影視內容可透過HTML5的播放器跨平台運作。配合Common Encryption在不同平台也能達到一定共識效果，使影片播放更快更流暢。

4. WebRTC

無論是事前錄製好的影片，還是即時放送的直播影片，WebRTC都允許我們在browser內使用 plugin-free Google Hangouts功能，讓我們隨時隨地都可以分享我們的影片至世界各地。

5. Fullscreen

利用HTML5𥚃面最新的Fullscreen API, 線上觀看4K的高質素影片也再不夢想。而且還切合任何標準的HTML UI。

6. Moving to <iframe> embeds

在HTML5的<video>語法中已預設為HTML5 player，此與Flash舊有的<object>嵌入式語法相比，新的embedder更切合<iframe>API的嵌入方式，能夠適應任何Browser。

HLS 的串流案例： Video.js :The Player Framework

Video.js 的好處
  1. 會自己判斷環境，如果是在電腦上就會用 flash 播放，在行動裝置就會使用 html5 播放
  2. 除了基本播放的功能，還有很多延伸的套件可以安裝 
Video.js 的壞處
  1. 新版本好像有 bug
  2. HLS 串流不支援倍速播放

HLS 的串流案例：hls.js:Dailymotion Developer Blog

hls.js 的好處
  1. 運作原理基於 HTML5 MediaSource Extension
  2. 採用HLS streaming protocol
  3. 簡單的影片切換機制
  4. 支援 VoD 與 Live (with DVR) streams
  5. 支援 P2P extensions (for hybrid CDN-P2P architecture)
hls.js 的壞處
  1. 聲響切換（HE-AAC，AAC）會出error（聲畫不同步） (MediaSource 的跨平台機制上並不完全支援聲響切換)
  2. 緩衝容量有限，如超過browser上限便會自動重載
  3. SourceBuffer.remove()用於分段加載以提供流暢的畫質切換，可不是所有Browser也支援分段緩衝，而且也不能準確刪除指定時間範圍

0 留言:

發佈留言