通过 HLS Content Steering 改善全局流化可用状态

♪低音音乐播放♪ ♪ 郑乃伟：你好 欢迎来到WWDC 我叫郑乃伟 我来自Apple的HLS流媒体团队 今天 我将讨论HLS中 称为内容引导的新功能 以及它如何提高全球流媒体的可用性 今天的网络连接是全球性的 流媒体公司在世界各地 提供他们的内容 然而 在全球范围内交付内容带来了 大量的挑战 是这个行业必须解决的 我们 Apple的HLS流媒体团队 也意识到这些具有挑战性的问题 并不断努力提供解决方案 今天 我们将集中讨论可用性的问题 特别是网络拥塞缓解 和错误恢复 为了帮助我们理解这些问题 我们来看个例子 假设亚洲一家受欢迎的流媒体公司 在以下三个国家 部署了CDN基础设施 中国、日本和新加坡 在这张图中 我们展示的状态是 一切运作都很完美的状态 我们有中国使用者使用中国CDN 也有日本使用者使用日本CDN 这两个CDN网络的性能都很好 现在 让我们介绍一些变化 假设一段时间后 中国的CDN流媒体 使用者大幅增加 导致CDN网络已经过载 用以前的HLS技术 我们很难完全解决 网络拥塞的问题 虽然我们可以将新使用者 分配到不同的CDN 但是 很难指导现有客户 使用不同的CDN 现有流量将会不断 使目前的CDN过载 有了我们新的HLS内容引导功能 内容公司可以通过 托管自己的引导服务器 来解决此问题 它与所有最新的HLS客户端 建立一个侧通道 以使用最新的CDN策略更新它们 例如 它可以向中国30%的现有客户 发送策略更新 以切换到日本CDN 而接收到策略更新的客户端 将接受更改 并将网络流量重定向到 日本CDN 解决了中国CDN网络拥塞的问题 但网络拥塞只是众多 可用性问题之一 网络中断时会发生什么？ 让我们再举一个例子 假设日本使用者 到日本CDN的网络路径 发生了区域性中断 使用我们以前的HLS技术 内容公司可以在主播放列表中 列出我们的备用变体流 这样客户可以尝试列表中的各个项目 直到找到一个有效的CDN 但是这种方法是初步的 因为内容公司无法实时更改 主播放列表中列出的CDN的顺序 或优先级 然而 在引导服务器的帮助下 客户近乎实时地更新 最新的CDN优先级 让我们回顾一下 看看它如何 帮助客户更有效的修正错误 在网络中断之前 日本的客户会定期 从引导服务器 获取CDN优先级列表更新 假设在最新更新中 日本的客户收到以下 CDN优先级列表 其中日本CDN是最受欢迎的 其次是新加坡 然后是中国 目前 日本使用者 正在使用日本CDN 现在当发生网络中断时 日本CDN将从优先级列表中 标记为不利使用 客户将移至优先级列表中的 下一个CDN 在本例中为新加坡的CDN 并重定向他们的网络流量 现在日本的使用者将能不受干扰地 继续观看他们的节目了 我们的示范向你展示的只是我们 新的HLS功能内容导向的概述 现在让我们更深入地 向你展示如何将这个 惊人的功能集成到你的流中 这是一个复制所有可用变体的 不同CDN URL的简单列表 如前面所述 这样的播放列表 有一个固定的和最终的 CDN优先级排序 内容公司不能在稍后的 播放过程中更改它 现在让我们看看如何向这个播放列表 添加内容引导支持 你可能会很意外 引入的变化如此之少 事实上 这些更改与当前的HLS客户 是向后相容的 让我们来浏览一下添加的内容 最值得注意的是 我们现在通过每个变体流上的 PATHWAY-ID属性 将变体流 分组到不同的路径中 其中每个路径通常对应一个CDN 在这个例子中 我们将不同的 变体流分为路径CN JP和SG 分别代表中国、日本 和新加坡的CDN 然而 路径可能包含来自不同CDN的 变体流 以支持更高级的案例 当客户选择路径时 只有来自该路径的变体流 才有资格进行变体选择 新的CONTENT-STEERING 标签上的PATHWAY-ID属性 指定了在回放启动时使用的初始路径 因此 在这种情况下 客户端将只在 初始播放时从属于CN路径的 变体流中进行选择 SERVER-URI属性 指定内容导向服务器的位置 客户端将从该URI中 获取内容指导更新 但是如果你的播放列表 包含媒体组呢？ 没问题 启用内容引导仍然非常简单 你所要做的就是 为每个路径复制媒体组 并为它们分配唯一的GROUP-ID 例如 这个播放列表中的音频组 正在为每个路径复制 并将GROUP-ID 设置为CN路径的CN-audio 等等 当HLS客户端加载带有 内容引导标签的 主播放列表时 就会触发稍微不同的启动例程 首先 当它执行初始变体流选择时 它只会使用来自初始路径的变体流 然后它将像往常一样加载并开始播放 所选的变体流及其媒体片段 但与正常的播放例程并行 客户端将开始在后台 定期发出引导清单请求 让我们来看看 引导清单请求长什么样子 这只是一个简单的HTTP GET请求 它根据主播放列表URL 从SERVER-URI属性 发送到这个已解析的URI 引导服务器将响应引导清单 让我们用一个例子来分析它的格式 引导清单是一个JSON文件 引导服务器可以为每个客户端 制作自定义的引导清单 这使引导服务器 在塑造其托管网络流量方面 具有很大的潜力 此引导清单中最重要的属性 是PATHWAY-PRIORITY字段 这是一个按优先级排序的 路径ID列表 第一个是最优先的 在本例中 我们优先选择CN路径 其次是JP 然后是SG 客户端在收到来自引导服务器的 引导清单后 将进行内容引导评估 以确定是否 切换到不同的路径 首先 客户端将排除不符合 选择条件的变体流 这包括由于网络错误 而不利使用的变体流 而且 不支持编解码器的变体流 就像平时的变体选择一样 它将选择至少有一个 符合条件的变体流 并且在所有符合条件的路径中 具有最高路径优先级的路径 如果选择的路径 与当前使用的路径不同 客户端将立即切换到新路径 如果没有选择合适的路径 或已经在使用选择的路径 客户端将什么都不做 继续使用当前路径 最后 客户端将安排 下一个引导清单的请求 以从引导服务器获取最新的更新 那么这个调度是如何运作的呢？ 让我们来看一下引导清单 请注意 这里有一个TTL字段 用于指定 客户端在发送 下一个引导清单请求之前 应等待的秒数 在本例中 在客户端 使用此引导清单的路径优先级列表 执行内容引导评估后 它将在三百秒 也就是五分钟内 安排下一个引导清单请求 还值得注意的是 引导服务器能够在 每个引导清单响应中更改此TTL值 从而影响客户端 应安排下一个请求的时间 它还有助于引导服务器 向每个客户端的TTL值 注入一些随机性 以分配服务器负载 此外 可选的RELOAD-URI字段 告诉客户端在哪里 请求下一个引导清单 引导服务器可以利用此字段在URL中 注入客户端特定的状态或会话数据 以便在下一个请求中回显 现在你已经了解了内容引导的 主要技术细节 让我们回到我们稍早的例子 看看它是如何运作的 假设在这种案例中下 中国的所有使用者 都收到了一个 以CN路径为首选的引导清单 并且由于使用者数量的增加 相应的中国CDN已经超载 于是引导服务器开始行动 向中国30%的使用者 发送不同的引导清单 其中最喜欢的路径改为JP 在进行内容引导评估后 这30%的中国客户 将切换到JP路径 将他们的网络流量 重定向到日本的CDN 解决中国CDN的网络拥塞情况 最后 我们介绍了内容引导的 新HLS功能 解释了它的运作原理 以及如何将其集成到你的流中 有了这个惊人的功能 你将能够 微调你的全球流媒体可用性 要了解更多技术细节 请点击此视频下方的 《HLS内容引导规范》连结 我还想告诉你 我们最新的 HTTP Live Streaming Tools 也支持播放列表和引导清单验证 我还要感谢我们在 HLS Interest IETF论坛的 同业成员那里 收到的反馈和帮助 也欢迎未来有更多反馈和建议 这些都就绪后 在今年的WWDC Seed版本中 开发人员和使用者 将可以使用HLS内容引导 因此 如果你想要更好 可用性更强的 全球流媒体传输 请立即行动 将HLS内容引导 集成到你的流媒体中 并为你的客户带来更好的流媒体体验 非常感谢 ♪