如何通过分块编码和分块传输CMAF

刚落幕的LiveVideoStackCon 2018音视频技术大会上，Akamai媒体业务群首席架构师William Law通过主题演讲介绍了如何通过分块编码和分块传输CMAF，为观众提供极低延迟的视频直播服务。本文由Akamai整理，并授权LiveVideoStack发布。

对于当今年轻人，电视早已没什么吸引力，大家更喜欢通过网络追剧、看比赛，甚至看各种直播内容。那么延迟到底会有多重要？为什么要强调低延迟？

假设你和邻居都在自己家看足球赛，邻居看电视直播，你看网络直播。邻居那边已经在为进球欢呼，你这边因为延迟，球员才准备起脚射门……你说低延迟重不重要。

面对数量激增的用户和复杂的网络环境，如何为观众提供更流畅的播放体验，并且对直播类节目提供低延迟快速高效的内容交付，已成为很多视频平台最关心，并且投入最多资源进行改善的领域之一。

那么「分块编码」和「分块传输」的「CMAF」到底是什么？

CMAF，一种全新的「容器」格式

随着HTTP自适应流媒体（HAS）技术的发展，视频直播观众对OTT质量和延迟提出了更高要求，甚至堪比传统广播电视节目。然而业内通常认为，HAS交付内容不可避免会遇到端到端延迟，甚至可能长达视频片段时长的数倍，自然无法比拟广播电视效果。但这种观点已经站不住脚了，现在已经有HAS解决方案能将这种端到端延迟降低到远低于一个片段时长的程度，甚至可以让整体延迟与片段时长完全无关，这个解决方案就是超低延迟CMAF（ULL-CMAF）。

CMFA（Common Media Application Format，通用媒体应用程序格式）由标准化组织MPEG在2017年正式颁布，这种格式定义了一种碎片化的MP4容器，其中可以封装视频、音频及文本数据。该格式最大的特点在于，能高效地让HLS播放列表同时引用多个媒体片段和DASH清单，同时还在DASH ATSC3广播配置文件的继承方面实现了很多优势，有助于进一步降低延迟。

但简单来说，只使用CMAF片段还不足以降低延迟，CMAF容器还必须与编码器、CDN以及客户端行为完全匹配，在整个系统范围内实现低延迟。

图1：CMAF的对象命名

分块编码，化整为零提效率

降低延迟的第一步是分块编码。按照MPEG CMAF标准，CMAF轨道由多个对象组成，如图1所示。「块」是最小的可引用单位，其中至少包含一个moof 和一个mdat原子（Atom）。一个或多个块组合在一起形成一个片段，而一个或多个片段还可进一步组合成一个片段。

标准的CMAF媒体片段将使用一个moof 和一个mdat 原子进行编码，如图2所示。其中mdat还包含一个IDR（Instantaneous Decoder Refresh，瞬时解码器刷新）帧，每个片段开头都会有。

图2：CMAF段的分块编码

虽然每个「分块编码」片段会包含一系列「块」，即多个moof/mdat 元（Tuple）组成的序列，如图2所示，但只有第一个元具备IDR帧。将片段分解为更短的碎片，这样做好处在于编码器能在编码完成后立即输出每个块。块数量相同的情况下，这种「提前」输出的做法可显著降低整体延迟。

分块传输，合零为整降延迟

接下来需要考虑如何实现分块传输。

图3：HAS媒体分发系统

编码器会使用HTTP 1.1分块传输编码机制，将编码后的CMAF块推送至源位置。例如，对于一个产生4s 30fps片段的编码器，将每4秒发出一个HTTP POST请求（每个请求对应一个片段），在接下来的4秒里，共有120个块（每个块时长为33毫秒）构成一个完整的片段，并发送至源位置。但编码器并不会对每个单独的块发出一个POST请求。

接下来，这个块会通过拉取的方式到达播放器。播放器读取清单或播放列表，了解内容描述信息，随后计算希望开始播放的位置起点，并向对应片段发出请求。清单中必须列出片段数据的早期可用性。对于MPEG DASH，这是通过MPD@availabilityTimeOffset参数实现的。

图4：视频直播过程中，播放器的启动选项

我们可以用图4所示过程为例，演示播放器起始播放算法对整体延迟的影响。这是一个会产生2秒片段的直播编码器。图中可见，系统正处于产生片段5的过程中。对于不分块解决方案，为了尽可能降低延迟，必须从上一个完整可用片段（片段4）开始播放，这会导致整体延迟增加3秒。但如果使用每500毫秒（仅供示例，实际中分块时长远低于500毫秒）一个片段进行分块编码，播放器就可从包含IDR的上一个块（块5a）开始播放，此时延迟可降低至1秒。

此外，还有两种方法可以进一步降低延迟。首先，播放器可以下载块5a和块5，但在开始播放前就从块5a向前解码块5b，这样可将延迟降低至500毫秒以内。第二种方法，播放器可将播放过程延迟1秒，随后在块6a生成后立即发出请求，这样也可以降延迟降低到500毫秒以内。

ULL-CMAF前提要求总结

总的来说，只有在全部满足下列要求的情况下，才能通过ULL-CMAF获得稳定的低延迟交付：

CMAF片段中的内容是分块编码的；

编码器调整DASH清单/HLS播放列表，以适应并标注自己使用了分块编码的方式，并借此告知数据的早期可用性；

编码器使用HTTP 1.1分块编码传输机制将内容推送至源分发位置；

CDN在分发链上的每个环节，都使用HTTP分块编码传输机制传播内容，并最终到达客户端；

而客户端也需要全部满足下列要求：

对片段请求进行精确计时，并在一个片段的有效时长内请求所需片段；

在收到比特流后立即解码，而不要等待片段结束。浏览器中使用的HTML5播放器必须使用Fetch而非XHR API，因为Fetch可以在数据下载完成前立即读取响应的正文内容；

具有估算吞吐量的方案，因为此时无法使用标准的Segment-timing技术；

缓冲区和自适应逻辑必须能应对非常低的缓冲；

由于吞吐量波动，能够在滞后于现场的情况下立即「赶超」。

所以说了半天，这种技术的效果到底如何？亲自体验一下吧。请使用Google Chrome浏览器（其他浏览器可能无法支持）访问：

http://mediapm.edgesuite.net/will/dash/lowlatency/low-latency-public-example.html

该演示使用由开源FFmpeg生成的直播流，发布至Akamai Media Services liveOrigin™，并通过Akamai Media Delivery网络交付，在客户端使用开源播放器dash.js播放。视频流为AVC 720p编码，码率2Mbps，片段时长6秒，每1帧的块时长29.97fps，availabilityTimeOffset设置为5.967秒，延迟目标设置为2.8秒，视频流在美国波士顿进行编码。