CMAF——是未来或仅仅是另一种格式？

本文为媒矿工厂编译的技术文章

原标题：The State of CMAF: The Holy Grail or Just Another Format?

原作者：Jan Ozer

原文链接：https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/The-State-of-CMAF-The-Holy-Grail-or-Just-Another-Format-135142.aspx

翻译整理：徐鋆

所谓流媒体的“珍宝”指的是可以被安全地传输到所有目标端点的一组文件。最可能获得此殊荣的候选人就是CMAF（Common Media Application Format）。虽然CMAF仍不能将“珍宝”传递至所有地方的客户，但它已经具有了互操作性的DNA，可以极大简化发布者和玩家之间的兼容性。

CMAF简介

CMAF是ISO/IEC 23000-19规定的分片媒体传输的标准。特别的，CMAF使用了基于ISO的媒体文件（ISOBMFF）容器和常见的加密方式（CENC）。其支持H.264，HEVC和其他编解码器，以及网络视频文本跟踪格式（WebVTT）和IMSC-1字幕。不像DASH和HLS，CMAF不是一种表现格式，它是一种容器格式，可以包括一组音视频文件和用于多种表示格式和DRM的清单文件。

CMAF试图解决的问题如下图。为了服务图右侧的所有终端，需要四种不同格式的文件：HLS、DASH、Smooth Streaming和HDS。

根据此图，需要四倍的时间来编码/封装，四倍的源端存储空间，并且降低了内容的可缓存性。有了CMAF，只需要一群分片mp4格式的音视频文件和轻量级的对四种自适应码率格式的清单文件。在理论上可以减少75%的编码和存储消耗，并且使缓存更加有效。

CMAF节省的部分被夸大了

对大部分用户来说，CMAF的节省被夸大了，因为有很多技术可以获得相同程度的节省。一个明显的例子是JIT打包，输入一组MP4文件，根据每个观众的需要被打包。这意味着一群MP4文件，而不是4倍，并且没有转码。使用JIT的公司将CMAF视为提供部分节省，而远远不是75%的编码和存储。

JIT并不是只需存储一组数据，而能产生多种格式的唯一方案。更清楚地说，相比于JIT，CMAF确实产生了存储和缓存节约，但是其程度取决于分发结构体系和打包是在源服务器还是边缘节点。

关于加密内容

使用DRM部署CMAF最重要的障碍可能与其中两种不兼容的加密模式有关。CMAF中有两种加密模式，分别是CBC（或CBCS）和CTR。苹果公司不想添加CTR支持，而谷歌和微软已经在DRM系统中添加了CBC支持。

但是，对于某些级别的DRM，加密模式需要硬件支持。老旧的设备没有CBC模式的支持，将不能支持硬件级DRM。同样的，虽然内容解密模型（CDM）已经被升级到支持CBC，设备也需要获得这样的升级，才能播放经此加密的内容。老旧的OTT设备或者是没有升级的移动设备可能存在此问题。软件级别的DRM可以被内置在app内。

很多人说CBCS支持将在12到18月内出现，但是总是有老设备的问题。只支持CTR的设备并不会消失，也不确定它们是否会被升级。我们在尝试支持老设备时必须要考虑这些问题。

不仅是硬件终端，浏览器版本也有问题。比如Edge和IE现在不能播放某些CBC加密的视频。微软将会升级Edge版本，但可能不会解决IE的问题。

最初，CMAF将仅是一种格式

虽然CMAF保证了对所有终端只有一组文件，但是很多初期的实施将会把CMAF附加在DASH或HLS上，来支持老设备。在一段时间内，人们将会把CMAF和HLS同时部署。也就是存在一段过渡期，而不会直接全面改变。

下图展示了CMAF的一种部署形态，其中CMAF在视频云平台里。视频云平台包括多种内容、一个动态的传输系统等。

在积极的角度说，把CMAF加入系统是简单的。但从分片的角度来看，CMAF可能在把事情变好之前会先将其变坏。

关于何时将CMAF添加入系统会有利这个问题，首先需要考虑CDN缓存数据的模型。最流行的数据，或者最常被检索的数据，被缓存的概率最高。所以交付4种格式会把与边缘缓存数据相关的开销增加4倍的这种说法并不正确。比如把Smooth Streaming传输给1%的观众，把HDS传输给1%的观众，把DASH传输给5%的观众，同时把HLS传输给93%的观众，那么缓存成本可能保持在1倍，因为只有HLS会被缓存。当然，还有其他开销或者未缓存数据有低的服务质量，但是存储消耗并不会翻4倍。

但是随着CMAF的流行，这种概念会变得对其有利。如下图所示，当CMAF的占有率达到84%时，CDN的成本能达到盈亏平衡。此时，关于其他格式的消耗将会增加，QoE将会下降，因为其数据未被缓存在边缘。

CMAF成为添加品并不是出人意料的，因为我们仍需要应对分片世界中的各种编解码器、各种传输格式和各种设备。并且如果需要支持很多不同的设备，还是需要多条工作流。

