簡單解釋一下CMAF

所謂流媒體傳輸?shù)摹笔ケ敝傅氖且唤M文件被安全地傳輸?shù)剿心繕硕它c。最有可能幫助實現(xiàn)這一目標的“候選”是通用媒體應用程序格式（CMAF）。盡管目前CMAF還不能將”圣杯”交付給所有客戶，但它所具備的互操作性的DNA，將極大地簡化發(fā)布者（publishers）和播放器（players）之間的兼容性。最終，它可能傳遞出”圣杯”。

簡單解釋一下CMAF

CMAF是ISO/IEC23000-19規(guī)定的分段媒體傳送的標準。具體來說，CMAF基于ISO Base MediaFile Format（ISOBMFF），包含加密方式（CENC）。它支持H.264、HEVC和其他codec，以及Web Video Text Tracks Format（WebVTT）和IMSC-1字幕。與DASH和HTTPLive Streaming （HLS）不同，CMAF不是一種演示格式（presentationformat），它是一種容器格式，可以包含一組音頻/視頻文件，被用于多種演示格式（presentationformats）以及多DRM的支持。

CMAF試圖解決的問題如圖1所示，它來自于2018年10月在洛杉磯舉行的Web Application Video Ecosystem （WAVE）項目的WAVE Boot Camp （更多關于WAVE的內(nèi)容將在稍后做進一步介紹）。為了服務于圖中右側(cè)所示的所有終端，需要提供四種不同格式的文件：HLS、DASH、Smooth Streaming和 HTTP DynamicStreaming （HDS）。

CMAF將這四組文件替換為一組音頻/視頻MP4文件和四個自適應比特率manifests

從圖中可以看出，原來需要消耗四倍的時間來編碼/打包，也將占用四倍的源端存儲空間，并且降低了內(nèi)容的可緩存性。使用CMAF，只需要一組分片mp4格式的音視頻文件和非常輕量的四種自適應比特率（ABR）格式的manifest文件。理論上，這減少75%的編碼和存儲成本，并使緩存更加高效。 對于大多數(shù)發(fā)布者而言，CMFA節(jié)省的成本被夸大了

對于大多數(shù)用戶來說，CMAF的節(jié)省被夸大了，因為有很多技術都可以獲得相同程度的節(jié)省。just-in-time（JIT）打包器就是一個典型的例子，它可以輸入一組MP4文件（實時或點播視頻），然后根據(jù)每個查看者的需要進行動態(tài)打包。這意味著一組MP4文件，而不是四個，并且沒有轉(zhuǎn)碼。使用JIT打包的公司認為CMAF可以提高一定的效率，但肯定不會在編碼和存儲成本方面節(jié)省75%。

例如，我與Kaltura的首席架構師Eran Kornblau交談過，他說：“我們有自己的just-in-timepackager，并且是非常高效的。它輸入MP4流并輸出所有必要的協(xié)議，提供了很大的靈活性，因為我們不必事先進行編碼和打包。”

我向Kornblau詢問了有關成本方面的問題，因為JIT打包需要服務器一直保持運行狀態(tài)。他回答說：“我們的JIT打包服務非常高效，所以提前打包到CMAF并不會比JIT打包節(jié)省大量資源?！蔽覐腁nevia的壓縮產(chǎn)品執(zhí)行副總裁Jerome Blanc那里得到了類似的回答，他也部署了JIT打包。他說：“我們優(yōu)化了打包和加密引擎，所以成本不高；也許我們可以通過交付靜態(tài)內(nèi)容而不是JIT來降低10%左右的CPU成本?！?/p>

JIT并不是在單個數(shù)據(jù)存儲中提供多種格式的唯一方法。根據(jù)Twitch的首席研究工程師兼工程經(jīng)理沈悅時的說法，CMAF對Twitch的短期利益影響并不大，因為它可以通過HLS實現(xiàn)所有相關的目標。沈悅時解釋道：“對于不支持HLS的目標平臺，我們的播放器可以實時轉(zhuǎn)換為DASH。”當然，Twitch面對的主要是計算機和移動設備，它們普遍支持HLS，而智能電視則普遍支持DASH，在這種環(huán)境中添加tranmuxing（指remux HLS to DAHS）可能會很復雜。

