通过 OTT 进行高度可扩展和冗余的直播

ZEE 重新开始了国际 T20 联赛的体育直播，在 Zee5，这是我们第一次向终端用户提供体育直播的工作。

为了确保我们在每个比赛日都能获得正确的数据流，这是一个艰难的旅程——从接收来自阿联酋的信号，到在播放时添加SCTE-35/辅助广告，再到使用预置编码为体育直播提供最佳的视听体验，然后通过能够处理数百万次同时请求的CDN架构来提供内容，这一切都让人兴奋不已，有时也让人沮丧不已！

本文由 Zee5 高级副总裁兼视频工程主管 Suneel Khare 和首席架构师 Rahul Banerjee 撰写，并得到 Falak Sangani、Gautam Kumar 和 Rakesh Rajan 的支持。

墨菲定律一直困扰着我们，但我们的视频工程管道确保我们始终能够应对挑战，并确保不会中断最终用户的视听体验。

每场比赛都以三种不同的语言进行直播：

英语
印地语
泰米尔语

在与某场比赛有关的每个流媒体中，三个频道的视频是相同的，而音频评论和图形（记分牌等）则与上述语言之一有关。解说和相关图形的添加是作为体育场内生产的一部分进行的。后期制作中，所有这些流媒体都通过ISP网络传输到印度（稍后部分会详细介绍！）

此外，我们有几个双赛日，所以基本上，双赛日就像同时有六个不同的频道！

Zee5 Video Engineering 团队面临的挑战是为每位最终用户提供一流的无缝运动体验。这要求我们构建一个完全冗余和可扩展的解决方案来满足大量同时请求。

以下部分将深入探讨现场体育架构的要求和各个方面的详细信息。

要求

要求可以大致分为以下三个部分 –

与需求有关的流的特征
流媒体的交付
向各种类型的消费者（即终端用户、B2B客户等）提供流内容。流方面的一个要求（即解决方案将消费的内容）和解决方案要求的各种功能。

流特征的相关要求

每个匹配项和语言都会有一个冗余流。因此，对于单个匹配项，6 个流 (3 + 3) 将可供系统使用。
每个流将包括一个视频（AVC 编码）和一个音频（AAC 编码）流。
上述 6 个流中的每一个都是 25 Mbps SRT 流。
每场比赛还将有两个次要的SRT信号，每个信号的比特率为15 Mbps。其中一个将有英语评论和图形，另一个将有印地语和图形。
对于双赛日，第一场比赛和第二场比赛的部分内容会重合，这意味着该阶段的容量要求会增加一倍。
选择 SRT 是因为它速度快，而且具有内在的抗错性。

流媒体的交付

如上所述，每场比赛将有 3 + 3 个 SRT 流。后期制作流是 j2k 格式（几乎未压缩），并作为输入传递给 Zee Satellite 广播链。
这个 j2k 流在 ISP POP 被编码成 25 Mbps SRT 流，然后通过 MPLS 链路被推送到位于孟买 Rabble 的 AWS 数据中心。
对于给定的语言，如上所述，存在 1 + 1 冗余。主流是“无中断的”（即，ISP 确保主流的传输本质上是冗余的，因为该流进一步分为两个流，并在到达端点之前合并），而备份/辅助流则不然。
这些流通过 AWS Direct Connect 接收到 AWS 环境中（出于安全原因，此处使用私有虚拟接口）。
此外，从相同的 j2k 流中，生成了 15 Mbps 流并通过完全不同的路径在互联网上推送。
使用 AWS MediaConnects 在 AWS 环境中接收这些互联网流。

向各种类型的消费者提供流媒体内容

首要的要求是为每个终端用户提供最佳的体育视听体验。
解决方案必须自始至终都是冗余的，最终用户不应有任何停机时间。
支持在Zee5平台上查看内容。
允许通过服务器端广告插入将 SCTE-35 标记插入 Zee5 上广播的一般娱乐频道来获利（这些频道默认不启用 SSAI，因为流不携带 SCTE-35 标记）。
使用正确的格式和徽标将 SRT 流式传输给 B2B 客户。
向我们的合作伙伴提供 SRT 流，以生成近乎实时的精彩片段。
提供给最终客户的流是 HLS TS 和清晰的（未加密的DRM）。
每个使用流的设备都将获得 1080p (1920×1080) 作为最高分辨率！
服务器端广告插入 (SSAI) 应该可以在流媒体上播放。

