CMAF现状：是终极标准或仅仅是另一种格式?

Photo by Kaboompics .com from Pexels

所谓流媒体传输的”圣杯”指的是一组文件被安全地传输到所有目标端点。最有可能帮助实现这一目标的“候选”是通用媒体应用程序格式(CMAF)。尽管目前CMAF还不能将”圣杯”交付给所有客户，但它所具备的互操作性的DNA，将极大地简化发布者（publishers）和播放器（players）之间的兼容性。最终，它可能传递出”圣杯”。

文 / Jan Ozer

译 / 元宝

审校 / 赵军

原文

http://www.streamingmediaglobal.com/Articles/ReadArticle.aspx?ArticleID=135885&PageNum=1

简单解释一下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还为时不晚，但肯定也不算早。