需要說明的是，CMAF確實比JIT打包提高了一些存儲和緩存上的效率，但是其程度取決于你的分發(fā)體系結(jié)構以及是在原始服務器上打包還是在邊緣打包?；仡橝kamai的生態(tài)系統(tǒng)中CMAF的早期用戶，媒體云工程公司的首席架構師Will Law表示：“從我們這邊來說，我們看到的最大好處是，在HLS / TS 多DRM實現(xiàn)被單層 HLS / CMAF的實現(xiàn)取代后，我們的緩存效率提高了?！比欢?，對于大多數(shù)生產(chǎn)者來說，CMAF并沒有實現(xiàn)圖1中所提出的4倍編碼/存儲的節(jié)省。

內(nèi)容保護方面呢？

使用DRM部署CMAF最主要的障礙可能與CMAF中兩種不兼容的加密模式有關。THEO Technologies的首席技術官Pieter-Jan Speelmans這樣解釋：“CMAF中有兩種加密模式：CBC（有時也被稱為CBCS）和CTR，前者主要用于Apple 的FairPlay DRM，后者用于Widevine和PlayReady。由于Apple不想添加對CTR的支持，因此谷歌和微軟已經(jīng)在他們的DRM系統(tǒng)中增加了對CBC的支持。

然而，對于某些特定級別的DRM，加密模式還是需要硬件支持的。不支持CBC模式的舊設備將無法支持硬件級的DRM。同樣地，當內(nèi)容解密模型（CDMs）已經(jīng)更新到支持CBC時，你的設備也需要獲得這樣的更新，然后才能播放此加密內(nèi)容。老舊的OTT設備（如智能電視和機頂盒等）和一些未更新的移動設備可能存在這樣的問題。軟件DRM則可以在應用程序中交付以規(guī)避此問題，但它不是硬件級別的DRM。

NBC體育數(shù)字視頻技術的副總裁David·McLary在NAB 2019年的報告“大規(guī)模部署CMAF，DASH和HLS的最佳實踐”中詳細闡述了這個問題，David稱“我們與之交談的每一個人都曾表示CBCS支持即將在未來12-18個月內(nèi)推出（用于新設備和更新）。但是總是會遇到老舊設備的問題。只支持CTR而不支持CBCS的設備不會消失，我不知道它們是否會得到更新。雖然我們在不斷發(fā)展，但也不得不考慮支持舊設備的問題?！?/p>

不僅僅是硬件終端，一些瀏覽器版本也有問題。例如，EZDRM的CEO David Eisenbacher指出：“微軟的Edge和IE瀏覽器目前不能播放某些PlayReady保護的CBC加密視頻。當微軟發(fā)布基于Chromium的新版本時，應該會解決Edge的問題，但可能不會解決IE的問題。”

對于設備支持問題的總結(jié)，請查看Phil Harrison在LinkedIn上發(fā)表的一篇非常出色的文章，“關于CBCS的時間”。

首次部署時，CMAF將僅是“另一種格式”

雖然CMAF承諾了對所有終端都只有一組文件，但大多數(shù)初始實現(xiàn)都還將使用CMAF加在DASH或HLS上，以此來支持老舊的設備。正如McLary在他的NAB演講中所說的那樣：“我們將在一段時間內(nèi)同時部署HLS和CMAF。在這中間存在一段過渡期，而不是在一天之內(nèi)全盤改變。因此，在這個中間階段，要弄清楚難點在哪里將會是非常復雜的?！?/p>

在必讀的白皮書《CMAF的大規(guī)模部署》中，來自Brightcove的四位作者（包括Yuriy Reznik）概述了他們在Brightcove視頻云平臺上部署CMAF的愿景，其概述如圖2所示。顧名思義，視頻云是一個基于云的系統(tǒng)，它包含多個組件，比如上下文感知編碼，以及一個動態(tài)交付系統(tǒng)，該系統(tǒng)管理傳輸、打包、加密以及將內(nèi)容交付到CDN。

Brightcove視頻云平臺

