HLS 内容转向和插页式广告规范介绍
来源：Global Video Tech Meetup：Seattle 作者：Zac Shenker 内容整理：胡经川 本文从多 CDN 切换入手，介绍 HLS 中内容转向的新规范以及插页式广告规范。
目录
- 多 CDN 切换
- 基于 DNS 的 CDN 切换
- 基于清单(Manifest)的 CDN 切换
- 基于客户端的 CDN 切换
- HLS 内容转向规范
- 插页式（interstitial）广告规范
多 CDN 切换
随着用户的增多，许多媒体公司从很多不同的角度需要多 CDN。在许多区域，对于冗余和故障转移，或者在许多高并发的大型活动中，多 CDN 可以分配和缓解负载。在多 CDN 体系结构中，流媒体服务的内容（图像、视频文件等）在不同地理区域的多个 CDN 提供商之间缓存。借助于智能负载均衡算法和在传输管道的不同点收集的数据，客户端的传入流量分布在这些多个 CDN 提供商之间，从而提供了更大的冗余和性能优势。
数据通常是通过 QoE/QoS 分析供应商收集的，或通过专有的方式测量网络性能（例如，下载虚拟文件所需的时间）。所有这些数据都被一个中央规则引擎或服务器使用，以决定多个 CDN 中的哪一个应该为来自某个地区的请求提供服务。
多 CDN 切换并不是 HLS 标准生态中原生的部分，有许多不同的实现方式，各有各的优缺点，以下是一些最常见的实现方式。
基于 DNS 的 CDN 切换
通过一个域名引导所有内容请求，该域名实时动态地处理流量分布。因此，如果域中的所有流量都需要从 CDN-A 重定向到 CDN-B，那么 DNS 将指向 CDN-B。这项技术很简单，非常容易部署并且支持全平台，许多公司都走这条技术路线。
但它不是很有效，因为 DNS 传播非常耗时，并且需要几分钟才能通过网络传播。在随后的时间内，最终用户可能会通过错误的 CDN 向内容服务器发送许多请求，如果处理不当，最多会导致性能下降或所有请求的服务中断。
基于清单(Manifest)的 CDN 切换
CDN 切换的另一种技术是实时更新清单。在这种方法中，决策服务器根据切换规则和因素重新更新清单以指向不同的 CDN。这需要加载（或重新加载）清单，以便应对变化。虽然这似乎是一个简单的策略，但它需要设置一个服务器，在更新后重新提供清单（没有被缓存）。这种服务的一个变种还在清单中记录了一个 CDN 的列表，在其中一个 CDN 失败的情况下，用户可以切换到这个列表其他的 CDN。
虽然这种技术看起来很容易，但在 HLS 播放列表中如何指定 URL，播放器在直播与 VOD 场景下如何频繁请求新的清单等方面都存在问题。
基于客户端的 CDN 切换
在客户端交换中，交换机制被集成到了客户端，这就允许了许多细粒度的控制。由于基于 HTTP 的流媒体的性质以及 HLS 中独立可解码切片的使用，用户可以从不同的 CDN 中独立获取每个切片。此外，用户还拥有有关网络状况、延迟和其他因素的“最新”信息，这些因素都可以成为决策节点。
但是这种方法存在许多缺点。首先你需要将额外的程序嵌入到客户端中，以便与维护所有规则和切换因素的外部服务器进行通信，而且你需要为所有平台的客户端（HTML5、Android、iOS、Roku、智能电视、Xbox 等）编写、测试和维护 SDK，这是一个艰巨的任务。此外，在客户端中改变流的 URL 需要访问客户端的源代码或 API。在无法获得这种级别的代码支持的平台上，你将无法在客户端实现流媒体的切换。
在了解了实现多 CDN 切换的不同技术后，你现在一定已经意识到，没有一个放之四海而皆准的方法。相反，公司可以根据他们的需求、基础设施能力、设计、预算和规模采用不同的策略。
HLS 内容转向规范
到目前为止，HLS 中的内容转向规范的最新版本号为 1.2b1，这是此规范的第三个版本，每一个版本都是向后兼容的。这个规范定义了 master 播放列表的语法，允许内容供应商指定客户如何优先访问其内容的不同路径，这是使用一个由用户定期重新加载的外部转向清单实现的。所有的 CDN 都应该在这个 master 清单中指定。
有一些新的内容被添加到这个版本的规范中。首先是#EXT-X-CONTENT-STEERING，它主要有两个属性，SERVER-URI 和 PATHWAY-ID。
- SERVER-URI 属性是一个指向内容转向清单的 URI，如果转向服务器需要 asset 标识符来产生转向清单，SERVER-URI 就可能包含 asset 标识符。它可以使用数据 URI 方案，在 master 播放列表中提供在线清单; 在这种情况下，可以使用 RELOAD-URI 参数将随后的清单重载重定向到远程转向服务器。
- PATHWAY-ID 属性标识了必须由客户端应用的 pathway，直到获得初始的转向清单。它的值必须是一个合法的 pathway ID，如 "Steering Manifest "部分所规定的。
图1：语法标签实例 1
此外，还有一些转向服务器查询参数，客户端发送一个带有转向清单 URI 的请求，以获得转向清单。它可以在 URI 上添加以下查询参数。
- _HLS_pathway:当前使用的 pathway 的 ID
- _HLS_throughput：THROUGHPUT 是每秒的整数位数。它表示客户端对应用的 Pathway 所做的下载吞吐量的当前预测。比特率估计的确切方法因客户而异。需要注意的是，HTTP 代理缓存应该为从其缓存键中排除此参数。
图2：转向服务器查询参数
另外还有内容转向清单(Steering Manifest)。内容转向清单响应是一个 JSON 对象，它有许多字段。首次第一个字段是版本号，固定为 1；
下一个字段是 TTL，TTL 指的是客户端在重新加载转向清单之前必须等待多少秒。推荐值是 300 秒（5 分钟）。转向服务器可以根据客户端改变 TTL 以分配服务器的负载；
然后是 RELOAD-URI，这是可选的，它指定客户端在下次获得转向清单时必须使用的 URI。它可以是一个基于当前转向清单 URI 的相对 URI;
PATHWAY-PRIORITY 字段是包含 Pathway ID 的数组。PATHWAY-PRIORITY 数组中的元素是按 Pathway 偏好排序的，第一个是最优先的。一个转向清单必须包含至少有一个 Pathway。在 PATHWAY-PRIORITY 数组中的一个 Pathway ID 不得出现超过一次，客户端必须忽略 PATHWAY-PRIORITY 数组中未被识别的 Pathway ID。
图3：转向清单
关于规范的更多内容，可以参考其 PDF 完整版本(https://developer.apple.com/streaming/HLSContentSteeringSpecification.pdf)
插页式（interstitial）广告规范
目前，服务器端广告插入（Server Side Ad Insertion）是最常用的方式，然而它还面临着许多挑战。HLS interstitials 规范旨在让广告内容的部署更加便捷，无论是在服务器端还是客户端，它不再需要依赖 SSAI 中的特殊标签。此外，它对 VOD 和直播场景都支持得很好。
图4：HLS interstitials 规范目标
此规范中，服务器可以插入 EXT-X-DATERANGE 标签来告诉客户端安排插页式播放。它包含许多属性，如下图所示。
图5：DATERANGE 标签属性
首先，CLASS 属性固定为 “com.apple.hls.interstitia”；X-ASSET-URI 属性是一个带引号的绝对 URL，用于一个单一的 interstitia asset; X-ASSET-LIST 属性是指向一个 JSON 对象的 URL，该 JSON 对象必须包含一个键/值对；X-RESUME-OFFSET 属性的值是一个以秒为单位的十进制浮点数，用于指定在插页式广告播放后应在何处恢复主要内容的播放，X-RESUME-OFFSET 的典型值为零，如果 X-RESUME-OFFSET 不存在，则播放器使用插页式播放的持续时间作为恢复偏移量，这适用于从实时边缘保持恒定延迟的实时播放和 VOD 播放；X-PLAYOUT-LIMIT 属性的值是一个十进制的浮动秒数，指定了整个插页的播放时间限制。如果它存在，播放器应该在达到其开始时的偏移量时结束插页播放，否则应该在到达插页终点的时候结束。
关于规范的更多内容，可以参考其 PDF 完整版本(https://developer.apple.com/streaming/GettingStartedWithHLSInterstitials.pdf)
附上演讲视频：
http://mpvideo.qpic.cn/0bc3uqaa2aaavyaag5xwuvqvbjgdbwsaadia.f10002.mp4?dis_k=320cd40dca1e9875e686785000c3fec3&dis_t=1645152937&vid=wxv_2246857306133184513&format_id=10002&support_redirect=0&mmversion=false