来源：Video Breakthroughs
原标题：Core Technologies for Streaming Workflows, in 2021 and beyond
原作者：Nicolas Weil
原文链接：https://blog.eltrovemo.com/1912/core-technologies-for-streaming-workflows-in-2021-and-beyond/
翻译整理：徐鋆
摘要：本文作者以行业内资深大佬的眼光，首先概述了当下 OTT 领域的关键技术，然后展望了未来有前景的新技术，内容丰富，涵盖广泛。原文中有大量推荐阅读及参考链接，感兴趣的读者请进原文观看。

目录

• 目前的核心技术

• CMAF/CBCS/IMSC 浪潮

• QUIC 的普遍性？

• 编解码器演进

• 低延迟终于到来

• CPIX - 统治密钥交换业务

• MSE 和 EME - 视频播放器的重要推动因素

• 未来的核心技术

• 转播技术

• ABR 转码技术

• A/B 水印

• DASH 清单文件优化

• 广告插入

• 低延迟

• 源摄取和同步元数据

• QoE / 多-CDN

• 可伸缩性

• 全都放到一起

自从我在这个博客上发表上一篇文章以来，已经快五年了——距离第一篇文章已经十年了——时间过得很快，流媒体技术发展也是如此。在 2016 年，CMAF 标准化刚刚开始，承载着简化工作流程和提高 CDN 缓存效率的希望。CBCS 加密方案的支持被希望远远超出苹果的生态系统，而 IMSC 也准备成为主导的字幕标准。现在我们可以看看其中有多少真的发生了，还有哪些技术确实作为流媒体工作流程的础出现了，以及哪些可能是未来五年的重要技术。

1目前的核心技术

让我们从过去五年中被认为在 OTT 中具有重要作用的技术开始......

CMAF/CBCS/IMSC 浪潮

自 2016 年以来，CMAF 已经成为事实上的媒体容器格式。所有的视频标准制定组织（Standards Developing Organizations，SDOs），如 DVB、ATSC、DASH-IF 或 3GPP，都采用了这个 MPEG 标准作为自己标准的基线技术。消费者技术协会（Consumer Technology Association）已经启动了其网络应用视频生态系统（Web Application Video Ecosystem，WAVE）项目，以进一步推动内容生产商和媒体播放器开发商利用 CMAF 的互操作性，以及 CMAF 行业论坛，以促进 CMAF 在整个视频生态系统中的使用。CTA-WAVE 最近发布了 DASH-HLS 互操作性规范，该规范描述了 DASH 和 HLS 应如何利用 CMAF 内容，并对 DASH 和 HLS 清单文件之间的映射进行了规范。而 MPEG 已经为 DASH 定义了一个 CMAF 配置文件（核心 DASH 规范第五版的一部分，处于国际标准最终草案 FDIS 阶段）。所以 CMAF 现在无处不在，没有什么事情是不兼容 CMAF 的。所有现代视频播放器都支持 CMAF 媒体片段，所以 TS 片段的使用范围现在仅限于 iOS 10 之前的设备和其他无法更新的传统硬件播放器——由于硬件更新周期，这个集合明显在缩小。与 LL-DASH 播放器不同，苹果 LL-HLS 播放器并不利用 CMAF 片段，因为这些平台上的启发式传输依赖于全线速传输，但至少它们与之兼容，这使得 LL-HLS 和 LL-DASH 清单文件之间共享一套媒体片段成为可能。

CMAF 的成功也是以 CBCS 接管 CTR 加密方案为条件的，因为这是在同一组片段中携带多个 DRM 的初步要求，与 CTR 和 CBCS 模式的两组片段相比，CDN 以最佳的缓存效率交付。我们需要承认，这个愿景在苹果生态系统之外只实现了一半，因为只有 2020 年及以后的非苹果设备在硬件上确实支持 CBCS，这限制了对 1080p 分辨率及以上的支持。考虑到标准的硬件更新周期，这导致我们在 2025 年才能看到 CBCS 被普遍支持。即使在像浏览器这样的环境中——其中 CBCS 现在已经成为有竞争力的特性——在它与所有 DRM 和 Clearkey 加密表现良好之前，仍然有很多互操作相关的工作需要去做。