從積極的角度來看，Brightcove作者表示將CMAF添加到他們的生態(tài)系統(tǒng)非常簡單直接，他們稱“將CMAF添加到已經(jīng)支持動態(tài)轉(zhuǎn)換為幾種現(xiàn)有交付格式的系統(tǒng)中是相對簡單的，并且可以歸結(jié)為以下幾個方面：更嚴格的控制配置文件的生成和編碼，增加ISOBMFF傳輸器的功能，并向HLS和DASH manifest生成器添加附加規(guī)則，以生成與CMAF兼容的manifest?！?/p>

然而，他們也表明CMAF將作為一種格式的補充：“盡管在短期內(nèi)CMAF最有可能將必須與HLS、DASH和其他一些交付格式并存，這樣更多的設備將能夠給它解碼，我們將看到更顯而易見的好處。即使使用動態(tài)傳遞和交付，CDN的使用仍然不是最優(yōu)的選擇，相同內(nèi)容的多個版本在邊緣競爭CDN緩存。”簡而言之，從分片的角度來看，這意味著CMAF在使事情變得更好之前，可能會先將其變壞。

那么，什么時候?qū)MAF添加到現(xiàn)有系統(tǒng)的格式中是有意義的呢？在2019年5月的舊金山視頻技術會議上，Brightcove的Reznik做了一個有趣的演講，題為“關于CMAF：部署第三種流媒體格式能降低成本嗎？”

在這里，他首先對CDN上緩存哪些數(shù)據(jù)進行了建模，這清楚的表明了最受歡迎的數(shù)據(jù)或者最常被播放器檢索的數(shù)據(jù)被緩存的可能性最大。

有趣的是，這一點揭穿了交付4種格式會把與邊緣緩存數(shù)據(jù)相關的開銷增加4倍的說法并不正確。也就是說，如果你將Smooth Streaming傳送給1%的觀眾，將HDS傳送給1%的觀眾，將DASH傳送給5%的觀眾，將HLS傳送給93%的觀眾，你的緩存存儲成本不會翻四倍——它們很可能保持在1倍，因為只有HLS會被緩存。當然，對于非緩存格式還有其他成本和較低的服務質(zhì)量，但是純存儲成本并不會翻四倍。

當然，隨著CMAF越來越流行，這種概念會變得對其有利。如圖3所示，當具備CMAF功能的播放器的比例超過84%時，CDN成本應該能夠達到盈虧平衡。正如我們前面看到的，關于其他格式消耗的成本將增加，而這些設備的QoE將減少，因為數(shù)據(jù)沒有緩存在邊緣。

一旦84%的終端可以從CMAF文件中播放，CDN成本就會開始下降

CMAF將成為附加品的這一事實并不是出人意料的。瑞典Eyevinn Technology的媒體解決方案顧問馬格努斯?斯文森（Magnus Svensson）表示：“我仍然認為，我們將不得不使用多種編解碼器、多種交付格式和大量的設備，來應對一個碎片化的世界?！薄拔覅⑴c過的部署工作給我的教訓是，只要你想支持多種不同的設備，尤其是智能電視，你就需要多個工作流程?！?/p>

關于需要多長時間才能繼續(xù)發(fā)布多種格式的問題，這一點因發(fā)布者而異。但顯而易見的一點是，只要收入（無論何種形式）超過成本，就有必要繼續(xù)提供對老舊設備的支持。長此以往，這意味著什么呢？

好吧，別抱太大希望。根據(jù)MediaKind的Tony Jones的說法，“主要的問題是，當CMAF幾乎變得無處不在之前，它還是帶來了一種分發(fā)格式的挑戰(zhàn)。當然最終其通用性會帶來真正的好處之前，似乎可能還需要幾年時間才能淘汰其他格式。”

想要一個確切的數(shù)字嗎？在Bitmovin工作的產(chǎn)品營銷經(jīng)理Sean McCarthy和解決方案架構師Richard Fliam都表示：“許多新設備可以很好地使用CENC和標準的加密算法，但傳統(tǒng)設備需要更特定、更多變的格式。由于這個原因，CMAF還沒有為CDN帶來成本降低的好處，但是隨著客戶在未來5年多的時間里逐步淘汰老舊設備，CMAF對CDN花費的節(jié)省才可能會顯現(xiàn)出來。”

實現(xiàn)的復雜性會有所不同