以下部分描述了我们如何最终实现所有要求以及更多要求的架构细节！

解决方案

本节将解释我们如何逐一实现上述高层次的要求，并在本节末尾列出完整和最终的架构图（满足所有要求）。

冗余的流媒体架构实现了沉浸式的视听体验

下图描述了冗余的数据路径，描述了产生单一通道的机制（即与特定语言有关的流，在此图中为英语），为终端用户提供沉浸式的体育体验。

如要求部分所述，AWS 直接连接是 AWS 流系统的网关。
与特定语言相关的 SRT 流（主要和备用）将在位于不同可用区的两个MediaConnect上接收。
互联网上的流媒体也在单独的 MediaConnect 上接收。
流媒体的下一跳是播放。播放员负责以下工作
- 添加填充程序
- 添加基于导演助理轨道的 SCTE-35 标记。
- 添加辅助广告（Aston 和 L-Bands）。
播出解决方案由合作伙伴提供，并在AWS EC2上运行。
从上图可以看出，对于每个语言流，使用了两个分布在可用区域中的播放实例。

主要播放将接收三个输入
- 在主要媒体连接上收到的信息。
- 在辅助媒体连接上收到的信息。
- 在媒体连接上接收的信息通过互联网接收
备份播放将接收两个输入
- 在备份媒体连接上收到信息。
- 在媒体连接上接收的信息通过互联网接收

通过 SRT 接收的流为 1920×1080（每秒 50 场，隔行扫描），播放被编程为生成 1920×1080（每秒 25 帧渐进）。
Playout 的输出流将进入编码器，我们使用AWS MediaLive标准分发来生成要提供给用户的演绎版。
AWS MediaLive标准发行版附带两个 NTP（网络时间协议）同步 MediaLive 编码器，它们位于不同的可用性区域，NTP同步确保可靠地切换以使用一个编码器到另一个编码器的输出，以防第一个编码器出现问题。
MediaLive 还允许从主输入流切换到另一个输入流，以防发现输入异常。但为此，输入流必须是 RTP，因此我们使用 playlet 将 SRT 流转换为 RTP 并提供给 MediaLive。
MediaLive 编码器带有大量编码选项，可控制生成流的编码质量和带宽。我们进行了一项练习，以得出每个再现可以实现的再现和最佳质量，同时通过微调 MediaLive 上的相关杠杆来密切关注各种 QoS 指标。
从 MediaLive 生成的再现被推送到源，对我们来说是Akamai MSL。Akamai MSL 广泛应用于 M&E 行业，为同时收视率高的体育赛事提供服务。MSL 还通过多区域实现高冗余。
最后，清单和片段通过 Akamai CDN (AMD) 提供给最终用户。

该解决方案中的每一块 brick 都是在仔细分析性能、装配和冗余后选择的。

所有这些关于冗余系统的谈论在现实中是如何发生的？

布丁的证明真的在测试中！在整个一个月的频道中，我们在流媒体的源头方面出现了大量的中断，即以下的方式：

我们突然发现一个 feed 的主流定期关闭，并转而使用备用 feed 作为播放输入的主要来源来规避这个问题。
比赛期间，通过 AWS Direct Connect 的所有主要和备用数据源多次出现故障。那时，我们使用来自互联网的信息作为播出的主要输入来规避这个问题。

我们感到非常自豪的是，尽管在几乎每场比赛期间，输入流方面都出现了反复的问题（上述性质），但最终客户的身临其境的视听体验从未受到干扰！

通过 SSAI 从娱乐频道的体育流媒体中获利

IL T20 比赛也被传送到大约十个娱乐频道（即 Zee TV 等）。通常，娱乐频道流不包含 SCTE-35 标记，因此不会使用 SSAI 。但是，业务团队要求通过插入 SCTE-35 标记，将这些频道上的 IL T20 比赛流媒体货币化。

这个要求是在最后一刻提出的，因此迫使我们真正创新地提出解决方案！

上图描述了解决方案：

Zee5 上的常规流路径显示为简化版本（为简单起见删除了冗余连接），数据路径可以通过链接 1 和 2。

本节的兴趣点真正从链接 3 开始。此时，我们有一个 25 Mbps SRT 流和 SCTE-35，并且辅助流可用。让我们跟随数据路径。

