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

簡單解釋一下CMAF

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在必讀的白皮書《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é)為以下幾個方面：更嚴(yán)格的控制配置文件的生成和編碼，增加ISOBMFF傳輸器的功能，并向HLS和DASH manifest生成器添加附加規(guī)則，以生成與CMAF兼容的manifest。”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

簡單性比低延遲更重要

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

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

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

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

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

CMAF是下一個大事件

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

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

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

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

WAVE的三個焦點(diǎn)

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

認(rèn)可CMAF，不僅僅只是認(rèn)可它是一種新的容器格式，而是認(rèn)可一個具有遠(yuǎn)見和影響力的行業(yè)組織，可以將簡單的規(guī)范轉(zhuǎn)換為互操作性。這在短期內(nèi)不會發(fā)生，但正如一位publisher所說，“再給AV1幾年時間，我們也許就能開始在這件事上做文章了。”目前還沒有其他標(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詢問有關(guān)CMAF的問題時，他說：“我們當(dāng)下不使用CMAF，只使用HLS+TS。我們的客戶依賴我們根據(jù)他們需要的功能來決定他們使用的格式，我們選擇從HLS+TS開始，因?yàn)樗鼡碛凶顝V泛的單一格式覆蓋范圍，包括較老的iOS設(shè)備。由于iOS CMAF的普及和DRM的支持，我們可能會在不久的將來轉(zhuǎn)向到CMAF交付，。”

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

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

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

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

此外，和我交談過的大多數(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ì)量控制過程中增加了CMAF合規(guī)性檢查，以確保符合規(guī)范。

CMAF得到了大多數(shù)播放器廠商的全面支持，包括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。

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

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

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

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

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