CMCD 处理实时真实数据

来源：ACM Mile-High Video 主讲人：Will Law, Sean McCarthy 内容整理：陈梓煜 本文介绍了通用媒体客户端数据（CMCD）用于处理实时真实世界数据的重要性，通用媒体客户端数据是连接用户播放器和内容分发的桥梁。本文介绍了 CMCD 的概念及其对于重要意义，介绍了 CMCD 数据的使用及实现方法，Sean McCarthy给出了实现 CMCD 过程中观察的问题及解决方法。Will Law 最后分享了从 CMCD 数据分析出的有趣结果。

目录

• CMCD 介绍
• CMCD 的重要性
• CMCD 实现方法
• CMCD 测试及分析
• CMCD 的应用

CMCD 介绍

CMCD（Common Media Client Data，通用媒体客户端数据）是连接用户播放器和内容分发的桥梁。CDN 每秒钟可以看见上百万个二进制信息的传递，在用户端，用户看见的是一个回放窗口里面存有最近几分钟的缓存数据可用于回放，我们想将这两种场景融合在一起，这是 CMCD 的关键点。CMCD 诞生于 Mile-High Video，我们在两年前的 Mile-High Video 会议上提议在用户请求中加入会话 ID，Dolby David 建议我们投入更多的精力将其变成一种标准。因此我们在会议结束后建立了一种原始的简单的标准，我们定义了一组结构化的键值对，将对双方都有益的媒体相关的信息从播放器传递到 CDN，通过以下三种形式：1）一组常规的头（A set of custom headers)。2）一个索引自变量(A query arg)。3）一个 JSON 对象。之所以称为常规是因为同样的数据结构可以被所有的播放器和所有的 CSDN 使用。

CMCD 介绍

被传输的数据主要有以下几种：

• 会话ID：将回放窗口中的所有媒体对象连接在一起
• 缓存长度：关系到播放器的状态
• 比特率：关系到播放器的状态
• 媒体对象延续时间：关系到CDN的表现
• 缓存饥饿状态标志符：计算缓存事件的数量
• 估计的网络流通量：关系到播放器的状态
• 数据流格式：HLS/DASH的统计数字 下一个对象：可以让终端提前捕获变化

被传输的数据类型

CMCD 的重要性

我们一直以来关注如何利用 CMC 数据产生 CMCD 数据。我们非常高兴能最终能在播放器端进行实现，理解我们应该在何处用何种方式使用这些数据。

我们有三个最常见的需要用到 CMCD 数据的场景，包括了：可实时观察性，会话窗口报告和 CDN 决策。Akamai 在会话分析和播放器 debug 方面建立了非常好的工具，因此我们将工作重心转移到服务于实时问题捕捉的聚合监控（aggregate monitoring）方面。也就是说我们现在专注于探索如何在实时可操控的监控内使用这些数据。

为什么要实现 CMCD

CMCD 实现方法

作为实现的一部分，我们将 CMCD 融合到我们的 Avia 网页播放器框架中，该框架建立在 HLS.js 和 Shaka 的基础上。Avia 播放器被应用在非常多的设备上。考虑该实现的本身，通过索引分享数据是公平且直接的，尽管修改最终输出的会话请求是非常低水平的实现方式，被获取的信息需要能够组织分散在不同模块下的数据，将这些数据聚合并传输给播放器的请求引擎。因此我们需要更好地理解播放器的架构。

播放器端实现

CDN 端的实现相对简单，主要包含三个部分：1）配置：实现的功能是将 CMCD 数据从缓存键中剔除，将 CMCD 数据从最初的屏蔽请求中剔除。2）满足实时记录：索引线索更容易被记录，同时要能够感知字节尺寸的限制，如果使用了原始的屏蔽 CDN 数据，需要去除 CMCD 数据参数。3）解析索引字串：字段排序可能会导致复杂化，并不是所有的字段都被呈现，最大的挑战是在不同的尺度范围下保持良好的实时性能。