無論多么的值得擁有或?qū)嵱?，大多?shù)OTT運營商仍然不會積極使用新的格式，除非它們能夠保護它、監(jiān)控它、用它獲利，并讓它在它們的所有目標設備上播放，不僅是針對當前內(nèi)容，還要包括舊版內(nèi)容。上面已經(jīng)講述了DRM如何使單一格式的交付變得復雜，后面還有其他幾個領域需要考慮。

首先，要理解CMAF需要單獨的音頻和視頻軌道。如果您已將所有內(nèi)容存儲為muxed文件格式，則必須重新處理該內(nèi)容才能與CMAF一起使用。在McLary的NAB演講中，NBC的McLary對這個問題評論道：“與你合作的大多數(shù)HLS都混入了音頻，所以當你想辦法開始混合HLS和CMAF工作流程時，音頻就成了一個大問題，尤其是當你處理服務器端廣告插入（SSAI）這樣的事情時，處理demuxed音頻（指在分離的文件中處理SSAI）這樣事情很快就會變得非常復雜?！?/p>

其次是廣告方面。當涉及到廣告插入，許多AVOD服務都無法對此進行控制。談到向CMAF的轉(zhuǎn)型時，一家不愿透露姓名的大型優(yōu)質(zhì)內(nèi)容發(fā)行商表示，“我們得到了廣告的支持，所以在我們啟動之前，我們一直在等待一些準備就緒。首先是谷歌廣告管理系統(tǒng)對CMAF的支持，我們了解到該支持將在［年底］到來。他們是我們的主要決策者，所以他們的支持是至關重要的。特別是在拼接方面，我認為目前音頻方面對解碼器的要求最具有挑戰(zhàn)性。同時，還需要保證所有的廣告滿足CMAF規(guī)格。

不僅僅是廣告插入方面，分析和監(jiān)控渠道有可能也需要更新。正如THEOTechnology的Speelmans所說，“根據(jù)你擁有的度量標準，你可能需要更新你的分析和監(jiān)控管道?！睂Υ?，我詢問了Telestream iQ的產(chǎn)品管理總監(jiān)Matthew Driscoll關于CMAF支持的問題，他回答說：“IQ的監(jiān)控探頭支持HLS和DASH流協(xié)議的ISOBMFF。一旦CMAF媒體在HLS播放列表或DASH清單中被引用，就可以主動監(jiān)控發(fā)布源或發(fā)布緩存?！?/p>

至于轉(zhuǎn)換成CMAF需要多長時間，Speelmans說，“根據(jù)我的經(jīng)驗，大多數(shù)打包程序現(xiàn)在已經(jīng)支持它了，所以這只是一個重新配置的問題。播放器通常也能夠透明地支持它。能不能完成這項工作取決于你的管道設置，但我估計工作時間不會超過兩周。請記住，你之后還需要做一個完整的測試，這意味著你需要投入更多的時間?！?/p>

當然，正如Eyevinn的Svensson所指出的那樣，“你添加的功能越多，系統(tǒng)也就變得越復雜。即使沒有CMAF，DRM和廣告插入本身也是很復雜的。我不確定CMAF本身是否增加了更多的復雜性，它更多的是格式、設備支持和功能的組合。如果你想接觸到帶有DRM保護內(nèi)容的各種設備，同時又想做動態(tài)廣告，那就變得非常復雜了?！?/p>

簡單性比低延遲更重要

低延遲CMAF已經(jīng)成為一種可行的技術，可以將延遲降低到1-3秒，這具體取決于您訪問的對象。盡管如此，一些目前正在實現(xiàn)CMAF的OTT供應商表示不要將CMAF等同于低延遲。一位不愿透露姓名的用戶說：“CMAF并不等于低延遲。只是每個人都關注這兩者，所以將它們混淆了。”另一個不愿透露姓名的人說：“現(xiàn)在就開始改用CMAF；在Apple低延遲HLS規(guī)范和其他基于CMAF的方法之間，低延遲方面的問題還需要一段時間才能解決，不要因此而推遲CMAF的實現(xiàn)?！?/p>