在 CMAF 的系列承诺中，还有一个方面是伴随着 IMSC1 在文本和图像 profile 的出现（见 CTA 规范的 4.4.1 节），在所有设备上使用单一的字幕 TML 格式。虽然苹果在 2017 年的 pantos-hls-rfc8216bis-00 规范草案 中引入了对 IMSC1 文本 profile 的支持，但 HLS 仍然没有正式支持图像 profile，WebVTT 在 HLS 领域的统治地位还没有真正受到挑战，使得字幕生态系统出现断裂。这可能与以下事实有关：即使是支持 IMSC1 文本 profile 这样一个广泛的规范也是具有挑战性的，需要像 EBU-TT-D 或最近的 Netflix IMSC 1.1 文本 profile 一样的配置文件。长话短说：我们需要更多的时间来看到 TTML 在业界的融合。

QUIC 的普遍性？

自 2013 年出现以来，QUIC 走过了漫长的历程，在 2015 年作为标准草案与 HTTP/2 非正式合作，并在 2021 年晋升为 RFC 和 HTTP/3 的官方基础（见 Akamai 一篇关于这段历史的精彩博文）。

通过多路连接和 UDP 来提高带宽效率，HTTP 传输的效率已经达到了前所未有的水平。在最初考虑使用 HTTP/2 推送作为 LL-HLS 机制后，苹果退缩了，因为他们意识到这与广告插入不兼容（出于 HTTP/2 的安全原因，所有媒体片段和广告片段都需要一个单一的来源），但使用 HTTP/2 仍然是 LL-HLS 合规性的一个强制性部分。而 LL-HLS 很可能会在不远的将来被更新，正式支持 HTTP/3。最初在 DASH 领域有一些担忧，因为 LL-DASH 依赖于 HTTP/1.1 分块传输编码，这不是一个跨越 HTTP/3 的概念（其中使用了 DATA 帧）。这实际上是工作得很好的，CDN 可以在原始层将 HTTP/1.1+CTE 透明地转换为 HTTP/3，并在边缘层向客户提供 DATA 帧。凭借其效率和媒体客户端与 CDN 之间的高度互操作性，QUIC 显然是 HTTP 传输方面的主导技术，现在和未来五年内都是如此。

编解码器演进

就视频编解码器而言，现在和五年前有什么区别？实际上，差别不大。AVC 仍然是占主导地位的编解码器，而 HEVC 的采用仍然滞后，因为许可情况分散。HEVC 解码广泛存在于解码芯片中，但为了避免授权费用，往往不被激活，所以它的采用一直在缓慢增加，主要是由 4K 内容分发驱动，因为 AVC 不是一个可持续的选择，而且苹果设备很早就提供硬件解码能力。在浏览器上，Safari 以外的 HEVC 支持仍然是例外，而不是常规，即使这可以通过底层硬件支持来实现。但这也是政治因素的影响，例如，谷歌更倾向于推动 AV1 而不是 HEVC，因为这是一个由他们主要控制的编解码器。与 HEVC 不同，AV1 自 2018 年起进入 Chrome/Firefox 等浏览器，并作为微软商店的免费扩展进入 Windows 10（而 HEVC 扩展是 0.99 美元的），使得 Edge 浏览器可以使用 AV1。2020 年，AV1 支持开始出现在电视上，有 LG、三星和索尼的机型，在移动领域有安卓 10+ 的支持。但苹果平台和高通骁龙 888 等流行的移动芯片组缺乏对 AV1 的原生支持，不知为何，AV1 一直处于挑战者的地位。广播标准生态系统开始认真看待它，DVB 将 AV1 列入下一代编解码器的支持名单，同时还有 AVS3（针对中国市场）和 VVC（又称 H.266）。虽然 AV1 有一个 ISO-BMFF绑定，这使得它可以在 HLS 或 DASH 背景下使用，但 HDR 支持仍然是一个新兴的 AV1 功能，只有一页说明可用于 HDR10+，而杜比视界支持的早期迹象在这里和那里可见。

在音频编解码方面，很难说在过去五年中发生了什么重大变化。AAC 变体仍然是主流选择，当有多声道音源可供转码时，一些 AC-3 变体会使流媒体变得更加精彩。没有任何音频革命真正被电视化。

低延迟终于到来

