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

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

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

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

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

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

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

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

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

圖1：CMAF的對(duì)象命名

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

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

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

圖2：CMAF段的分塊編碼

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

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

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

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

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

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

圖4：視頻直播過(guò)程中，播放器的啟動(dòng)選項(xiàng)

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

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

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

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

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

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

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

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

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

對(duì)片段請(qǐng)求進(jìn)行精確計(jì)時(shí)，并在一個(gè)片段的有效時(shí)長(zhǎng)內(nèi)請(qǐng)求所需片段；

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

具有估算吞吐量的方案，因?yàn)榇藭r(shí)無(wú)法使用標(biāo)準(zhǔn)的Segment-timing技術(shù)；

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

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

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

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

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