如何通過分塊編碼和分塊傳輸CMAF

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

對于當(dāng)今年輕人，電視早已沒什么吸引力，大家更喜歡通過網(wǎng)絡(luò)追劇、看比賽，甚至看各種直播內(nèi)容。那么延遲到底會有多重要？為什么要強調(diào)低延遲？

假設(shè)你和鄰居都在自己家看足球賽，鄰居看電視直播，你看網(wǎng)絡(luò)直播。鄰居那邊已經(jīng)在為進(jìn)球歡呼，你這邊因為延遲，球員才準(zhǔn)備起腳射門……你說低延遲重不重要。

面對數(shù)量激增的用戶和復(fù)雜的網(wǎng)絡(luò)環(huán)境，如何為觀眾提供更流暢的播放體驗，并且對直播類節(jié)目提供低延遲快速高效的內(nèi)容交付，已成為很多視頻平臺最關(guān)心，并且投入最多資源進(jìn)行改善的領(lǐng)域之一。

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

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

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

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

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

圖1：CMAF的對象命名

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

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

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

圖2：CMAF段的分塊編碼

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

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

接下來需要考慮如何實現(xiàn)分塊傳輸。

圖3：HAS媒體分發(fā)系統(tǒng)

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

接下來，這個塊會通過拉取的方式到達(dá)播放器。播放器讀取清單或播放列表，了解內(nèi)容描述信息，隨后計算希望開始播放的位置起點，并向?qū)?yīng)片段發(fā)出請求。清單中必須列出片段數(shù)據(jù)的早期可用性。對于MPEG DASH，這是通過MPD@availabilityTimeOffset參數(shù)實現(xiàn)的。

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

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

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

ULL-CMAF前提要求總結(jié)

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

CMAF片段中的內(nèi)容是分塊編碼的；

編碼器調(diào)整DASH清單/HLS播放列表，以適應(yīng)并標(biāo)注自己使用了分塊編碼的方式，并借此告知數(shù)據(jù)的早期可用性；

編碼器使用HTTP 1.1分塊編碼傳輸機制將內(nèi)容推送至源分發(fā)位置；

CDN在分發(fā)鏈上的每個環(huán)節(jié)，都使用HTTP分塊編碼傳輸機制傳播內(nèi)容，并最終到達(dá)客戶端；

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

對片段請求進(jìn)行精確計時，并在一個片段的有效時長內(nèi)請求所需片段；

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

具有估算吞吐量的方案，因為此時無法使用標(biāo)準(zhǔn)的Segment-timing技術(shù)；

緩沖區(qū)和自適應(yīng)邏輯必須能應(yīng)對非常低的緩沖；

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

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

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

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