关于需要多长时间来继续发布多种格式这个问题，出版商们意见各不相同。但是明显的一点是，只要收入超过成本，就有必要继续支持传统设备。主要问题在于，当CMAF几乎变得无处不在之前，它还是带来了一种额外格式的挑战。当然最终其通用性会带来真正的好处，但淘汰其他格式还需要一些年。随着用户逐渐淘汰老旧设备，CMAF对CDN花费的节省才可能会显现出来。

CMAF实施的复杂性不同

无论多么令人满意或功能强大，大多数OTT运营商仍然不会积极使用新的格式，除非他们能够保护它、监控它、将它货币化，并让它在他们的所有目标设备上发挥作用，这不仅是针对当前内容，还包括老旧内容。上面已经讲述了DRM如何使单一格式的交付变得复杂，后面还有其他几个领域需要考虑。

第一，CMAF需要分离的音轨和视频轨。如果内容已经被存储在了复用的格式中，那么需要重新处理，从而满足CMAF的要求。大部分的HLS都将音轨内置了，所以如果要混合CMAF和HLS，音频是一个大问题。

第二是广告方面。许多AVOD服务不能控制广告插入。支持广告的出版商在等待CMAF对于广告的支持到位，之后他们才会部署CMAF。首先就是谷歌广告管理对CMAF的支持，这将在年底完成，这个支持至关重要，特别是在拼接方面，目前音频方面对解码器的要求最具有挑战性。同时，还需要保证所有的广告满足CMAF规格。

不仅仅是广告方面，分析和监控渠道有可能也需要更新。不过大部分包装程序已经支持CMAF，所以只需要重新配置即可，并不困难。

当然，添加的功能越多，系统也会越复杂。即使没有CMAF，DRM管理和广告插入本身就是复杂的。CMAF本身是否添加了复杂性还没有定论。

简单比低延迟重要

低延迟CMAF已经收录了一个可用的技术，把延迟降低到了1-3秒。但一些目前正在实施CMAF的OTT供应商表示不要将CMAF等同于低延迟。大多数OTT供应商采用CMAF的迫切动机是简单，而不是低延迟。如下图所示，有多种方式实现闭合字幕、缩略预览、广告插入等，CMAF提供了一种良好的方式将这些整合。

对OTT供应商来说，另一个部署CMAF的巨大动力是CMAF将其从碎片化中解脱出来。他们此前为跨平台的DRM支持需要生成4个不同的包，所以迁移到CMAF/CENC是具有吸引力的，因为这样只需要更少的编码，封装和存储花费。

虽然很少有人提到，但是CMAF关键的潜在好处是简单。很多人现在提供六种ABR格式和DRM的不同组合，这使得测试和质量控制非常复杂。如果可以向所有设备发送同一种格式，CMAF将在降低复杂性和测试要求方面带来巨大的成本节约。

CMAF是下一个大事件

试想如果每个电视制造商需要使用全球所有频道来测试其新电视机，而每个频道都要使用所有制造商的每个新电视来测试，那电视行业将会如何？不兼容性将会蔓延，市场发展将会停滞。这和目前流媒体领域发生的事情在本质上是一致的，并且给OTT发行商带来了巨大的兼容性负担。在这种负担下，OTT行业还能如此成功是一件令人惊讶的事。

本质上，兼容性问题就是WAVE的核心所在。WAVE是一个由CTA发起的项目，致力于改善互联网传播的商业视频在消费电子设备上的处理方式，让内容创作者更容易将视频分发到这些设备上。

WAVE计划通过为内容、设备和API创建规范和配套测试来提高互操作性。CMAF是所有规范的核心。在IBC2019，WAVE发起了CMAF行业论坛。该论坛是WAVE的一个分支，强调CMAF在WAVE规范和配套测试中的作用，并且鼓励人们采用CMAF。

CMAF是由苹果和微软开发的，多种ABR格式(包括HLS、DASH和HDS)的统一容器。WAVE项目的重点是使用CMAF来创建规范和配套测试，以确保内容/设备的互操作性。在两年内，内容发布者将不会选择没有通过配套测试的编码器/打包器，并且没有播放器、硬件或软件会在没有经过测试的情况下发布。新特性、api和编解码器将以一种标准化的方式添加，从而鼓励真正的创新，而不仅仅是让内容在目标设备上能够播放的繁琐工作。

购买CMAF，不仅是购买一种新的容器格式，而且还是购买一个具有远见和影响力的行业组织，可以将简单的规范转换为互操作性。这在短期内不会发生，但没有其他标准或规范能接近于实现这种愿景。

但是CMAF目前还并不适合所有人。很多公司也因为一些原因而打算暂缓CMAF的部署，但都只是暂缓，而不是不进行。

同时，大多数的技术公司要么已经实施了CMAF，要么正在全速前进。而且CMAF也获得了大部分播放器厂商的全面支持。

基本上在每一个地方，CMAF要么在使用中，要么在开发中，要么在考虑中。现在开始使用CMAF还为时不晚，当然也不算早。