自 2017 年 DASH-IF/DVB 第一次迭代以来，LL-DASH，即 MPEG-DASH 的低延迟 profile，一直走得很坎坷。LL-DASH 花了三年时间在规范方面成熟，结果是 2020 年 2 月 DVB-DASH v.1.3.1 规范的 10.20 节和 2020 年 3 月 DASH-IF 的 DASH IOP 扩展的低延迟模式。像重新同步点这样的必要创新需要对 MPEG 的核心 DASH 规范进行多次补充，第五版有望成为该领域的最后一次迭代。DASH-IF 在 2019 年赞助了 FFmpeg 中 LL-DASH 支持的实施，所以现在有一个坚实的开源基础，用于低延迟 DASH 编码/打包，可以与各种发端解决方案相结合，如 Streamline、originjs 或 Nginx 的 dash-server。但尽管如此密集的 2019/2020 年标准化和开源工作，LL-DASH 仍然是一个相对保密的技术，很少有大规模的生产部署。DASH 玩家的生态系统仍然是分散的，对低延迟的支持就像对其他基础技术，如多周期（实现服务器端广告插入）。

通用的低延迟工作流（Akamai）

这就是 2019 年 LL-HLS 的引入对行业的激励作用，苹果突然打开了看到 20 亿台 iOS 14 设备兼容 LL-HLS 的视角。开源视频社区紧跟这一趋势，废除了 LHLS 社区规范，转而采用苹果公司的 LL-HLS 规范，在 2020 年底和整个 2021 年，Exoplayer、Shaka player 和 hls.js 中都出现了 LL-HLS 支持。LL-HLS 规范中对 RF8673（HTTP 随机访问和实时内容）的引用为与 LL-DASH 的互操作性打开了大门，通过在一组共同的片段上使用字节范围寻址（见 Will Law 关于此主题的详细博文）。并非所有主要的 CDN 都与这一最新的演变相兼容，但到 2022 年底，这应该是一个行业的竞争力特性。毫无疑问，（至少）接下来的所有大型体育赛事都将以 LL-HLS 和 LL-DASH 进行转播，向前推进。

CPIX - 统治密钥交换业务

DASH-IF 的内容保护信息交换格式（Content Protection Information Exchange Format，CPIX）规范，现在是 2.3 版本，最初于 2015 年发布，无疑是行业中最好的隐秘宝藏，因为它允许视频打包者与密钥服务器使用独特的加密密钥请求 XML 有效载荷，而此前密钥交换是通过 DRM 服务平台的专有接口实现的。像 AWS 安全打包器和编码器密钥交换（SPEKE）这样的框架，建立在 CPIX 之上，试图围绕一个共同的 API 方法进一步统一行业，以交换 CPIX 有效载荷，因为 DASH-IF 没有提供一个携带 CPIX 文档的参考 API。随着最近 SPEKE v2.0 的发布（这是我自 2019 年底以来与 AWS Elemental 的主要工作课题之一），现在这两个规范有了完美的统一，并且有了明确的跨版本的发展路径，这将使所有下一个关键的交换创新顺利到来。CPIX 是构建密钥交换工作流程的强大工具集，既然它也已经作为 ETSI 规范发布，那么它肯定会在未来几年内保持行业主导地位。

MSE 和 EME - 视频播放器的重要推动因素

在我 2016 年发表上一篇博文时，W3C 的媒体源扩展（Media Source Extensions）和加密媒体扩展（Encrypted Media Extensions）规范已经是用于支持浏览器中媒体播放和解密的主导性底层机制，被所有 javascript 驱动的视频引擎如 hls.js 或 dash.js 所利用。在浏览器领域，自那时以来最引人注目的兼容性扩展是 2019 年在 iPad 的 iOS13 的 Safari 中增加了 MSE 支持，而在联网电视领域，2016 年在 HbbTV v 2.0.1 中引入了 EME，2020 年在 2.0.3 版本中引入了 MSE。虽然 MSE 和 EME 在安卓/安卓电视领域并不适用，但这些技术已经在电视操作系统（如 LG webOS 自 v3.0 或 Tizen OS v2.3）中取得了进展，现在为在多个电视生态系统中开发和部署 OTT 播放器提供了便利。另一个有趣的扩展是对 iPhone 的 Safari 浏览器的 MSE 支持（就像已经在 iPad 上提供的那样--在这个平台上实现LL-DASH播放），但听起来苹果不太可能添加它，因为这将突然允许 (LL-)DASH 在所有的 iOS 浏览器中挑战 (LL-)HLS，并将 HLS 的相关性只限制在编译的应用程序的范围。这对于为实施者提供更多的选择是好事，但肯定不利于苹果对其生态系统的控制。

2未来的核心技术

试图预测 OTT 技术的演变总是一个非常主观的工作，但让我们在相信和怀疑之间试一试。

转播技术

