演進中視頻流媒體容器格式與傳輸協議

最近幾年，在線視頻行業發展十分迅速,無論是視頻播放設備還是視頻傳輸技術都在不斷革新，從60英寸的UHD平面屏幕到平板電腦或者手機，從光纖網路到3G，4G的蜂窩網路技術，這些技術的革新使得流媒體視頻製作人員要支持多種自適應流技術。

隨著市場的競爭增加，利潤率下降，行業中的公司必須將視頻編碼，打包，存儲和交付成本縮減到最低限度，通常從兩方面來滿足。第一方面的技術是先進的編碼器，這方面Apple公司對HEVC推動作用顯著。與H.264相比，HEVC可以降低傳輸成本，同時提高觀眾的體驗質量。第二個方面技術是Common Media Application Format（CMAF），是一種文件格式規範，可以打包支持多種自適應流技術，包括HLS和DASH。將一種格式提供給多個目標的效率可以大大降低視頻編碼，打包和存儲成本。通過增強內容的可緩存性，CMAF也可以降低傳輸成本並提高QoE。

雖然新技術的出現會給行業發展帶來很多的好處，但是，與舊設備或播放器的兼容性不容忽視。在一定時期內，新技術並非取代舊技術而是有益的補充。本文將向讀者介紹視頻封裝打包（Format, Packaging）和分發協議（delivery protocol）方面近期的標準化技術，並討論如何將新技術整合到視頻流服務系統中，同時盡量保持與現有技術的兼容性。

1、編碼器的演進

流視頻其實就是關於編解碼器，容器和協議的。如果一個視頻文件沒有經過壓縮直接傳輸的話，即使是最快的互聯網連接也無法實現傳輸。因此必須減小視頻文件或實時視頻流的大小，但同時保持儘可能多的質量。這也是壓縮（也稱為編碼和轉碼）的由來。

多年來，AVC和H.264是在線視頻的主要壓縮技術或編解碼器，但近年來，HEVC受到青睞，因為它可以實現以一半數據速率獲得相同的視頻質量。Figure 1中顯示了各種壓縮格式的質量和效率提升。

圖1

HEVC涉及的許多實際編碼技術與AVC相同，但做了多方面的擴展。例如，當搜索幀間冗餘時，AVC呈現9個方向向量的選擇，而HEVC提供33個向量的選擇。 HEVC還可以提供更高質量的內容，如4K和高動態範圍（HDR）視頻。

圖2

一般而言，HEVC能以大約一半的數據速率提供與H.264相同質量的視頻，但這也會根據視頻內容類型而定。例如，對於1080p流，發布者可能能夠將數據速率從8Mbps降低到4Mbps而不會降低質量。

比特率的降低會對邊緣緩存成本產生重大影響，因為當視頻傳遞給最終消費者時，文件大小現在變小了。在某些情況下，例如通過4G傳送到高解析度平板電腦，這可以讓觀看者觀看1080p流而不是720p流，從而提高整體體驗質量。

與幾乎能在任何地方播放的H.264不同，支持HEVC播放的領域還比較有限，目前，HEVC主要用於向智能電視和類似的OTT和STB設備以及4K或UHD內容提供視頻。

2、流媒體容器格式和傳送協議的演進

無論使用哪種編解碼器壓縮視頻，該視頻都需要格式或容器存儲，還需要選擇流式傳輸協議進行傳送。我們將在下面的Streaming Protocols部分討論協議的最新進展，這裡先介紹容器格式和協議之間的關係。

簡而言之，容器格式是文件頭中的數據，它描述的是視頻和相關元數據如何存儲在文件中，就像擴展名為.MOV的文件是QuickTime文件；從技術上講，這意味著它以QuickTime容器格式存儲。雖然容器格式決定了文件兼容性和可播放性，但壓縮後的視頻和元數據構成了整個文件的絕大部分。容器格式實際上只取決於文件頭中的幾位數據。這也就意味著很容易從一種容器格式轉換為另一種容器格式，前提是不以任何方式修改壓縮視頻或元數據，只更改文件頭中的幾位即可。

