所謂流媒體傳輸的”圣杯”指的是一組文件被安全地傳輸到所有目標端點。最有可能幫助實現這一目標的“候選”是通用媒體應用程序格式（CMAF）。盡管目前CMAF還不能將”圣杯”交付給所有客戶，但它所具備的互操作性的DNA，將極大地簡化發布者（publishers）和播放器（players）之間的兼容性。最終，它可能傳遞出”圣杯”。

簡單解釋一下CMAF

CMAF是ISO/IEC23000-19規定的分段媒體傳送的標準。具體來說，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的內容將在稍后做進一步介紹）。為了服務于圖中右側所示的所有終端，需要提供四種不同格式的文件：HLS、DASH、Smooth Streaming和 HTTP DynamicStreaming （HDS）。

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

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

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

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

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

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

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

內容保護方面呢？

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

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

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

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

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

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

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

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

Brightcove視頻云平臺

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

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

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

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

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

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

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

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

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

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

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

實現的復雜性會有所不同

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

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

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

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

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

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

簡單性比低延遲更重要

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

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

WarnerMedia希望通過CMAF簡化內容交付

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

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

CMAF是下一個大事件

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

本質上，這個兼容性問題是WAVE設計要解決的核心所在。從技術上講，WAVE是一個由消費者技術協會（CTA）發起的項目。CTA的網站稱，該項目的目標是“改善互聯網傳輸的商業視頻在消費者電子設備上的處理方式，并方便內容創作者更便捷地將視頻分發到這些設備上。”

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

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

WAVE的三個焦點

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

認可CMAF，不僅僅只是認可它是一種新的容器格式，而是認可一個具有遠見和影響力的行業組織，可以將簡單的規范轉換為互操作性。這在短期內不會發生，但正如一位publisher所說，“再給AV1幾年時間，我們也許就能開始在這件事上做文章了。”目前還沒有其他標準或規范能實現這種愿景。

CMAF還不適合所有人

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

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

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

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

大多數行業正在加速發展

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

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

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

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

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

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

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