对于每个语言流，提供了两个媒体连接（用于冗余，在不同的可用区）以接收来自播出的输出（请记住，对于每个语言流，我们在不同的 AZ 上有两个播出）。
因此，每次播出我们都有一个媒体连接，下游到播出和接收内容（请参阅链接 3）。为了简单起见，在上图中我们只显示了主要连接。
我们已经通过 650 Mbps MPLS 在德里 NCR 数据中心和 AWS 孟买区域之间预置了直接连接，用于定期内部通道交付以打包到 AWS Media packager。当我们开始这项工作时，几乎使用了 80% 的链路容量 (520-530 Mbps)。

但是，如果我们必须为每个通道发送 25 Mbps 的流，我们就会超出容量。增加链接容量不是一种选择，因为它需要时间！
这是团队想出一个非常创新的解决方案的地方，如下所述
- 我们仅通过直接连接向德里 NCR 数据中心发送了三个流（一个流，每个流都带有与英语、印地语和泰米尔语相关的音频评论和图形），并且在 elemental 上收到了它们；通过链路 5 的编码器。
- 此外，我们还通过另一个链接将相同的 3 个流发送到 Prem 编码器上的相同流（图中未显示）来确保此处的冗余。所以在 Prem 编码器上接收 3 个流（具有适当的 1 + 1）冗余）。
- 现在，on Prem 元素编码器（比如接收英语流的那个）作为 UDP 多播服务器工作， 任何数量的负责与英语评论和图形进行流媒体匹配的元素编码器都可以通过多播连接到该服务器。
通过上述机制，通过使用来自 MPLS 的 75 Mbps 带宽，我们已经能够为大约 10 个频道提供服务（在这 10 个频道中，一些需要提供英语解说、一些印地语和一些泰米尔语）。
现在，让我们以 Zee TV 为例，看看它过去是如何工作的。
- 负责为 Zee TV（在 Zee5 上）生成再现的元素编码器现在有两个输入，一个来自常规的本地播放（图中未显示），第二个输入是 UDP 多播，如上图链接 6 所示。
- 通过第二个输入的数据仅在比赛转播开启时可用。
- 作为商定的运行顺序的一部分，在每个比赛日的特定时间，我们切换 Zee TV Elemental 编码器以开始使用来自第二个输入的数据（通过包含 SCTE-35 标记的 UDP 多播）。这确保现在 SSAI 可以在 Zee TV 上关闭，因为流包含 SCTE-35 标记！
- 生成再现后，这些再现将通过预定义和现有的 Zee5 实时路径推送到 Mediapackager。
- 再次在比赛结束时，根据约定的运行顺序，在特定时间，我们将 Zee TV 元素编码器切换为使用常规播放输入的数据。
这种切换以绝对无缝和帧精确的方式进行。遵守预定义的运行顺序始终确保切换不会给最终用户造成任何突然的体验问题。

上述机制实现了通过 SSAI 将娱乐频道上的体育流媒体货币化的业务需求。上述解决方案确保我们重用现有基础设施来实现要求。

上述解决方案以绝对无缝的方式在所有 34 场比赛中发挥作用！

冗余的另一个层次

虽然设计和解决方案非常可靠，但我们希望拥有另一种灾难恢复机制。这个想法是这个机制将尽可能少地重复使用前面图中显示的组件。

因此，这就是我们为绝对灾难恢复而构建的流媒体链。该链的构建仅用于英语，并不意味着要受 SSAI 的约束。

数据流向如下：

此数据流的来源是通过互联网到达 AWS 的英语 SRT 流。这确保不再依赖孟买的 AWS Direct Connect 作为数据到 AWS 系统的单一来源（网关）。
从媒体连接（具有 1 + 1 冗余），数据通过 Airtel 链接传递到 Prem 元素编码器（不使用德里 NCR 地区数据中心与 AWS 孟买地区之间的通常直接连接，就像早期用例一样）。
除了 CDN 使用外，其余流程与常规直播流程相同。
通常，对于实时流，AMD 是面向客户端的 CDN。但是，为了避免 AMD（即使它具有 100% SLA）作为单点故障，DR 流使用 Cloudfront 作为面向客户端的 CDN。

默认情况下，此流程保持关闭状态，仅在主流失败时才启用。值得庆幸的是，它从来不需要打开！

诺伊达是德里 NCR 的一个城市。这就是 Zee 数据中心所在的位置。

最后……

所以到目前为止，我们已经看到了解决方案的各个方面。当所有内容都合并到一个架构文档中时，它看起来如何？