虽然 QUIC 赢得了边缘之战，但它没有被集成到 SRT 或 RIST 等转播技术中（还没有），这些技术迄今为止侧重于线性 TS 摄入。随着 CMAF 的使用扩展到客户端分布的初始边界之外，它可能会加速，因为这与单比特率或多比特率的 CMAF 转播完美匹配。实际上，看到 SRT 和 RIST 利用这个机会融合成一个单一的技术栈是很好的，因为他们基本上做同样的事情，只是略有不同，支持组织试图通过 "我的成员比你多 "的新闻发布来杀死对方，在这个竞争中，SRT 联盟迄今为止已经超过了 RIST 论坛。不过，能有 Zixi 协议的公开替代方案当然是好事。Facebook 团队最近发布了 RUSH IETF 草案，该草案有可能显示出这样一条通往转播协议 QUIC 的融合之路。从视频编解码器的角度来看，在 2019 年出现的 JPEG XS 似乎正在成为低延迟无损转播的参考选项。它在 MPEG-2 中的传输是由 MPEG 和视频服务论坛（VSF）刚刚发布的 MPEG-2 和 2110-22 传输的补充建议标准化的。许可条款似乎也很合理。因此，JPEG XS 应该在未来的许多年里在转播空间中无处不在。

ABR 转码技术

在编解码器领域，通用视频编码（又称 VVC 或 H.266）肯定有很大的发展空间，它比 HEVC 有 50% 的预期改进（根据 Comcast 公司的 Jan Ozer 和 Dan Grois 的说法，目前的实现方式是 40%），而且自然适合 8K 和 360/VR 流媒体应用要求。但是，随着 MPEG LA 和 Access Advance 现在形成的两个专利池，我们有一些理由认为，这个新一代的 MPEG 编解码器可能会面临与 HEVC 前身一样的许可问题。

另一个新的有趣的 MPEG 选项是低复杂性增强视频编码（LCEVC，又称 ISO/IEC 23094-2）方法，其中两层编解码器的增强可以提高底层 AVC、HEVC 甚至 AV1 或 VVC 基础编码的感知质量，最高可达 50%。由于 V-Nova 是目前唯一被确认的专利持有人，有机会比 VVC 的许可条款更成功，并更快地引发一波实施。与 VVC 相比，LCEVC 的另一个主要优势是，它不需要重新编码整个 AVC 或 HEVC 内容库来提供可操作的好处——假设你对你的视频播放器有足够的控制权来升级它们以支持增强层。这也是一个更平稳的过渡承诺，为无法升级的传统播放器提供了向后兼容的路径。增强层信令尚未在 HLS 和 DASH 中指定，但这不应该比多层杜比视讯流的信令更具挑战性。对 CMAF 的绑定也是如此。

从音频编解码器的角度来看，很明显，我们需要新的沉浸式选项来配合 VR 视频轨道，并支持基于对象的音频，以允许定制流组。我们还需要灵活地根据可访问性需求来个性化音频流的结构。MPEG-H 提供了制作者和终端用户所需的个性化水平，为简单的流组构成提供了预设，并为流组组件之间的细粒度音量调整提供了高级设置，包括响度保护。Fraunhofer IIS有许多关于这个主题的博客文章和网络研讨会，还有一个创作套件和相关教程。最近，MPEG-H 授权计划已经启动，所以它现在已经可以用于工业。

A/B 水印

随着 DRM 和 HDCP 的利用在过去几年中成倍增加，服务器端 A/B 水印作为内容保护的"最后手段"出现，在最初的措施被规避之后。虽然几年来它一直是专有实现的游乐场，但促进了 CPIX 创建的相同的互操作性精神已经改变了 A/B 水印的格局。首先是 2020 年底发布的用于编码器集成的超高清论坛水印 API，它允许直播和 VOD 转码器以共同的集成方式承载来自多个供应商的水印模块（具有非压缩域与压缩域水印使用案例的微妙之处，水印发生在编码期间或作为其后期处理）。阅读 Laurent Piron 的这篇文章，了解关于这个版本的更多细节。目前是 V1.0.1 版本，当 DASH-IF 正在制定的配套规范发布时，该规范肯定会有小幅发展，但不会有大的转变，所以它肯定是一个坚实的基础。DASH-IF 目前正在扩展这一转码器级别的标准化工作，为原件/包装商和 CDN 整合制定补充指南。对于原创者和包装者，我们的想法是根据每个终端用户的独特水印模式和一层边缘决策逻辑，指定 A/B 水印如何与流的摄取和转换操作互动，以及来自 CDN 的转发请求，以拉取 A 或 B 版本的片段。

