CMAF技术解码及实践

概述：

在当今如火如荼的直播产业中，运行着各种各样的流媒体封装及传输协议，比如广电行业应用最多的HLS、风靡互联网直播平台的RTMP、HTTP-FLV以及海外OTT行业应用广泛的MPEG-DASH。这些流媒体封装协议都有各自的利弊，比如RTMP、FLV这种流式传输媒体协议，能够满足实时直播场景低延时的要求，但是由于容器格式老旧，在一些新的编码协议扩展、加密方案支持上，无法跟新迭代满足需求。再比如HLS、MEPG-DASH这种文件切片式流媒体协议由于应用了MPEG-TS或MP4容器格式，在编码器扩展、多音轨支持、版权保护方面有着得天独厚的优势，但是由于切片式生成和传输的缺陷，导致端到端延迟高一直是被用户所诟病。面对这样的割裂的格局，一种全新的、兼容性更高，针对上述几个问题的通用容器格式和传输方案应运而生。

1.CMAF媒体框架介绍

CMAF，全称Common Media Application Format，是由Microsoft、Apple、MLBAM、Akamai等行业巨头向MPEG提出并在2017年被批准的一项国际标准。顾名思义，CMAF旨在解决媒体扩展性、传输低延迟、内容可缓存性等通用问题的综合性解决方案，整体上降低流媒体传输的成本以及提升用户体验。

首先先从媒体对象模型上了解下CMAF的组成：

图1.CMAF数据模型图

从图中模型组成结构可以看出，可以用CMAF Header、CMAF Segments、CMAF Chunks以及CMAF Tracks来呈现一个CMAF资源对象。接下来分别介绍下这几个结构。

CMAF Header：CMAF Header用于描述每个CMAF Track解析、解码和现实等相关的配置，通常是起始于一个'ftyp'类型的box，包含一个'moov'box，包含了整个set的box的序列号。

图2.包含一个IOSBMFF数据段的CMAF Fragment

CMAF Fragment：如图2中，每个Fragment通常由一个ISOBMFF段组成，可以独立解码和解密，当进行chunked传输时可以包装多个ISOBMFF段。

图3.CMAF track数据框架

CMAF Track：如图3中，每个track中包含存储在CMAF指定的容器中的编码的媒体样本，包括音频，视频和字幕， 由一个CMAF头片段和其后的包含媒体样本的CMAF切片组成。CMAF序列包含存储在CMAF指定的容器中的编码的媒体样本，包括音频，视频和字幕，源自ISO基本媒体文件格式（ISOBMFF）。

图4.CMAF Segment结构

CMAF Segement：如图4中，在一个CMAF序列中的一个或多个CMAF Fragment可以被打包成一个CMAF Segment，每个Segment可以使用独立的资源描述符进行引用和传输。为了更高效编码，通常每个音视频Fragment长度在2-6s，为了保证CMAF低延时的效果，CMAF的Segment的长度通常不会超过10-12s。

图5.CMAF Chunk数据结构图

CMAF Chunk：如图5所示，CMAF Chunk是在直播编码器中，在一个CMAF Segment没有完整产生的情况下可以被分成不同的块进行传输分发，用这种方法能够使每一个CMAF Fragment能够渐进式编码、传输以及播放器的解码。也能够满足广播和多播的传输和识别。

除了了解上述基础的数据结构外，CMAF的媒体模型中还定义了多track集合以及自适应码率的结构、为了支持多语种&多视频角度或编码器的选择集合和延迟绑定的数据结构、多CMAF序列进行同步编码、解码的基准时间数据模型等。

2.CMAF特性介绍

作为通用的媒体封装格式，CMAF的特性优势非常明显，对比常用的几个流媒体封装协议看：

表1.多协议特性对比

通过上面几种流媒体封装和传输协议对比来看，几乎所有维度cmaf都是完美PK对手。下面分别从扩展性、安全性、低延迟和多码率自适应维度简单分析下cmaf的特性。

图6.多通道选择集合

扩展性：如图6所示，首先cmaf可以使用track的维度来分离音频、视频、字幕等，也可以使用多track去描述不通的编码器或不同的码率，这种方式可以很好支持多音轨、多码率以及字幕的场景需求。

安全性：对于OTT视频行业来说，版权保护一直是标准化需求，CMAF继承了HLS和MPEG-DASH对通用DRM方案（CENC）的支持能力。比如CBC加密模式中能否支持Apple的FairPlay DRM,CTR加密模式下，支持谷歌的widevine以及微软的fairplay，基本满足了99.9%的硬件设备级别加密要求。