對于大多數(shù)OTT供應商來說，采用CMAF的最迫切動機是其簡單性，而不是低延遲。在NAB上，WarnerMedia的多平臺視頻解決方案主管Cooper Pope展示了圖4并評論道：“我能想到我們實現(xiàn)closedcaptions的六種不同方式、四種不同的縮略圖預覽以及很多廣告插入方法。無論何時你添加一個新設備，它只是添加到你必須要做的工作清單中，以保持功能的完整性。在這一點上，你沒有創(chuàng)新，你只是在重復你已經(jīng)做過的事情，因此，你是在尋找一個更好的方法來把事情做好?！?/p>

WarnerMedia希望通過CMAF簡化內(nèi)容交付

另一家OTT供應商說：“對我們來說，部署CMAF的另一個巨大動力就是CMFA使我們從碎片化中解脫出來。我們?yōu)榭缙脚_的DRM支持生成了四個不同的打包。（我相信其他發(fā)布商也在為移動/CTV/web定制包）。遷移到CMAF/CENC的想法對我們來說非常有吸引力，因為這樣只需要更少的編碼、封裝和存儲花費”

Anevia的Blanc有效地總結(jié)了這個概念：“很少有人談論CMAF的主要潛在優(yōu)勢是它的簡單性。一些客戶目前提供六種ABR格式和DRM的不同組合，有的甚至有更多，這使得測試和質(zhì)量控制非常復雜。如果可以向所有設備發(fā)送同一種格式，CMAF將在降低復雜性和減少測試方面帶來巨大的成本節(jié)約。”

CMAF是下一個大事件

想象一下，如果每個電視制造商都必須使用全球所有的頻道來測試他們的新電視機，并且每個頻道都要在所有制造商的每臺新電視機上進行測試，那么電視行業(yè)將會怎樣演變。不兼容現(xiàn)象將會蔓延，市場發(fā)展將會停滯。這和目前流媒體領域發(fā)生的事情在本質(zhì)上是一致的，并且給OTT發(fā)行商帶來了巨大的兼容性負擔。在這種負擔下，OTT行業(yè)還能如此成功是一件令人驚訝的事。

本質(zhì)上，這個兼容性問題是WAVE設計要解決的核心所在。從技術上講，WAVE是一個由消費者技術協(xié)會（CTA）發(fā)起的項目。CTA的網(wǎng)站稱，該項目的目標是“改善互聯(lián)網(wǎng)傳輸?shù)纳虡I(yè)視頻在消費者電子設備上的處理方式，并方便內(nèi)容創(chuàng)作者更便捷地將視頻分發(fā)到這些設備上。”

我與技術工作組主席Will Law和微軟的John Simmons進行了交談。John Simmons是幫助設計媒體源擴展（MSE）和加密媒體擴展（EME）等web標準的工作組成員，他還與蘋果公司合作開發(fā)了CMAF。他們指出，WAVE項目是在CMAF標準化的時候成立的，現(xiàn)在在整個流媒體生態(tài)系統(tǒng)中已經(jīng)有60多名成員（請參考項目參與者的完整列表）。

WAVE計劃通過為內(nèi)容、設備和API創(chuàng)建規(guī)范和測試套件來提高互操作性，而這在以前是不存在的。毫不奇怪，CMAF是所有規(guī)范的核心。在IBC 2019大會上，WAVE發(fā)起了由蘋果公司的Krasimir Kolarov主持的CMAF行業(yè)論壇。該論壇是WAVE的一個分支，旨在強調(diào)CMAF在WAVE規(guī)范和測試套件中的作用，并鼓勵大家采用（如圖5所示）。

WAVE的三個焦點

net-net是這樣的：CMAF是由Apple和Microsoft開發(fā)的，是多種ABR格式（包括HLS、DASH、HLS和HDS）的統(tǒng)一容器。WAVE項目的重點是使用CMAF來創(chuàng)建規(guī)范和測試套件，以確保內(nèi)容/設備的互操作性。在兩年內(nèi)，內(nèi)容發(fā)布者將不會選擇沒有通過適當測試套件的編碼器/打包器，并且不會有任何播放器、硬件或軟件會在沒有經(jīng)過類似測試的情況下發(fā)布。新特性、API和編解碼器將以標準化的方式添加，從而實現(xiàn)真正的創(chuàng)新，而不僅僅是讓內(nèi)容在目標設備上播放的繁瑣工作。