相比之下，流傳輸協議是伺服器和播放端之間傳送視頻的規定。這些協議指定並使用容器格式，但也包含其他元素，如將在後面介紹的manifest files等。

在CMAF出現之前，各種流媒體協議使用了兩種不同的容器格式。 Apple的HLS使用MPEG傳輸流容器格式（MPEG-TS或.ts），這種格式與有線和IPTV行業數十年相同。當HLS新出現時，是將每個流被分成稱為segments的單獨文件，每個segment具有.ts擴展名，即使是短電影或節目也會有成千上萬個.ts文件，這使得文件傳輸複雜化並降低了緩存的有效性。後來，HLS更新為使用單個.ts文件，該文件的segments通過byte-range request進行檢索，這些請求在較長文件中定義了謹慎的chunks。

所有其他基於HTTP的協議，包括Dynamic Adaptive Steaming over HTTP（DASH），都使用了更新，更靈活的分段MP4容器格式（fMP4或.mp4）。雖然可以為每個segment生成單獨的fMP4文件，但DASH的默認操作模式是單個文件，其中通過byte-range request請求segment，從而簡化文件傳遞並提高文件緩存的能力。

因為HLS使用MPEG2傳輸流容器，而DASH和其他HTTP技術使用Fragmented MP4文件，如果視頻發布者想要訪問所有設備，它必須打包並提供每個視頻的兩個版本 - 一個是HLS，一個是DASH。直到2016年蘋果和微軟合作並宣布了DASH和HLS的通用格式之前，一直是需要提供兩種版本才能訪問所有設備。我們將在後面介紹這個通用格式。

2.1 流媒體協議

