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

簡(jiǎn)單解釋一下CMAF

CMAF是ISO/IEC23000-19規(guī)定的分段媒體傳送的標(biāo)準(zhǔn)。具體來(lái)說(shuō)，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試圖解決的問(wèn)題如圖1所示，它來(lái)自于2018年10月在洛杉磯舉行的Web Application Video Ecosystem （WAVE）項(xiàng)目的WAVE Boot Camp （更多關(guān)于WAVE的內(nèi)容將在稍后做進(jìn)一步介紹）。為了服務(wù)于圖中右側(cè)所示的所有終端，需要提供四種不同格式的文件：HLS、DASH、Smooth Streaming和 HTTP DynamicStreaming （HDS）。

CMAF將這四組文件替換為一組音頻/視頻MP4文件和四個(gè)自適應(yīng)比特率manifests

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

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

例如，我與Kaltura的首席架構(gòu)師Eran Kornblau交談過(guò)，他說(shuō)：“我們有自己的just-in-timepackager，并且是非常高效的。它輸入MP4流并輸出所有必要的協(xié)議，提供了很大的靈活性，因?yàn)槲覀儾槐厥孪冗M(jìn)行編碼和打包?！?/p>

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

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

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

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

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

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

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

不僅僅是硬件終端，一些瀏覽器版本也有問(wèn)題。例如，EZDRM的CEO David Eisenbacher指出：“微軟的Edge和IE瀏覽器目前不能播放某些PlayReady保護(hù)的CBC加密視頻。當(dāng)微軟發(fā)布基于Chromium的新版本時(shí)，應(yīng)該會(huì)解決Edge的問(wèn)題，但可能不會(huì)解決IE的問(wèn)題?！?/p>

對(duì)于設(shè)備支持問(wèn)題的總結(jié)，請(qǐng)查看Phil Harrison在LinkedIn上發(fā)表的一篇非常出色的文章，“關(guān)于CBCS的時(shí)間”。

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

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

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

Brightcove視頻云平臺(tái)

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

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

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

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

有趣的是，這一點(diǎn)揭穿了交付4種格式會(huì)把與邊緣緩存數(shù)據(jù)相關(guān)的開(kāi)銷(xiāo)增加4倍的說(shuō)法并不正確。也就是說(shuō)，如果你將Smooth Streaming傳送給1%的觀(guān)眾，將HDS傳送給1%的觀(guān)眾，將DASH傳送給5%的觀(guān)眾，將HLS傳送給93%的觀(guān)眾，你的緩存存儲(chǔ)成本不會(huì)翻四倍——它們很可能保持在1倍，因?yàn)橹挥蠬LS會(huì)被緩存。當(dāng)然，對(duì)于非緩存格式還有其他成本和較低的服務(wù)質(zhì)量，但是純存儲(chǔ)成本并不會(huì)翻四倍。

當(dāng)然，隨著CMAF越來(lái)越流行，這種概念會(huì)變得對(duì)其有利。如圖3所示，當(dāng)具備CMAF功能的播放器的比例超過(guò)84%時(shí)，CDN成本應(yīng)該能夠達(dá)到盈虧平衡。正如我們前面看到的，關(guān)于其他格式消耗的成本將增加，而這些設(shè)備的QoE將減少，因?yàn)閿?shù)據(jù)沒(méi)有緩存在邊緣。

一旦84%的終端可以從CMAF文件中播放，CDN成本就會(huì)開(kāi)始下降

CMAF將成為附加品的這一事實(shí)并不是出人意料的。瑞典Eyevinn Technology的媒體解決方案顧問(wèn)馬格努斯?斯文森（Magnus Svensson）表示：“我仍然認(rèn)為，我們將不得不使用多種編解碼器、多種交付格式和大量的設(shè)備，來(lái)應(yīng)對(duì)一個(gè)碎片化的世界。”“我參與過(guò)的部署工作給我的教訓(xùn)是，只要你想支持多種不同的設(shè)備，尤其是智能電視，你就需要多個(gè)工作流程?！?/p>

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

好吧，別抱太大希望。根據(jù)MediaKind的Tony Jones的說(shuō)法，“主要的問(wèn)題是，當(dāng)CMAF幾乎變得無(wú)處不在之前，它還是帶來(lái)了一種分發(fā)格式的挑戰(zhàn)。當(dāng)然最終其通用性會(huì)帶來(lái)真正的好處之前，似乎可能還需要幾年時(shí)間才能淘汰其他格式?！?/p>

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

實(shí)現(xiàn)的復(fù)雜性會(huì)有所不同

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

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

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

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

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

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

簡(jiǎn)單性比低延遲更重要

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

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

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

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

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

CMAF是下一個(gè)大事件

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

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

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

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

WAVE的三個(gè)焦點(diǎn)

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

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

CMAF還不適合所有人

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

Marcus Johansson是OSK Berlin的一名流媒體工程師，他說(shuō)：“我們還沒(méi)有在任何項(xiàng)目中真正實(shí)現(xiàn)CMAF，因?yàn)槲覀兡壳暗钠脚_(tái)已經(jīng)在我們需要支持的所有設(shè)備和瀏覽器上和HLS一起使用了。到目前為止，超低延遲的直播還不是必需的。因此，盡管我們已經(jīng)開(kāi)始接觸到一些相關(guān)咨詢(xún)，并在實(shí)驗(yàn)室中運(yùn)行低延遲的原型，但我們沒(méi)有通過(guò)DASH/HLS或者使用分塊流共享分布式資源，”

DaCast的首席運(yùn)營(yíng)官兼業(yè)務(wù)開(kāi)發(fā)和銷(xiāo)售副總裁Greg Ellis說(shuō)：“每個(gè)人都想要更低的延遲，而CMAF看起來(lái)是擁有真正可擴(kuò)展性的最佳選擇。但那些規(guī)模更大、增長(zhǎng)最快的客戶(hù)對(duì)其他具有更高優(yōu)先級(jí)的增強(qiáng)功能的需求，導(dǎo)致我們今年幾乎每個(gè)季度都推遲實(shí)施CMAF?！?/p>

因此我們沒(méi)有聽(tīng)到很多“不”，只是很多“尚未”。

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

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

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

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

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

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

在Bitmovin的“2019年視頻開(kāi)發(fā)者報(bào)告”中，有25%的參與者計(jì)劃實(shí)施CMAF

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