CDN实现

CMCD 测试及分析

我们将我们的 Avia 播放器嵌入到网页中，然后分享到我们的网络中去在四个不同的 CDN 上产生网络交通流。我们利用机会制造了不同的分发条件。在聚合实时可操作监控这一目的下，我们从测试数据中获取了一些经验。

状态码让数据变得混淆。为了解决这一问题，我们不再在单独的单位下分析 CMCD 的表现，我们监控服务器的 TTLB、4xx 计数、5xx 计数、缓存点击率和 CMCD 场。我们将通过弹出的方式将其分解，或者用 client ASN 或者 client geo 来分解，然后我们在其中加入请求计算器来提高数据的优先级。

状态码导致数据混淆

使用缓存饥饿状态作为重缓存的节点。我们想使用缓存饥饿计数器作为整体重缓存的指示符。但是由于数据和每个请求的关联方式，我们过滤 5xx 状态码时没有查看到任何重缓存，为了对此缺陷进行补偿，我们决定不在我们的缓存饥饿面板上使用状态码过滤器。

缓存饥饿状态作为节点

如何解释缓存长度。这个问题引发了团队内的激烈讨论，因为目标缓存长度因设备而存在差异。我们发现当我们把缓存事件根据设备进行分类，画出来缓存长度和时间的关系，可以得到有意思的结果。有些设备缓存了十秒钟的数据，而另外一些设备可能保存了三十秒的缓存数据。不幸的是，设备的 ID 被从 CMCD 数据中移除了，而收集用户的终端类型数据非常困难。因此我们认为选择最大的缓存长度是一个好的选择。

如何翻译缓存长度

另外一个有趣的发现是当我们停止了数据流，我们的解码器给出了结束标识。两个不同的被嵌入的的播放器分析模块显示，伴随着数据流的停止，出了重缓存的峰值，但是并没有任何缓存饥饿事件出现在 CMCD 数据中。这种假阳性事件引入了非常多的噪声，是容易造成影响的事件。

数据流末端假阳性

CMCD 的应用

我们搭建了一个特殊的日志处理软件，名为 GhoLo，来翻译和展示 CMCD 数据。接下来我们将展示我们能从 GhoLo 中获取的数据。

GhoLo Dashboard

其中一个有意义的数据是缓存特征，缓存特征记录了单个播放器的 CMCD 缓存长度随着时间的改变。当我们把对 CMCD 缓存长度采样间隔设置为 6s 时，缓存长度显示出稳定着状态，但是当我们进一步采样更小的间隔时，我们发现缓存长度随着时间发生锯齿状的波动。

缓存特征

当我们使用 HLs.js 展现每次循环的细节时，我们发现了锯齿状曲线的原因。当播放器载入一段 6s 的片段时，该片段在 600ms 内被传递，在加载下一个片段时等待一个片段的时延，这导致每经过 6600ms 我们接受 6000ms 的新数据，因此我们的缓存长度下降了 600ms。这种下降一直持续到缓存长度低于阈值，缓存长度会被调整到原始的值。

HLs.js缓存循环细节

我们统计内容分发的 Last mile 流通量，并根据国家进行划分。结果显示不同国家之间的 Last Mile 流通量区别非常大。

Last Mile流通量可视化

CMCD 可以提示我们播放器转换的频率，通常当我们的数据流通量比较平稳时，较多的转换情况意味着低质量的 abr，当我们的流通量不平稳意味着网络连接不稳定时，较多的转换情况意味着高质量的 abr 因为它在快速适应网络的变化情况。

单设备比特率变化次数

附上演讲视频：

http://mpvideo.qpic.cn/0bc3jaaayaaav4abi4mdzbrfasgdbreaadaa.f10003.mp4?dis_k=dd250ef685aedb1dab4cdd0a3d5ae870&dis_t=1653461295&vid=wxv_2401935093658648577&format_id=10003&support_redirect=0&mmversion=false