重塑和改善直播 OTT 体验

提供高质量的 OTT 直播体验一直是一个有趣的挑战。作为最终用户，我一直渴望获得一流的直播体验，其中包括以下几点：

除此之外，作为 OTT 解决方案提供商，我们始终需要注意随着用户群的增长而不断增加的CDN成本！

因此，我们的要求似乎需要相互矛盾的解决方案，例如：

减少频道切换时间的一种方法是从最低比特率段开始，以减少初始缓冲延迟，然后以自适应性（根据用户的网络速度）方式逐步提高质量。然而，这将导致频道调整后的音频质量很差（尤其是当用户在更大的屏幕上观看内容时，这是不可接受的）！
减少频道切换时间的另一种常用技术是缩短片段持续时间。然而，这将使播放容易出现频繁缓冲！
同样，减少片段大小会改善 OTT 播放的延迟（相对于卫星广播），这使得播放容易出现频繁缓冲！
要控制 CDN 成本，一个显而易见的解决方案是降低编码比特率。然而，这将对用户的视听体验产生不利影响。
增加片段持续时间将改善缓冲并使编码更有效（从而减少带宽），但会增加延迟（相对于卫星广播）和调谐到频道的时间。

看了这么多还不明白吗？

最近在 Zee5，我们采取了一项举措来改善我们应用程序上的 OTT 用户直播体验。以下部分描述了在 OTT 内容编码/包装方面所做的改变，以及这些改变如何显著改善了用户体验。

用户体验的改善是显而易见的，但在本文中，我们将根据从 Conviva 收集到的相关矩阵来描述其优势。

我们尚未在我们的平台上引入低延迟直播。低延迟直播的使用超出了本文档的范围。

使用的技术

对于任何 Live OTT 解决方案来说，这是最重要的事情之一。经过多次迭代后，我们将所有通道的分段大小锁定为 4 秒。

在减少重新缓冲方面，我们看到了非常好的效果，但这并不会对延迟（相对于广播）和频道调整时间产生不利影响！

在 Zee5 中，直播 OTT 内容始终使用 HLS TS 格式向所有设备提供。我们有意识地做出的决定之一是尽可能从 HLS TS 迁移到 HLS CMAF，原因如下：

CMAF (fMp4) 本质上作为容器格式，确保有关 AV 内容的元数据是集中的，并且通常不包含在段中（以 init 段的形式），因此不会浪费带宽。另外，TS包的打包也会造成带宽的浪费。
Apple 强制要求 HEVC 只能在 HLS CMAF 上承载（不能在 HLS TS 上承载）。因此，4K（4K 的 AVC 编码在带宽方面极其昂贵）可以通过 4K 上的 HEVC 编码来服务。
低延迟解决方案大多可通过 CMAF 上的规范获得。
所有播放器/设备都广泛支持 HLS CMAF。

如今，Zee5 上超过 80% 的直播频道都是通过 HLS CMAF 提供的。

优化的下一个也是最重要的方面是微调编码器参数。我们主要微调了以下参数：

这些变化使所有频道中生成的变体的比特率发生了重大变化（更多内容请参见 “结果 “部分），但绝对不会造成视听体验上的感知损失！

对于直播，与来自诺伊达（新德里附近的城市）数据中心的直播频道相关的生成的 ABR 变体通过 MPLS 推送到 AWS 孟买数据中心，然后通过 Direct Connect 进入 AWS 云。请参阅下面的 Cloudwatch 图表，该图表描述了 Direct Connect 端带宽使用量的下降。

可以看出，平均使用率从 500 Mbps 下降到 370 Mbps 左右，带宽减少了约 25%。

下图中 MPLS 合作伙伴的指标也可以看到同样的情况。

我们使用 Conviva Metrics 衡量最终用户体验的改进。我们关注的一些清晰描述最终用户体验的指标是：

下表描述了上述关键参数的改进（我们从5月最后一周开始进行更改 ，并于6月中旬结束）。