利用 HLS Content Steering 传输可靠的流媒体

♪ ♪

Zheng Naiwei: 大家好 欢迎来到 WWDC 我叫 Zheng Naiwei 来自 Apple 的 AVFoundation 团队 在本次演讲中 我们将讨论如何通过添加到 HLS Content Steering 中的新功能 来提高流媒体传输的可靠性

我们今天将介绍三个主题 如果开发者还没有听说过 Content Steering 请不要担心 这是一项 HLS 技术 可以动态引导流媒体流量 以提高流媒体服务质量 我会进行一个简短的回顾 以帮助开发者上手

然后 我将介绍 新的 Pathway 克隆功能 它可以带来 超越极限的动态控制能力 以进一步提高流媒体服务的可靠性

最后 我将使用具体的例子 来指导开发者 话不多说 开始吧

在我们没有推出 Content Steering 的时候 HLS 规范中 没有对错误回退的变体选择 进行标准化定义 在选择下一个回退变体时 不同的客户端会有 不同的实现方式 但是一种典型的方法是 在多变量播放列表中 遵循变量顺序 如果流媒体提供商想要 指定一组回退 CDN 那么他们就需要列出 每个CDN中的每一个变体 并在多变体播放列表中正确地排列 这样 如果客户端播放器 第一个变体遇到故障 它可以在播放列表中 移动到下一个变体 故障变体将在做选择时受到惩罚 在这种情况下 我们看到客户端 播放器在 CDN1 的 6 Mbps 变体上有问题 因此按照多变体播放列表中的顺序 移动到下一个 CDN1 的 3 Mbps 变体 如果很不幸 CDN1 的 3 Mbps 变体也坏了 客户端播放器将不再保留 CDN1 的变体 而是转向 CDN2 的 6 Mbps 变体 它可以断断续续地执行此操作 直到没有要回退的变体为止 但是 即使播放列表的 创作服务器可以控制 回退变体的顺序 这种控制只发生在 客户端请求多变体播放列表时 一旦播放列表发出 就无法更改回退顺序 这就是 Content Steering 进入画面的地方 借助 Content Steering 流媒体提供商 现在可以将变体分组到 具有不同 CDN host 的路径中

错误回退行为现已针对 Content Steering 进行了标准化 通路按偏好排序 在此示例中 顶部的 CDN1 通路 是首选 其次是 CDN2 和 CDN3 流媒体提供商还托管 Steering Server 为每个客户端播放器 生成 Steering Manifest Steering Manifest 定义了 路径优先级的规则 所以 播放器可以遵守规则 在变体流之间进行选择和回退 例如 流媒体提供商正尝试 将一些流量从 CDN1 转移到 CND2 它将生成带有新路径 优先级规则的 Steering Manifest 当 CDN1 的客户端播放器 请求更新 Steering Manifest 时 Steering Server 可以将准备好的带有 规则更改的 Steering Manifest 发送给客户端 客户端将解析并查看 新的路径优先级规则 并将其应用于其播放会话 在这种情况下 规则更改 切换了 CDN1 和 CDN2 通路之间的首选项顺序 因此客户端播放器 将立即从 CDN2 切换播放 然后 如果发生故障 客户端将首先在当前路径中 耗尽回退变体 并根据其当前路径优先级 回退到最优先的路径 在这种情况下 如果 CDN2 中的所有变体都出错了 客户端播放器可以开始 从 CDN1 的变体中进行选择 这是下一个首选途径 当我们将 Content Steering 应用到全球范围时 它可以解决更大的区域 负载均衡问题 假设我们的流媒体服务提供商 在世界各地运营 具有两个主要的 CDN 提供商 要将这些 CDN 分配给 全球客户端播放器 Steering Server 准备了 两个不同的 Steering Manifest 一个倾向于 CDN1 另一个倾向于 CDN2 然后它根据客户端播放器的区域 分发这些 Steering Manifest 以便北美和南美使用 CDN1 世界其他地区使用 CDN2 在世界地图的顶部 我们显示了一个水平堆叠的条形图 表示 CDN1 和 CDN2 之间的流量分布 截至目前 这两个 CDN 都为全球一半的流量提供服务 但是 随着时间的推移 流媒体服务提供商观察到 由于全球日光偏移 CDN2 的流量显著增加 与此同时 流向 CDN1 的流量也在减少

