在現今的網路環境,基於CDN(Content  Delivery Network)來提供串流服務已成主流,不論是直播或是「點播(即隨選視訊-Video On Demand)」皆然。

直播指的是和內容來源同步播放,僅維持一定的時間差,像電視頻道或是實況轉播的節目,都是採用直播的形式。在直播的情況下,內容無法快轉或倒轉,只能隨著時間播放。

而點播就不同了,點播的內容,都是早就存在好的檔案,並不像直播內容,都是由直播內容來源即時的產生。也因此,二者運用的技術會有所差異。

在過去,直播不是透過即時的串流協定,就是透過P2P的即時串流來做到,理由之一,便是因為直播內容是即時產生,不方便事先產生一個靜態的檔案來供接收端取用。但目前使用CDN的方式來提供接收端存用,卻都是以靜態檔案的方式,因為,CDN的作用基本上,就是把靜態檔案分布到多個快取伺服器上去,以降低各地客戶端存取的延遲時間及分散流量。

HLS協定為HTTP提供網路內容直播技術

那麼直播要如何基於CDN來做到呢?要回答這個問題,就得從HLS說起了。

HLS(HTTP Live Streaming)通訊協定是由Apple所提出的,現在雖然尚未成為IETF的標準,但是因為主流的平臺,諸如iOS/Android等重要的手持裝置平臺,皆已支援,使得它儼然成為在業界流通的準標準了。

那什麼是HLS呢?簡單的來說,HLS就是一種基於HTTP協定之上的串流協定,而且可適用於即時的直播用途。

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

所以,要怎麼運用HTTP來做直播呢?

HLS的核心想法,是將串流的內容切割成一個個短的片段,例如,如果是影音內容的話,就把內容切割成約十秒左右的片段。不一定要切成十秒,究竟要切成幾秒,還可以考慮其他的因素。通常,這十秒的片段的格式其容器(container)格式為MPEG-TS,所包裝的視訊格式為H.264 ,而音訊格式為AAC。因此,整個影音的內容,就會被切割成許許多多的小片段。

當支援HLS的播放器要播放時,是從一個 .M3U8格式的播放清單開始,在這個播放清單中,會有一連串的MPEG-TS檔案的網址。此時,播放器只需要逐一的取出每個MPEG-TS檔案的網址,並且透過HTTP協定持續取得每一個MPEG-TS檔案,就能夠持續的播放整個串流的內容。

有一點很重要的是,在播放器播放某個MPEG-TS檔案的內容時,它可以取得整個清單中更之後的MPEG-TS檔案,甚至做一定程度的預儲,這使得前一個MPEG-TS播放完成時,下一個MPEG-TS已經準備好了,因此可以達到流暢的播放。若是預儲的份量夠,則可以提供足夠的緩衝效果,來因應時有的網路傳輸速度短暫、不穩定情況。

正因為它是把整個串流的內容切割成多個小檔案,因此,得以實現即時的串流。

但說是即時,也不那麼的完全即時。因為,整個內容來源就算很快的完成格式的轉換、壓縮、及切割,客戶端也要載入起碼一個MPEG-TS,之後才能播放,也就是說,起碼也要再等十秒(若是單一個MPEG-TS切割成十秒的話),才能看到直播的內容。但是,絕大多數的應用情境,都可以接受一定程度的直播延遲,這使得HLS有機會成為網路串流直播的主要選項。

當初HLS選擇基於HTTP是個不錯的決定,怎麼說呢?第一個考量是,HTTP是一個「穿透率」比較好的協定,因為它是瀏覽網站時所需的協定,因此,許多防火牆都會開放HTTP通過。倘若是其他的串流協定,不見得就會出現在防火牆的開放清單中。

CDN技術的應用,協助快速擴展執行規模

此外,還有一個重要的好處,就是有許多擴展規模的技術,都是基於HTTP而做的,這是為了開發能承載高流量、大規模的網站而研發的,如今都可以運用在HLS服務的擴展規模之上,例如CDN就是其中之一。

當串流內容經過如上所描述的一連串程序,產生一個個MPEG-TS檔案之後,即可將它們送至CDN之上,接著再利用CDN的機制,將不同客戶端的來源,分配至不同的快取伺服器。如此一來,客戶端可以更就近、快速取得檔案,而流量也都不需要集中在特定的伺服器或機房,而可以分散掉,而分散化就是得到規模可擴充性的主要手段之一。

此外,同一個內容,還可以被編碼成不同的位元率(bitrate),也就是會提供不同的品質。因為透過網路連接上串流服務的客戶端,可能會有各種不同可能的連線頻寬,針對不同連線頻寬的客戶端,就可以藉此提供不同的品質,使得它們都可以流暢的觀看。

而使用HLS的好處之一,也包括了播放過程中,可因應客戶端連線頻寬變化而執行品質的調整。

當播放時,發現客戶端的頻寬持續不足的情況,便可以將它導向另一組位元率較低的MPEG-TS檔案,以提高它播放的流暢度,而這個轉換的動作,在HLS的設計下,是可以動態的進行。所以,你可以看得出來,這樣的設計,有助於行動裝置在多媒體串流的播放,因為行動裝置的連線品質通常變化動態,會比個人電腦來得還大。

所以,經過這樣的說明,就不難了解HLS和CDN之間的關聯性。倘若只有HLS,最終還是必須面臨傳統集中式架構的問題,即頻寬使用集中、無法分散的缺點。但正如前面所述及的,選擇了HTTP,等於選擇了為HTTP所開發出來的各種擴展規模的技術,包括CDN在內。這使得立足於CDN的HLS,有了優秀的規模可擴充性。

現在,許多雲端平臺都提供CDN的服務,例如Amazon的CloudFront,這更便於串流服務的提供者,因為只需將串流內容直接送往CDN,即可處理掉擴展服務規模的許多技術議題。在這裡,雲端的平臺技術,對即時串流服務,起了很大的作用。

應用HLS+CDN的成本不一定低

此外,即使不是即時的串流,也可以使用HLS+CDN的技術組合。也有不少「點播」的服務者,使用靜態檔案部署於CDN的方式,來提供點播的檔案,例如使用 .MP4 做為容器格式,內含H.264 及AAC格式的視訊及音訊。

這也行的通,但是MP4 的容器格式對播放器來說,需要多花點時間,才能取得相關的一些索引資訊,因此,在載入時間上就不像HLS那樣的短。在播放時,需要更多的時間才能開始收看。此外,這種方式在CDN上,會比HLS成本更高。

但HLS也並非毫無缺點,舉例來說,MPEG-TS格式的額外負擔比較重,因此,會提高整體傳輸時所需的位元率。

總而言之,HLS的設計搭上CDN基礎設施的愈趨完備,使得它成為目前多媒體串流服務的主流選項。以現在服務的品質及規模來看,這個組合會流行好一陣子。

作者簡介


Advertisement

更多 iThome相關內容