認可CMAF，不僅僅只是認可它是一種新的容器格式，而是認可一個具有遠見和影響力的行業(yè)組織，可以將簡單的規(guī)范轉(zhuǎn)換為互操作性。這在短期內(nèi)不會發(fā)生，但正如一位publisher所說，“再給AV1幾年時間，我們也許就能開始在這件事上做文章了?！蹦壳斑€沒有其他標準或規(guī)范能實現(xiàn)這種愿景。

CMAF還不適合所有人

盡管如此，CMAF還并不適合所有人，至少是現(xiàn)在。當我向編碼器供應商/ OVP Mux的聯(lián)合創(chuàng)始人兼產(chǎn)品主管Steve Heffernan詢問有關CMAF的問題時，他說：“我們當下不使用CMAF，只使用HLS+TS。我們的客戶依賴我們根據(jù)他們需要的功能來決定他們使用的格式，我們選擇從HLS+TS開始，因為它擁有最廣泛的單一格式覆蓋范圍，包括較老的iOS設備。由于iOS CMAF的普及和DRM的支持，我們可能會在不久的將來轉(zhuǎn)向到CMAF交付，?！?/p>

Marcus Johansson是OSK Berlin的一名流媒體工程師，他說：“我們還沒有在任何項目中真正實現(xiàn)CMAF，因為我們目前的平臺已經(jīng)在我們需要支持的所有設備和瀏覽器上和HLS一起使用了。到目前為止，超低延遲的直播還不是必需的。因此，盡管我們已經(jīng)開始接觸到一些相關咨詢，并在實驗室中運行低延遲的原型，但我們沒有通過DASH/HLS或者使用分塊流共享分布式資源，”

DaCast的首席運營官兼業(yè)務開發(fā)和銷售副總裁Greg Ellis說：“每個人都想要更低的延遲，而CMAF看起來是擁有真正可擴展性的最佳選擇。但那些規(guī)模更大、增長最快的客戶對其他具有更高優(yōu)先級的增強功能的需求，導致我們今年幾乎每個季度都推遲實施CMAF。”

因此我們沒有聽到很多“不”，只是很多“尚未”。

大多數(shù)行業(yè)正在加速發(fā)展

此外，和我交談過的大多數(shù)技術公司要么已經(jīng)實施了CMAF，要么正在全速前進。他們包括像Bitmovin、Brightcove、CapellaSystems、Encoding.com、hybrid k、Media Excel、MediaKind、Mux、Telestream和VideonCentral等編碼供應商。Encoding.com甚至在其質(zhì)量控制過程中增加了CMAF合規(guī)性檢查，以確保符合規(guī)范。

CMAF得到了大多數(shù)播放器廠商的全面支持，包括Bitmovin、JW player和THEOTechnologies。Akamai已經(jīng)支持CMAF一年半多了，而Limelight Networks已經(jīng)有了概念運作的證明，并計劃在2020年推出。云轉(zhuǎn)碼供應商Wowza和Softvelum現(xiàn)在支持CMAF。

與我交談過的所有顧問都至少有一個CMAF項目。除了上面提到的那些，RealEyes的CEO David Hassoun稱，他幫助一個不知名的OTT供應商“從HLS傳輸流遷移到CMAF”。其主要目標是將DRM全面統(tǒng)一起來，尤其是在互聯(lián)網(wǎng)上，以部分取代Flash （Flash仍然只用于DRM）。”

咨詢師Mark Kogan報告說，他幫助一家大型以色列電信公司啟動了一項基于CMAF的4K HEVC HDR服務，將世界杯轉(zhuǎn)播給Apple TV客戶。這項服務現(xiàn)在正被擴展到編碼DASH目標，如LG、三星和其他聯(lián)網(wǎng)電視。

如圖6所示，在Bitmovin的《2019年視頻開發(fā)者報告》中，25%的參與者計劃在2020年部署CMAF?？紤]到41%的參與者認為“在所有設備上重播”是他們最大的挑戰(zhàn)（首先是延遲54%），這并不讓人意外。

在Bitmovin的“2019年視頻開發(fā)者報告”中，有25%的參與者計劃實施CMAF

基本上，我看到的每一個地方，CMAF要么在使用中，要么在開發(fā)中，要么在認真考慮中?，F(xiàn)在開始使用CMAF還為時不晚，但肯定也不算早。