因此 流媒体提供商决定 引导欧洲地区使用 CDN1 它通过准备一个更倾向于 CDN1 的 Steering Manifest 来实现这一点 并将其发送给欧洲地区的客户 现在 该区域中的这些客户端播放器 将流量引导到 CDN1 把 CDN2 卸载 全球流量变得更加平衡 现在让我们看一下 具有内容控制支持的 HLS 多变量播放列表 首先 我们看到 EXT-X-CONTENT-STEERING 标签 这表示此多变量播放列表 使用 Content Steering 然后我们有 SERVER-URI 属性 指定客户端应从何处请求 Steering Manifest 更新

然后 下一个 PATHWAY-ID 属性 指定启动时播放 要选择的初始路径 然后我们可以看到每个变体流 都被赋予了一个 PATHWAY-ID 属性 将它们分组到通路中 每个通路应具有相同的变体流集 唯一的区别是它们的 URI 和媒体组名称 这个例子中有两个通路 即 CDN1 和 CDN2 两者都包含两个变体流 一个 6 Mbps 高分辨率视频 和一个 3 Mbps 低分辨率视频 唯一的区别是它们的 URI 主机名 每个路径还有两个不同的音频组 它们具有不同的 URI 主机名 下面是一个示例 Steering Manifest 它是一个 JSON 文档 PATHWAY-PRIORITY 字段是按 首选项顺序排列的通路 ID 列表 因此 在这种情况下 接收客户端 播放器将首选 CDN1 而不是 CDN2 这是 Steering Server 提供给欧洲客户的 Steering Manifest 让他们选择 CDN1 通过更改 Steering Manifest 的 PATHWAY-PRIORITY 字段 一个 Steering Server 可以控制 每个客户端的转向策略 这就是 Content Steering 的快速概述 如果您想要更深入的了解 随时查看我的 WWDC21 演讲 通过 HLS Content Steering 提高全球流媒体可用性 但是 我们提供支持 更具可扩展性和更可靠的 流媒体服务的旅程并不止于此 如今 公司可以访问 更多通用的云基础架构 和工具来完成过去无法想象的事情 我们必须赶上技术的飞跃 假设我们的流媒体服务提供商 今年已经变得更大 他们正在尝试一种 新方法来满足不断增长的用户群的 动态流量需求 他们通过实时动态 生成 CDN 服务器队列 来减轻时间流量压力 例如 它可以生成新的 CDN3 舰队 并希望将其宣传给现有的客户 但是 挑战是当现有客户要求时 动态生成的 CDN 信息 并不包含在多变量播放列表中 因为它根本不存在 那么 我们可以做些什么来告诉客户 新的 CDN 的出现呢 这就是我们新的 Pathway Cloning 功能的用武之地 这是一项具有向后兼容性的新功能 在 WWDC21 中引入 Content Steering 1.2 有了 Pathway Cloning Steering Server 可以使用一个 紧凑的清单定义 向现有的客户端宣布新的 CDN 通过假设通路的结构上相同 可以通过复制和修改现有通路 来创建新的路径 我们来看看通路的结构 通路由一个或多个变体流组成 每个变体流只能在一个 且只有一个通路中 如果未指定 PATHWAY-ID 属性 它隐含的属于默认的“ . ”通路 每个变体流可以引用 每种媒体类型的零个或一个媒体组 音频 字幕和隐藏式字幕 每个媒体组可以由多个变体流引用 甚至来自不同的通路 当我们现有通路中克隆出新的通路时 我们不仅应该克隆其变体流 而且还有引用的媒体组 如果有的话

然后 为了使其成为新的通路 我们需要修改新克隆通路的变体 和呈现流的 URI 让我们以克隆的通路中的 6 Mbps 变体流为例

假设此特定变体流 具有如下所示的 URI 要将其修改为新通路的 URI 请执行以下操作 最灵活的方法是 完整替换完整的 URI 行 这意味着我们需要 在 Steering Manifest 中为每个 克隆的通路存储一整套 URI 但是 在实践中 我们通常可以做得更好 在业界 跨多个 CDN 部署流媒体资产 并保留相同的 URI 路径结构 是很常见的 从同一 URI 提供的资产 共享相同的 URI 主机名 和查询参数 如果是这种情况 我们只需要在清单中 存储主机和查询参数的替换 并替换所有克隆 URI 的组件 这样我们就得到了新的通路

