剛落幕的LiveVideoStackCon 2018音視頻技術大會上，Akamai媒體業務群首席架構師William Law通過主題演講介紹了如何通過分塊編碼和分塊傳輸CMAF，為觀眾提供極低延遲的視頻直播服務。本文由Akamai整理，并授權LiveVideoStack發布。

對于當今年輕人，電視早已沒什么吸引力，大家更喜歡通過網絡追劇、看比賽，甚至看各種直播內容。那么延遲到底會有多重要？為什么要強調低延遲？

假設你和鄰居都在自己家看足球賽，鄰居看電視直播，你看網絡直播。鄰居那邊已經在為進球歡呼，你這邊因為延遲，球員才準備起腳射門……你說低延遲重不重要。

面對數量激增的用戶和復雜的網絡環境，如何為觀眾提供更流暢的播放體驗，并且對直播類節目提供低延遲快速高效的內容交付，已成為很多視頻平臺最關心，并且投入最多資源進行改善的領域之一。

那么「分塊編碼」和「分塊傳輸」的「CMAF」到底是什么？

CMAF，一種全新的「容器」格式

隨著HTTP自適應流媒體（HAS）技術的發展，視頻直播觀眾對OTT質量和延遲提出了更高要求，甚至堪比傳統廣播電視節目。然而業內通常認為，HAS交付內容不可避免會遇到端到端延遲，甚至可能長達視頻片段時長的數倍，自然無法比擬廣播電視效果。但這種觀點已經站不住腳了，現在已經有HAS解決方案能將這種端到端延遲降低到遠低于一個片段時長的程度，甚至可以讓整體延遲與片段時長完全無關，這個解決方案就是超低延遲CMAF（ULL-CMAF）。

CMFA（Common Media Application Format，通用媒體應用程序格式）由標準化組織MPEG在2017年正式頒布，這種格式定義了一種碎片化的MP4容器，其中可以封裝視頻、音頻及文本數據。該格式最大的特點在于，能高效地讓HLS播放列表同時引用多個媒體片段和DASH清單，同時還在DASH ATSC3廣播配置文件的繼承方面實現了很多優勢，有助于進一步降低延遲。

但簡單來說，只使用CMAF片段還不足以降低延遲，CMAF容器還必須與編碼器、CDN以及客戶端行為完全匹配，在整個系統范圍內實現低延遲。

圖1：CMAF的對象命名

分塊編碼，化整為零提效率

降低延遲的第一步是分塊編碼。按照MPEG CMAF標準，CMAF軌道由多個對象組成，如圖1所示。「塊」是最小的可引用單位，其中至少包含一個moof 和一個mdat原子（Atom）。一個或多個塊組合在一起形成一個片段，而一個或多個片段還可進一步組合成一個片段。

標準的CMAF媒體片段將使用一個moof 和一個mdat 原子進行編碼，如圖2所示。其中mdat還包含一個IDR（Instantaneous Decoder Refresh，瞬時解碼器刷新）幀，每個片段開頭都會有。

圖2：CMAF段的分塊編碼

雖然每個「分塊編碼」片段會包含一系列「塊」，即多個moof/mdat 元（Tuple）組成的序列，如圖2所示，但只有第一個元具備IDR幀。將片段分解為更短的碎片，這樣做好處在于編碼器能在編碼完成后立即輸出每個塊。塊數量相同的情況下，這種「提前」輸出的做法可顯著降低整體延遲。

分塊傳輸，合零為整降延遲

接下來需要考慮如何實現分塊傳輸。

圖3：HAS媒體分發系統

編碼器會使用HTTP 1.1分塊傳輸編碼機制，將編碼后的CMAF塊推送至源位置。例如，對于一個產生4s 30fps片段的編碼器，將每4秒發出一個HTTP POST請求（每個請求對應一個片段），在接下來的4秒里，共有120個塊（每個塊時長為33毫秒）構成一個完整的片段，并發送至源位置。但編碼器并不會對每個單獨的塊發出一個POST請求。

接下來，這個塊會通過拉取的方式到達播放器。播放器讀取清單或播放列表，了解內容描述信息，隨后計算希望開始播放的位置起點，并向對應片段發出請求。清單中必須列出片段數據的早期可用性。對于MPEG DASH，這是通過MPD@availabilityTimeOffset參數實現的。

圖4：視頻直播過程中，播放器的啟動選項

我們可以用圖4所示過程為例，演示播放器起始播放算法對整體延遲的影響。這是一個會產生2秒片段的直播編碼器。圖中可見，系統正處于產生片段5的過程中。對于不分塊解決方案，為了盡可能降低延遲，必須從上一個完整可用片段（片段4）開始播放，這會導致整體延遲增加3秒。但如果使用每500毫秒（僅供示例，實際中分塊時長遠低于500毫秒）一個片段進行分塊編碼，播放器就可從包含IDR的上一個塊（塊5a）開始播放，此時延遲可降低至1秒。

此外，還有兩種方法可以進一步降低延遲。首先，播放器可以下載塊5a和塊5，但在開始播放前就從塊5a向前解碼塊5b，這樣可將延遲降低至500毫秒以內。第二種方法，播放器可將播放過程延遲1秒，隨后在塊6a生成后立即發出請求，這樣也可以降延遲降低到500毫秒以內。

ULL-CMAF前提要求總結

總的來說，只有在全部滿足下列要求的情況下，才能通過ULL-CMAF獲得穩定的低延遲交付：

CMAF片段中的內容是分塊編碼的；

編碼器調整DASH清單/HLS播放列表，以適應并標注自己使用了分塊編碼的方式，并借此告知數據的早期可用性；

編碼器使用HTTP 1.1分塊編碼傳輸機制將內容推送至源分發位置；

CDN在分發鏈上的每個環節，都使用HTTP分塊編碼傳輸機制傳播內容，并最終到達客戶端；

而客戶端也需要全部滿足下列要求：

對片段請求進行精確計時，并在一個片段的有效時長內請求所需片段；

在收到比特流后立即解碼，而不要等待片段結束。瀏覽器中使用的HTML5播放器必須使用Fetch而非XHR API，因為Fetch可以在數據下載完成前立即讀取響應的正文內容；

具有估算吞吐量的方案，因為此時無法使用標準的Segment-timing技術；

緩沖區和自適應邏輯必須能應對非常低的緩沖；

由于吞吐量波動，能夠在滯后于現場的情況下立即「趕超」。

所以說了半天，這種技術的效果到底如何？親自體驗一下吧。請使用Google Chrome瀏覽器（其他瀏覽器可能無法支持）訪問：

http://mediapm.edgesuite.net/will/dash/lowlatency/low-latency-public-example.html

該演示使用由開源FFmpeg生成的直播流，發布至Akamai Media Services liveOrigin?，并通過Akamai Media Delivery網絡交付，在客戶端使用開源播放器dash.js播放。視頻流為AVC 720p編碼，碼率2Mbps，片段時長6秒，每1幀的塊時長29.97fps，availabilityTimeOffset設置為5.967秒，延遲目標設置為2.8秒，視頻流在美國波士頓進行編碼。