总的来说，这个想法是允许实施者在他们的工作流程中结合或交换各种编码器、原件/包装商和 CDN，在更换组件时只需在 A/B 逻辑方面做最小的调整。由于标准化工作相当重要，该规范将需要几个月的时间才能发布，但我相信（也许我有偏见，因为我参与了这项工作），这两个规范的结合将为实施工作提供一个非常强大的基础。

DASH 清单文件优化

目前有几项正在进行的计划，以减少 DASH 清单文件的大小——还没有与 HLS 清单一起。DRM 信号优化，由 DASH 第五版的 ContentProtection@Ref/RefID 属性定义，是最直接的优化，因为它允许在清单中声明一次 ContentProtection 元素，并在之后通过其 ID 进行引用，从而允许将 DRM 参数因素化，并大大减少所产生的清单大小。DASH 社区还在研究混合方案清单的优化，其中音频 AdaptationSets 使用简洁的 +Duration 方案，独立于视频 AdaptationSets 使用的基于  的方案，以消除音频 <S> 行因音频采样率与视频帧率不一致而产生的冗长。对于这第二项优化，还有一些验证工作要做，包括广告期和不对称/不符合规定的轨道持续时间，但通过结合这两种优化方法，优化潜力约为清单文件大小的 95% 至 98%。

还有就是 Hulu 在 MPEG（DASH 第五版第 5.15 节）和 DASH-IF 上推动的用于直播流的颠覆性的"补丁清单"方法（请看 Zack Cava 关于这个话题的精彩演讲），其目的是改变我们至今为止的一个基础假设：每次播放器在请求清单时，它都会得到播放 URL 所携带的所有 DVR 历史。补丁清单方法取代了我们在业界使用多年的这种非常粗暴的方法，它说播放器只在第一次请求时获得完整的清单（这样它就可以获得自流媒体开始时间和现在以来的完整 DVR 历史），然后它在每次补丁清单请求时获得增量清单更新，只携带自上次清单更新以来添加和删除的片段——完整的媒体时间线由播放器在内存中动态构建，作为初始清单请求和所有后续补丁清单请求的结果。

这种机制在资源受限的播放环境中非常有效，因为它优化了清单解析操作，并通过传输非常轻量级的补丁清单大幅减少了网络传输。这种补丁清单方法不仅减少了传输和解析的数据量，还能实现优化的广告插入方法。因此，它是未来 5 年 DASH 的重要工具，并且从 3.2.1 版开始已经在 dash.js 中支持。如果 DASH 播放器和包装商支持足迹的扩展，毫无疑问，这将很快成为 DASH 直播清单的主导方法。关于所有 MPD 优化方法的更多细节，请参考 Alex Giladi 在上次全球视频技术会议上的精彩演讲。

广告插入

补丁清单方法允许的新的广告插入范式是服务器引导的广告插入（Server Guided Ad Insertion，SGAI）方法（在 DASH-IF 关于广告插入的最新章节中描述）：服务器不再解析清单，用广告段引用来替换媒体段条目，而是将播放器指向轻量级的补丁清单更新，只包括离散的广告舱段，不产生额外的现场边缘延迟。从服务器端广告插入的角度来看，其可扩展性的好处是巨大的。苹果公司最近发布了一个类似的 HLS 功能与广告插播建议，这基本上是在一个离散的 EXT-X-DATERANGE 目标 URL 中隔离广告舱的片段。在这种情况下，视频播放器只有在广告舱被实际消费时才会请求广告舱的 URL，这就减少了广告服务器在初始 DVR 窗口中的负载，而不仅仅是实时清单更新。您可以在 DASH SGAI 中做同样的事情，对初始清单请求的广告期与整个 DVR 历史使用 Xlink（以便播放器仅在接近广告舱时解决广告）。

虽然 DASH SGAI 和 HLS Interstitials 共享大致相同的服务器端方法，但在客户端有区别，DASH 播放器将用一个播放器实例处理媒体段和广告段，而在 Interstitials 方法中，两个 HLS 播放器实例将需要协调工作，一个用于内容媒体段，一个用于广告舱段,至少在苹果的实现中是如此。虽然它在像苹果设备这样的受控环境中可能运行良好，但这种双播放器方法已经证明了它在低功耗环境中的低效率，因此它对更广泛的 HLS 生态系统的适用性是相当值得怀疑的，而传统的服务器端广告插入（SSAI）将继续在一段时间内发挥作用。我希望通过 CTA-WAVE DASH-HLS 互操作性倡议，这些新的广告插入方法会发生进一步的整合，但有一件事是肯定的：为广告插入进行完全清单解析的日子已经过去了，这将使我们的生活更加轻松。