让我们看一下如何 在 Manifest 对象中定义路径克隆 我们添加了带有路径克隆对象数组的 PATHWAY-CLONES 字段 每个路径克隆对象定义 从现有路径来的新通路 在此示例中 我们有一个路径克隆对象 BASE-ID 字段指定 CDN1 是要从中克隆的原始路径 ID 字段 将新的路径 ID 指定为 CDN3 接下来 有个 URI-REPLACEMENT 字段 其中包含 URI 替换规则对象

在此示例中 我们使用 HOST 和查询参数替换规则 这应该取代主机部分 并分别插入或替换流 URI 的查询参数 在这种情况下 我们将把主机部分 替换为 cdn3.example.com 并添加或设置值为 xyz 的查询参数 foo 和值为 123 的查询参数栏

让我们尝试在前面的示例 URI 上 应用主机和参数 URI 替换 首先 我们有基于 多变量播放列表的 URI 解析的变体流 URI

在 Steering Manifest 中 我们使用了主机 URI 替换规则 因此 对于 URI 的主机部分 我们用 cdn3.example.com 替换它 并获取了新 URI 的新主机部件

然后 我们从克隆的 URI 中 保留 URI 路径组件

最后 我们应用 URI 查询参数替换规则 在这里 我们替换 foo 参数 因为它存在于原始 URI 上 然后 我们追加 bar 参数 因为它是一个新参数 这样 我们有了新 URI 的 替换查询参数部分 最终结果 URI 来自新通路 CDN3 的 6 Mbps 变体流的 URI

我们将相同的 URI 替换规则 应用于其余变体 和克隆通路中的再现 对于 3 Mbps 变体流 我们有原始 URI 并应用主机和参数 替换规则以获取新的 URI 我们对音频和字幕再现 执行相同的操作 将 URI 替换规则 应用于所有克隆的变体和格式副本后 我们就有了一个 从新的 CDN 主机服务的新通路 让我们再举一个例子 假设流媒体提供商 希望通过对最快的 CDN 主机 进行特殊调整 来提供最高带宽的视频和音频流 这与其他较低比特率的流不同 这就是 per-stable-ID URI 替换规则派上用场的地方 在 HLS 中 STABLE-VARIANT-ID 和 STABLE-RENDITION-ID 属性 被引入 以识别变体和再现流 通过在多变量播放列表中设置 我们稍后通过通路克隆对象中的 稳定 ID 在Steering Manifest 中 引用每个变体或呈现流 并为每个流分配 URI 替换规则 要定义这些特定的 特殊 URI 替换规则 请执行以下操作 我们需要为多变量播放列表中的 所有变体和呈现流 分配稳定的 ID 例如 我们将 STABLE-RENDITION-ID “audio-en-ac3” 分配到 AC3 English 音频 并将 STABLE-VARIANT-ID “video-4k-dv” 分配到 25 Mbps 4K 变体流 然后 在 Steering Manifest 中 我们可以通过引用其稳定 ID 添加两个灵活的替换规则 对于变体流 我们将 PER-VARIANT-URIS 字段 添加到 URI-REPLACEMENT 对象 使用 STABLE-VARIANT-ID 到 URI 记录的字典 在这里 我们指定用 STABLE-VARIANT-ID “video-4k-dv” 和下面的 URI 来替换变量流的 URI 对于格式副本流 我们用 STABLE-RENDITION-ID 到 URI 记录的字典 将 PER-RENDITION-URIS 字段 添加到 URI-REPLACEMENT 对象 这里我们指定用 STABLE-RENDITION-ID “audio-en-ac3” 用以下 URI 替换呈现流的 URI

在这里 我们看到 在应用 URI 替换后 所有流都从新的 cdn3.exmaple.com 主机提供服务 除了 4K 视频变体 和 AC3 英语音频再现 其中它们具有特殊的 URI 替换规则 将其指向 faster.example.com 主机 并具有不同的 URI 路径 和查询组件