低延迟：CMAF把segment切成了更小的块单元进行传输，首先不需要等待segment完全生成的编码延迟，其次更快的请求响应能力能够提升播放器的响应速度，整体上保证了播放器能否在一个块产生的延迟里获取到最新的一个块，进行解码和播放，从而降低延迟。

图7.多track切换集合

多码率自适应：CMAF定义了可互操作的CMAF媒体配置文件。这些媒体配置文件制定了解码和所需的编码和编码规则，以及确保动态自适应流所需的无缝跟踪切换的需求，交换集可以在CMAF切片的边界处切换和凭借备选的CMAF TRACK,以不同的比特率和分辨率自适应地传输相同的流。

3.CMAF低延时特性详解

仔细分析上述的特性，其实很多特性在MPEG-DASH的标准中已经实现，CMAF对比DASH的优势主要集中在低延迟，接下来我们重点分析下低延时的实现原理：

图8.切片耗时、响应分析原理图

在传统的文件切片编码器中，延迟往往由几部分产生，比如为了保证快速响应，分发历史生成的片或者为了保证传输最新切片，hold住连接，等待最新的切片生成后再分发。

分析图中的case1，为了保证对播放器的快速响应，直接分发了历史分片3，由于切片的长度为8s，生成第一个分片就会累计8s延迟，再加上当前编码器中最新未生成的3s的缓存数据，那么本次请求的延迟就是11s左右。

分析图中的case2，为了降低延迟，hold住请求5s，然后分发最新的切片，那么延迟就是8s，虽然延迟对比case1略有下降，但是用户的Qoe并不好，在最新分片生成的期间内，虽然保证了延迟都是8s，但是所有的连接都会被hold住0-8s，用户首屏的体验会比较差。

那么在CMAF中，这种被hold和延迟大的问题都会被解决，首先能够保证在任何时候都可以立刻响应，其次，即使当前的分片还没有产生，也可以用chunk编码的方式把当前片已经编码后可解码的部分立刻发出去，那么对于图中的case来说，保证立刻响应，延迟也控制在3s。

对于这种大切片的情况，实时响应的要求下，能保证延迟控制在0-8s。在实际的应用场景中，我们可以把分片长度控制小点，比如4s一个片，那么整体的用户延时能控制在0-4s，首屏也能得到保证。

4.CMAF实践及效果展示

关于CMAF的应用，腾讯云直播产品已经完成了编码器部分的开发部署，配合直播cdn平台，我们整体的设计思路如图所示：

图9.CMAF媒体处理框架

复用云端原有的接流、转码处理的优势能力，增加CMAF Packager模块，用于处理CMAF的容器封装等媒体处理工作，包装成可以传输的http chunk推送给http server分发给终端播放器进行播放。以下是腾讯云中国香港的媒体处理中心切片生成的CMAF流配合腾讯云直播cdn分发的效果对比普通dash流效果图：

图10.CMAF和普通MPEG-DASH效果对比图

测试环境说明：

编码器位置：云直播中国香港集群。

推流：中国香港腾讯云cvm，ffmpeg文件推流。

切片服务配置：封装模块配置的切片为4s一个，3个分片为窗口大小。

测试地点：中国深圳。

测试播放器：dash.js

效果：整体效果看，CMAF比普通的MPEG-DASH流降低了15s左右的延迟。当然，测试效果和播放器的策略有一定相关性。

长连接复用优化：

在传统的dash或hls分发中，往往使用短连接来请求m3u8文件或ts、mp4分片，为了更好提高传输效率，我们建议使用HTTP1.1长连接特性，复用TCP连接，文件索引列表和切片请求分别运行在2个的TCP连接上，整体上可以提升传输效率也能够降低云端服务器的连接数负载，提升整体的服务性能。

后记

很多技术，从原理角度理解是比较简单明了的，但是真实地工程化应用到线上，保证海量、稳定可靠、低成本以及鲁棒性高的服务，又是另一门高深的学问。我们会持续优化迭代CMAF的性能，争取为用户带来更好的音视频流媒体服务体验。

参考文档

1.Common Media Application Format for Segmented Media-ISO/IEC JTC1/SC29/WG11 N16186.

2.https://github.com/Dash-Industry-Forum/dash.js/wiki/Low-Latency-streaming.

3.https://github.com/cannonbeach/ott-packager.

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