容器格式是簡單的元數據描述，詳細說明數據如何存儲在文件中，而流媒體協議定義了一個系統，通過該系統將視頻傳送給播放端。在過去十年左右的時間裡，流媒體協議已經從RTMP（(Real Time Messaging Protocol）發展到HTTP，RTMP是用於Flash流傳輸的協議，而HTTP是HLS和DASH使用的協議，並且Microsoft的Smooth Streaming （MSS）和Adobe的HTTP-based Dynamic Streaming（HDS）也是基於HTTP協議。

RTMP到HTTP的發展有幾個原因，首先，RTMP需要在播放器和伺服器之間建立持久連接，這意味著除標準HTTP Web伺服器外，還需要運行特殊伺服器。因為流式伺服器很昂貴並且只能處理有限數量的終端設備，使得成本提高。相比之下，基於HTTP的流式傳輸協議可以從標準Web伺服器運行，不需要流式伺服器。 RTMP也是Adobe許可的專有技術，可能會有與IP相關的問題。

RTMP數據包不能像HTTP數據包一樣進行緩存，這會降低總體傳輸效率，並且RTMP數據包通常會被防火牆阻止，這是因為防火牆可以在沒有流的情況下阻止潛在的查看者。最後，支持基於HTML5的瀏覽器級解決方案Flash已經要被棄用，更使得基於HTTP的傳輸方式成為最廣泛兼容的解決方案。除了基於RTMP的流媒體的衰落之外，Flash的棄用導致Adobe HDS的使用減少，而至少對於基於計算機的交付而言Silverlight的棄用導致MSS的使用下降（MSS仍然用於提供遊戲平台）。

但是，雖然RTMP已被HTTP作為傳遞協議取代，但它經常用於將流傳輸到雲中以用於實時流應用程序以及其他系統到系統通信。這是因為RTMP是基於TCP的，因此它具有糾錯功能和其他增強可靠性的特性

除了從RTMP到HTTP的過渡之外，為了能在大多數流媒體製作者所服務的各種連接帶寬和播放平台上播放流媒體，流媒體協議已經從單個文件傳輸演變為多個文件的自適應傳輸。 HLS和DASH以及MSS都是基於HTTP的自適應流媒體協議，它們的工作方式也非常相似。

也就是說，它們都使用視頻文件和manifest file的組合將視頻從HTTP伺服器傳送到播放端。要開始播放時，瀏覽器中的播放器首先檢索主清單文件，該文件指向所有質量級別的所有流的manifest file的位置。這些流級manifest file指向各個媒體文件中各個文件的segments或byte-range位置的位置。當播放期間帶寬或其他條件發生變化時，播放器使用主清單文件來查找另一個流，允許播放器動態調整其檢索的chunks或文件segments的質量和大小。

2.2 支持多種協議

實際上，大多數流媒體製作者必須使用多種協議來傳送內容。 Apple設備都使用HLS，計算機上的許多OTT平台和基於瀏覽器的解決方案也是如此。 智能電視主要使用DASH，許多其他基於瀏覽器的計算機解決方案也是如此。 而像Xbox這樣的老遊戲平台仍然使用MSS。

當向特定用戶分發優質內容時，文件加密和數字版權管理（DRM，digital rights management）使服務問題更加複雜。 具體來說，基於HTML5的交付的興起意味著生產商可能需要支持多個DRM，例如用於iOS設備和Safari的FairPlay，用於Microsoft瀏覽器和遊戲平台的PlayReady，用於Chrome和Android設備的Widevine，甚至可能是用於傳輸到智能電視，機頂盒或其他平台的額外的DRM。而加密，存儲所有協議的排列和DRM會增加存儲和傳輸成本。

2.3 JIT封包

用於最小化這些成本的一種技術稱為Just-in-Time（JIT）或動態封包。簡而言之，JIT打包是指基於伺服器的技術，可以從一組實時流或VOD MP4流中工作，並根據請求播放的終端的特殊要求對這些流進行打包和加密。如圖3所示。

圖3

具體來說，上圖左側的一組通用文件打包成多個組，以用於不同的協議和DRM。如前所述，由於容器格式僅由文件頭中包含的幾位數據確定，因此JIT技術可以即時轉換為正確的格式，並滿足請求視頻的客戶端的特定需求。在較高的層面上，JIT技術允許生產者在原始伺服器上存儲單一格式，從而節省了打包和存儲多種格式的成本。

除了封包之外，JIT技術還可以為不同的協議定製segment的大小。有些還可以管理中斷期，或自行根據提前設置好的規則來執行操作，例如在傳輸到移動設備時，提供1080p流就毫無意義，因為觀看者對720p和1080p之間是無法分辨的。

2.4 The Common Media Application Format (CMAF)

CMAF是分段媒體傳送的標準，形式化為MPEG-A Part 19或ISO / IEC 23000-19。 具體來說，CMAF使用ISO基礎媒體文件格式（ISOBMFF）容器，可以支持H.264，HEVC和其他編解碼器。 CMAF僅定義媒體格式，而不定義manifest file的結構或內容，並且HLS播放列表（.m3u8文件）和DASH清單文件（.mpd文件）都可以檢索CMAF格式的內容。

CMAF還簡化了為多種語言提供隱藏式字幕的過程，這一直是一項複雜的挑戰。一直以來，Apple使用基於文本的Web視頻文本軌道（WebVTT）標準在HLS中隱藏字幕（Figure4），並可能繼續使用它。

圖4

DASH可以使用WebVTT，但也使用稱為Timed Text Markup Language Profiles for Internet Media Subtitles and Captions或IMSC1，它不僅允許文本，還支持圖像，如許多亞洲和中東語言或非拉丁語系的語言所要求的語言。（Figure5）。因此，CMAF支持WebVTT和IMSC-1格式。

圖5

對於DRM，CMAF支持通用加密（CENC，Common Encryption），它可以將多個DRM合併到一個包中。CMAF還支持兩種不兼容的加密模式，AES-128 Counter (CTR)和AES-128 Cipher Block Chaining CBC（CBC）。當CMAF最初推出時，Apple的DRM FairPlay僅支持CBC，而PlayReady，Widevine和許多其他DRM僅支持CTR，這導致了單個加密文件包在Apple和非Apple平台上無法同時播放。

隨後，谷歌已將CBC納入Widevine，而微軟已承諾計劃於2018年發布的PlayReady 4.0也將支持CBC。但是在短期內單個加密文件集仍舊很難在所有相關終端上播放。

3、典型的應用場景

實施任何新技術的挑戰之一是它如何適應現有技術。考慮下面三種典型情形：

場景1 - 創建了一個新的移動應用程序，僅針對最新的iOS和Android手機。單個CMAF文件集能夠支持所有目標終端。如圖6所示，編碼器輸入單個文件，而輸出CMAF ABR集，其中包含用於DASH的MPD文件和用於HLS的M3U8文件。它們被上傳到CDN，從CDN可以將它們傳送到設備並按原樣播放。

圖6

場景1.5 – 支持按次付費的訂閱直播服務，比如現場音樂活動。用戶只能購買特定的新設備和瀏覽器，或使用Apple TV的APP。為了支持所有可用的終端，部署了兩個DRM; Widevine和FairPlay。如圖7所示，具有HLS和DASH的manifest的單個CMAF文件集和CBC加密可以使用FairPlay for HLS和Widevine for DASH來支持所需的設備。

圖7

顯然，這兩個應用程序僅支持一組有限的設備，這極大地限制了目標受眾。下面是一個更現實的場景。

場景2 – 提供catch-up TV或訂閱VOD服務，並且必須保留對現有設備的支持和向後兼容性，不僅要支持最新的iOS和Android設備，還要支持舊版本的設備和操作系統，以及一系列流行的，新舊的機頂盒和遊戲設備，如Apple TV，Fire TV，Chromecast，Roku，Xbox，智能電視，連接藍光播放器等。

圖8

在這種情況下，CMAF只能服務於一定比例的目標客戶，因此需要JIT解決方案才能實現全覆蓋。CMAF將有助於限制JIT封裝的負載，因為最流行的設備很可能是可以播放兼容CMAF的HLS和DASH的新設備，因此，只需要非常輕量級的manifest package，並且在緩存和CDN中使用更多共享視頻片段的能力將提高整體傳輸效率和性能。

使用JIT打包解決方案可以擴展對未升級的舊設備的支持，並繼續支持無法升級的舊設備。這可以確保觀眾數量不受限制，任何想要觀看的人都可以在他們想要的任何設備上觀看。

CMAF and JIT 協同工作

CMAF無法為所有終端提供服務，因為與CBC不兼容，而且許多終端都不會兼容（特別是遊戲設備）。 而除了傳統設備支持之外，DASH本身在實現方面存在差異，不同終端可能會阻止單一的manifest文件為所有DASH終端提供服務。 出於這些原因，JIT封包仍然是確保持續支持最廣泛設備，並保持靈活性以支持更多設備的最有效方式。

顯然，將CMAF格式文件傳輸給新設備的能力將提升伺服器效率，併產生可提高伺服器吞吐量和增強緩存的公共視頻片段。 但是，對於絕大多數流媒體服務而言，CMAF更多地被認為是JIT封包系統中支持的格式，而不是它的替代品。

4、 結論

使用HEVC，可以在與AVC相同的帶寬下獲得更高的視頻質量，或者以使用AVC的一半帶寬提供相同的質量。使用CMAF，只需編碼，打包和添加DRM一次即可訪問大量的播放設備。雖然CMAF的好處很明顯，並且基於HTML5的CMAF內容播放是未來發展的趨勢，但許多公司仍舊必須繼續支持與CMAF不兼容的舊設備，需要綜合使CMAF和JIT封包技術。

參考資料：

AWS Elemental, Evolving Standards in Video Mastering, Packaging, and Delivery, Streaming media Spotlight Series, 2018.5

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！