低延迟

由于 LL-HLS 和 LL-DASH 是市场上的两大竞争者，留给其他以 OTT 为中心的低延迟方法的空间就很少了。由 THEO 发起并由 HESP 联盟推广的高效流协议（HESP）正是为了成为这样一种替代方案，仍然使用基于 HTTP 的传输。虽然它并不完全属于 LL-HLS 和 LL-DASH 的延迟范畴--因为它的目标是亚秒级的延迟水平，更属于 WebRTC 的范畴。

该规范最近作为 IETF 草案发布。用于达到最低延迟和压缩时间的 Maximal Gain Profile 不允许在 Continuation Stream 段中使用 B 帧，而在 Maximal Gain Profile 和 Compatibility Profile 中，Initialization Stream 段（在播放会话开始时使用）必须只包括 I 帧。这意味着所需的编码资源至少要增加一倍，才能在与连续流片段相同的帧率下，将初始化流片段制作成仅有 I 帧的片段。在制作大型 ABR 阶梯时，加倍的编码可扩展性要求并不简单，因为它可能需要将编码负载分散到多个同步编码器实例上。我们需要一个非常好的理由来接受这种权衡，比如 WebRTC 传输基础设施的成本和复杂性大大优于翻倍的编码足迹的成本和复杂性，这在一定的收视率水平上可能是真的，但我很难说清楚哪里是阈值。鉴于这种编码的可扩展性问题，我不认为 HESP 可以取代 LL-HLS 或 LL-DASH，在目标延迟为 2 至 5 秒的任何使用情况下。

关于 HESP 列举的另一个好处，值得注意的是，MPEG 正在进行一些活动，为 DASH 定义一个解决方案，可能不需要一个特定的切换适应集和一个特殊的编码或重新包装。因此，HESP 最终可能只与 HLS 在快速切换方面进行竞争。

源摄取和同步元数据

DASH-IF 正在制定一个摄取规范（第二版正在社区审查中），涵盖了 CMAF 摄取和 DASH/HLS 摄取，旨在废除仍在多个解决方案中使用的传统的 Smooth Streaming 摄取，这已经有一段时间了。这在 DASH-IF 上是一个相当有争议的讨论，而且它可能还没有完成（在一些小问题上，如使用 Unix 纪元时间作为可用性开始时间），因为 MPEG 可能会把 DASH-IF 的工作作为一个新的 MPEG 编码器和起源规范的起点，但它与 Interface 1（CMAF 的）一起朝着好的方向发展，这可能会使业界统一在一个共同协议的碎片化摄入上。被广泛采用的驱动力是平滑流格式越来越无法应对进一步的创新，以及对低延迟工作流程的普遍需求，这可以通过 HTTP/1.1 分块传输编码（或 HTTP/3 与 DATA 帧，这样摄取规范将是 HTTP/3 友好的）与分块 CMAF 相结合的摄取规范来支持。

从最初起，摄取规范中还包括使用定时元数据轨道来承载事件，如 SCTE-35 标记在一个独立的轨道中，而不是像行业中存在的数字视频以来的视频轨道。这曾经是而且现在仍然是一个有争议的话题，因为它需要一个嵌套的时间线来将元数据事件的时间戳与视频和音频的时间戳联系起来，这使得在事情发生时更难进行故障排除。除了这个矛盾点以外，这个想法是好的，因为它可以通过使用单一轨道而不是在所有视频轨道中系统地复制元数据来减少用于元数据的带宽，确保元数据独立于其他媒体轨道，并更容易通过人工智能引擎处理元数据有效载荷，以进行翻译/索引/分析。虽然有办法在 DASH 清单中发出定时元数据轨道的信号，但在 HLS 清单中仍然没有这种情况，如果这个问题得到解决，这可能会引发更广泛的采用。我们依靠像 CTA-Wave 这样的 SDO 来说服苹果填补 HLS 规范中的这种结构性空白。现在，定时元数据轨迹可以在产业链的上游使用，但不能直接被视频播放器（至少是 HLS 播放器）使用；一旦端到端的使用成为可能，那么对产业来说就是一个完全不同的故事。

QoE / 多-CDN

