通用媒体客户端数据 CMCD

来源：Global Video Tech Meetup: Portland 主讲人：Will law 翻译整理：张一炜 本次演讲介绍了目前 CDN 日志所包含的信息有限的问题，引出了由 CTA 提出的 CMCD(Common Media Client Data)规范，并对其中的主要内容进行了详细的介绍，同时也给出了 CMCD 规范的数据如何帮助优化 CDN 传输以提高客户端的 QoE 指标。

目录

• CMCD 规范的提出
• CMCD 的具体内容
• CMCD 规范的自定义
• CMCD 数据应用方式

CMCD 规范的提出

CMCD(Common Media Client Data) 是由 CTA WAVE(Web Application Video Ecosystem) 创立的项目，并得到了 Apple、Hulu、Dolby 等组织的支持。并在 2020 年 9 月发布。

CMCD 规范的提出，主要是为了解决 CDN 日志的一些缺陷。CDN 的日志信息格式如下图所示。

原始的 CDN 日志信息内容

一行 CDN 的日志信息中虽然包括了请求的 IP 地址与请求的视频段编号。但由于日志中的 IP 地址可能仅仅是网关的地址，仅通过这一条日志也难以判断实际的用户。CDN 的日志也仅能反应点击量信息，无法得到有关 QoE 维度的信息。

另外 CDN 的日志无法获得详细的视频段信息，包括该媒体数据实际的长度，是 HLS 还是 DASH 格式，对象的码率、直播或者点播、播放器的 buffer 情况以及当前的播放状态等都无法获取。

从播放端的角度来看，同样希望 CDN 能够通过日志信息了解到播放器的情况，包括了当前的网络状况、当前播放器的 QoE 指标（Convivia,NPAW,MUX等）、当前 CDN 在发送缓慢的数据是初始化数据、音频数据还是视频数据。并且，虽然从 CDN 的日志可以获取点击量的信息，但无法知道点击量对应的实际视频内容的个数。

所以，在播放器和 CDN 服务器之间交换一些互相有益的信息是很有必要的。事实上，在播放器请求播放列表和媒体数据段的时候就已经实现了每隔几秒交换一定的信息。可以在其中添加一些其他的数据信息来实现 CDN 服务器和播放器之间的信息交换。

播放器对 CDN 服务器的请求

CMCD 的具体内容

CMCD 规范为了解决上述问题，定义了一套结构化的键值对集合，以此来传递对 CDN 服务器和播放器共同有益的信息。在播放器与 CDN 服务器之间的交换方式包括了一系列的自定义 header、查询参数以及 json 对象三种方式。该规范被称为通用的原因也正是在于这样的数据结构可以支持所有的播放器与 CDN 服务器。

具体来说，CMCD 的键值对主要包括了以下几个，括号中的内容为对应的 key 标识，后面则是对该键值对的简单介绍。

• 编码码率（br）:音频和视频数据所需要的码率大小
• 缓冲区大小（bl）:和对应的媒体数据端一起被请求。
• 缓冲区饥饿（bs）:在先前请求和当前请求之间某一时刻缓冲区处于饥饿状态。
• 内容编号（cid）:对当前内容的唯一字符串标识符。
• 对象持续时间（d）:当前请求对象的回放时间，以毫秒为单位。
• 最后期限(dl):请求的第一个对象的最长有效时间，以避免缓冲区的落后和播放时出现问题。
• 吞吐量测量值（mtp）:客户端和服务器之间的吞吐量大小，由客户端测量得到。
• 下一请求对象（nor）:下一请求对象的相对路径。
• 下一请求范围（nrr）:如果下一请求只是对象的一部分数据，那么该字符串下一请求的字节范围。
• 对象类型（ot）:当前请求的媒体数据对象的类型。
• 回放速度（pr）:描述了当前播放的速度。只在非正常速度播放时传输。
• 请求最大吞吐量（rtp）:客户端的理想最大吞吐量。
• 流媒体格式（sf）:当前请求的流媒体格式，Dash、HLS等。
• 会话 id(sid):识别当前播放会话的 GUID.
• 流媒体类型（st）:主要用于判断是直播还是点播场景。
• 起始点（su）:标识播放起始需要的对象，在 buffer 为空时寻找或是恢复。
• 最大码率（sf）:当前播放列表中客户端允许的最大码率。由此对编码器和视频大小进行限制。
• CMCD 版本（v）:用于解释当前版本规范的CMCD版本号。

为了确保传输内容的 CMCD 结构化数据的隐私性，推荐使用 HTTPS 来传输相应的数据。

CMCD 规范的自定义

CMCD 中还包括一些基本的规则，即上述的所有 key 都是可选的，客户端仅仅发送一个 sid 的情况也是允许的。并且，也允许添加自定义的键值对，但对于自定义的情况，需要携带一个连字符前缀以避免和未来版本的 CMCD 的命名空间产生冲突。

如果在 header 中添加自定义的键值对，则这些自定义的键必须基于其期望的级别和可变性分配个4个特定的 header 名称(CMCD-Request、CMCD-Object、CMCD-Status、CMCD-Session)。

下面给出一个 CMCD 规范下的结构化数据，其中包括了自定义 header、查询参数以及 json 对象三种方式。

CMCD 结构化数据

CMCD 数据应用方式

借助这些键值对信息，CDN 服务器与客户端可以高效的交换一些互相有益的信息，以使得 CDN 服务器对客户端的状态和需求有更好的了解。主要包括以下一些应用。

• 简化非单调增长的段编号下预取内容，利用下一请求对象（nor）键值对，可以根据相对路径，更方便的告知 CDN 服务器下一请求的媒体数据对象，而不需要每次都根据绝对路径进行请求。
• 在符合要求的移动网络上对媒体数据段进行优先级排序。客户端可以标记出起始点（su）字段，来发出一个高优先级的请求。以及网络可以读取其中的 header 信息，判断出服务类型来为其中的流量区分出不同的传输优先级。
• 帮助 CDN 服务器更好的缓存重要内容。CDN 服务器不可能缓存所有的媒体数据段。因此 CDN 服务器更需要缓存一些重要的数据段来确保客户端较好的观看体验。可以利用 su 键来设定优先需要缓存的内容以提高客户端的 QoE 指标。
• 优化客户端 CDN 服务器选择。目前的 CDN 服务器选择基本都是基于速度测试，然而单纯的速度测试无法精确反应当前播放器下不同 CDN 服务器的真实性能。可以添加 RPM (Real Player Monitoring) 键值对来解决。视频内容分发商也可以利用这些数据来进行更精准的 CDN 选择决策。

附上演讲视频：

http://mpvideo.qpic.cn/0bc3aeabeaaajmae26gvnrqvaaodciaqaeqa.f10002.mp4?dis_k=53e450e41ba284cba25e055da915f746&dis_t=1645149885&vid=wxv_2210922384063332355&format_id=10002&support_redirect=0&mmversion=false