有了通路克隆 当流式处理提供程序动态生成时 在本例中 就是新的 CDNfleet CDN3 转向服务器可以添加 CDN3 作为其 Steering Manifest 中 现有客户端的通路克隆 它还可以选择一个区域 例如欧洲 来优先考虑将 CDN3 作为主要通路 当欧洲客户获得 Steering Manifest 更新时 它们将引导流量转向 CDN3 在本期演讲的最后一部分 让我们将重点转移到 Steering Server 的细节上 解释如何实现服务器逻辑 通过具体示例 引导客户端流量 以实现负载平衡 管理和编排大量客户端的一种方法 以及应用分区规则 是将每个客户端放入存储器中 并在存储器级别应用规则 在 Steering Server 上 实施存储器非常简单 不需要维护任何客户端会话状态 当客户端请求 初始 Steering Manifest 时 它在 Steering Server URI 上 发出 HTTP GET 请求 然后 服务器从 12 个可能的存储中 生成统一的随机数 返回 Steering Manifest 时 服务器会添加存储器编号 在这种情况下 7 为 RELOAD-URI 属性 这将是来自客户端播放器 下一个请求的 Steering Manifest URI 以便下次客户端播放器 请求 Steering Manifest 时 它将在其请求参数中携带存储器编号 并且服务器可以提取它并根据 存储器编号应用转向规则 现在 让我们看一个简单的 双分区转向规则 在这种情况下 我们希望引导 50% 的流量 倾向于 CDN1 其他 50% 的流量倾向于 CDN2 我们可以根据存储器编号 编写此类规则 如果客户端播放器的数 落在前 6 个存储器中 我们返回倾向于 CDN1的 带有 PATHWAY-PRIORITY 的 Steering Manifest 否则返回倾向于 CDN2的 由于客户端是统一分配到存储器的 将 12 个存储器分成 6 个存储器 可以对流量进行平均分区

现在 假设一个名为 CDN3 的 新通路是动态生成的 Steering Server 可以使用 通路克隆向客户端宣传它 而客户端并不从它们的 多变量播放列表中知道它 用 Pathway Cloning 构建 Steering Manifest 时的 一个常见问题是确定通路的集合 需要包含在 PATHWAY-CLONES 阵列中 规则是克隆不在客户端的 多变量播放列表中的通路 但是 如果没有 维护任何服务器端状态的 客户端会话 Steering Server 又如何 知道客户端多变量 播放列表中的路径集呢

一种方法是在 多变量播放列表的生成过程中 在初始转向服务器 URI 中 包含一组通路来作为查询参数 在这种情况下 多变量播放列表包含两个通路 CDN1 和 CDN2 因此 将它们作为查询参数 包含在 SERVER-URI 属性中 然后 客户端播放器 将向 URI 发送请求 将参数传送到 steering server 然后 Steering Server 可以提取参数 作为客户端 多变量播放列表中的通路集 然后它可以通过 用客户端多变量播放列表中的 通路集减去可用通路集 来计算要克隆的通路集 在这种情况下 可用的通路是 CDN1 2 和 3 客户端多变量播放列表中的通路是 CDN1 和 CDN2 因此 需要包含的通路 在 PATHWAY-CLONES 阵列中 是 CDN3

让我们也来看看 当有三个可用的通路时 Steering Server 如何更改其转向规则 在这种情况下 服务器想要分区 客户端流量在 CDN1 2 和 3 之间均匀分布 我们通过返回首选 CDN1 的 PATHWAY-PRIORITY 来编写此规则 如果客户端的存储器数量 位于 12 个存储桶的前三分之一 返回首选 CDN2 的 PATHWAY-PRIORITY 如果客户端的存储器数 在第二到第三个范围内 否则返回首选 CDN3 的 PATHWAY-PRIORITY 这样 每个通路将为 三分之一的客户端流量提供服务 凭借我们涵盖的一切 开发者现在装备齐全 使用自己的动态转向规则 构建开发者的 Steering Server 这样做可以进一步 提高流服务的可靠性

这些是我们 今年在内容指导方面的更新 如果您还没有做过 尝试采用 Content Steering 作为开发者的 HLS CDN 后备机制 因为它用途更广 并提供动态流量转向 请同时利用新的通路克隆功能 来提高服务的可靠性 像往常一样 查看最新的 IETF HLS 规范以了解更多技术细节 请记得使用 我们的 HTTP 实时流媒体工具 在进行更改时验证播放列表 最后 如果开发者有其他问题或建议 请随时通过 hls-interest@ietf.org 与我们联系 感谢您的加入 祝您今天愉快