构建一个灵活的多 CDN 视频传输架构从来都不是一件容易的事情：每个 CDN 专有的边缘视频标记化实现往往使标记化成为不可能，而迫使使用 DRMs，在播放器层面收集的性能数据很难与 CDN 日志相关联，专有的 CDN 负载平衡机制往往需要自定义播放器实现，因为 HLS 和 DASH 规范并没有提供足够的原生机制。所有这些都将发生变化，因为有多个倡议旨在解决这些问题。

CTA-WAVE 最近与 SVA 一起开始了一项关于标记化主题的工作，它被称为通用访问标记（Common Access Token）倡议。它的目标是定义一个可以跨多个 CDN 使用的视频标记方案，这样，两个 CDN 标记之间的唯一区别可能只是用于确保 URL 签名的秘钥。一旦这项标准化工作产生结果（我认为大约在 2022 年第二季度），我们可以期待在主要的 CDN 中迅速采用，这些 CDN 厂商都参与了讨论，并且在他们的客户中渴望简化他们的实施。

有了 CTA-WAVE 在 2020 年底发布的通用媒体客户端数据（Common Media Client Data，CMCD）规范，CDN 到客户端的性能数据关联现在变得更加容易。该规范定义了关键的播放器数据点（又称 "保留键 Reserved keys"），如会话 ID、缓冲区长度或测量吞吐量，以及在 CDN 请求中包含这些数据点的方法，通过头文件/查询字符串，或与对象请求并行，向 CDN 发送独立的 json 对象。虽然该规范没有说 CDN 应该如何将数据点转发给第三方多 CDN 决策服务，但这仍然是一个非常重要的进展，因为这是我们第一次有一个标准化的框架来了解视频播放器在多个播放会话和 CDN 环境中的性能。在播放器方面，有 dash.js、Exoplayer 和 Akamai AMP 的支持。在 CDN 方面，到目前为止，Akamai 支持它，但这正在迅速扩大。Datazoom 视频数据平台也在支持它。由于支持 CMCD 对于生成多 CDN 切换所需的数据至关重要，因此在不久的将来，看到更多的播放器支持 CMCD 将是至关重要的，特别是苹果 HLS 播放器，它们在对象请求结构方面是不可定制的。这个标准化过程的下一步是定义一个通用媒体服务器数据（CMSD）的有效载荷格式，可以用来客观地比较多个 CDN 的交付性能。这项工作在 CTA-WAVE 刚刚开始，所以在我们看到可操作的结果之前，还需要几个季度的时间。但是，将 CMCD 和 CMSD 的数据结合到一个单一的数据湖中，应该能够以一种非常有效的方式为多 CDN 切换决策提供信息。

这就是 HLS 内容指导提案的作用。它没有谈及每个客户/终端用户应该如何做出 CDN 切换决定，但它描述了在 HLS 父播放列表中应该如何描述多个 CDN 的同一直播或 VOD 内容的多个版本，以及播放器应该如何根据来自内容指导服务（基本上是多 CDN 切换服务）的 JSON 响应在这些版本之间切换。总的来说，这是一个相当简单的机制，所以它完全有机会成功。问题是，这是一个以 HLS 为中心的机制，所以我们必须在同等的 DASH 机制上下功夫，比静态的 BaseURL 元素有更多的表现灵活性，以支持多个 CDN 和相关的边缘令牌，并利用相同的内容指导服务 JSON 有效载荷。这项工作在 MPEG 或 DASH-IF 还没有开始，但这只是一个时间问题，直到它被拾起。一旦完成，我们将得到一个强大的框架，通过 CMCD/CMSD 和通用接入令牌来构建多 CDN 交换服务。

可伸缩性

我认为对可扩展性影响最大的技术之一将是 IP 多播自适应媒体流——也就是所谓的多播 ABR（mABR）。在过去 5 年左右的时间里，像 Broadpeak 这样的公司一直在采用专有模式，电信公司和有线电视运营商的采用率也很高。它基本上是将单播的 DASH 或 HLS 流作为输入，并将其转化为多播的 DASH 或 HLS 的直播边缘片段，视频播放器以单播方式请求 DVR 片段，传递直播内容的最后几分钟。它最近被 DVB 标准化为 DVB-MABR，作为更广泛的 DVB over Internet（DVB-I）计划的一部分，它现在可供所有网络运营商实施。5G 的混合模式组播能力也有同样的潜力。在实践中，它仍然受制于电信网络上非常有预见性的 IP 多播计划配置--这意味着它可以用于已知的 24/7 直播频道，是一种相当静态的、类似 IPTV 的配置。

但是，让我们快进到这一天，当这项技术最终使用完全动态供应时（这不是现阶段规格的一部分，现在只是活在我的想象中）——意味着它将能够应用于运营商网络上最受欢迎的直播流，可能是事先已知的 24/7 频道或任何 OTT 事件流（如高级拳击或足球付费赛事）突然在网络上聚集了几十/十几万观众。与目前的单播情况相比，常规 OTT 流的好处将是巨大的，在单播情况下，由于反向代理架构的可扩展性限制，流会以最大努力的方式被缓存在 ISP 基础设施中。

DVB-MABR 方法的另一个局限性（实际上 ATSC 3.0 也是如此）基本上是它采用了传统的广播视角，同时将线性流换成了分段格式，而不是试图通过广播可扩展性技术来改善分段格式的传输。从广告插入的角度来看，它通过第三方 CDN 代理服务（在苹果语言中又称内容指导服务）将视频播放器重定向到多播交会服务的方式是一个非黑即白的选择：如果直播流以单播方式播放，那么你可以使用 SGAI；如果直播流以多播方式播放，那么广告插入就需要在客户端进行（通过单播），这其中有很多的隐患。最后，无论直播流的传输模式是什么，个性化的广告段都将通过单播传输，所以为什么不尝试将清单和段的传输解耦，通过系统地以单播方式交付个性化的清单（这现在是一个高度可扩展的选项，使用 DASH 补丁清单或 HLS 广告插播），段的转发请求在进行多播终止的网关上从单播翻译成多播？这将通过坚持 SGAI 方法来保持广告插入工作流程的效率，同时通过媒体段的多播交付来保持分段线性流的可扩展性（这才是真正的可扩展性问题）。它还将保留做有针对性的内容替换的灵活性（如地理定位/基于用户状态的停播或体育比赛直播替换），这在全多播的直播场景中是不容易做到的。然后，问题就变成了如何让多播网关知道单播和多播媒体段 URI 之间的映射，但与多播服务器在上游进行的单播到多播的转换相比，这是一个微不足道的问题，需要解决。

虽然我相信我在这里提出的单播/多播混合传输方案可以成功实施，但通过多播传输媒体片段会带来另一个问题：它基本上阻止了 A/B 水印的工作，因为媒体片段对每个视频播放器都是一样的。在单播 A/B 水印的背景下，CDN 边缘决策逻辑为媒体片段的转发请求路由提供动力，需要用其他东西来替代。第一个选择是通过组播传输所有 A 和 B 段的变体，让组播网关操作 A/B 逻辑，而不是单播 CDN 边缘。从安全的角度来看，这是一个挑战（多播网关必须经过加固，并支持复杂的 A/B 逻辑），从网络的角度来看（在不同的多播 URI 上以 A 和 B 的变体传输所有的流，以及它在网络上占据的所有空间）。第二种选择是使用单一的组播媒体段，用客户端水印取代服务器端 A/B 水印，在视频播放器方面也有同样的加固挑战，如果水印已经在客户端进行了完全的单播 OTT 分发，这可能真的不是一个额外的负担。不管怎么说，这里有一个很大的挑战要解决，而且绝对不是简单的。我相信 DVB 和 DASH-IF 的专家会找到一个优雅的解决方案，如果我们在混合单播/多播传输模式的规范中走到这一步的话。

全都放到一起

纵观本文，我们得出了一个混合架构的设想，在这里我们既可以受益于 OTT 解决方案的灵活性--服务器端流的个性化/SGAI、清单优化和基于标准化 QoE 反馈环路的多 CDN 切换，又可以尽可能受益于媒体段的组播交付的可扩展性。让我们用一个高层次的图表来总结一下，看看每种技术需要在哪里实施，主要的数据流是什么（而不是应该如何设计冗余/故障转移架构）：

我可能还需要 5 年的时间来实现这个愿景，但这很好，因为我还很年轻。最后我想说，在过去的 21 年里，与众多的流媒体技术打交道，对我来说是一次令人兴奋的旅程，我总是对这个领域的下一步发展感到着迷。在过去的 5 年里，我们看到了大量的技术在 OTT 领域崛起，而且在未来的 5 年里，这种节奏似乎也不会慢下来。很高兴看到我们正在达到这样的地步，即我们拥有所有必要的工具，使流媒体像广播一样可靠和可扩展——终于！。

文章来源：媒矿工厂