在构建实时视频摄取服务时遇到的最具挑战性的问题

Hulu在其博客发布了建立直播服务遇到的挑战及解决方案，这对于以前只提供点播服务的系统而言是一次彻底的升级。LiveVideoStack对原文进行了摘译。本文是系列文章的第三篇，访问第二篇和第一篇。

如果您刚刚加入我们，在看我们的最后一篇文章之前请看看我们的直播视频摄取文章系列的第一部分和第二部分。在第一部分中，我们讨论了实时视频摄取系统的挑战和设计需求，并在第二部分中概述了我们如何构建该系统。在本系列的最后一篇文章中，我们将详细介绍在构建实时视频摄取服务时遇到的最具挑战性的问题。

与大多数面向消费者的系统不同，由于视频播放列表和片段发布的一致性，我们的实时视频摄取服务具有稳定且可预测的请求率。具体来说，我们的目标是提供最高可用性的直播流服务，使观众可以在其带宽可用时观看最高质量的视频。下面是我们发现并缓解的一些具体挑战，以减少我们客户端播放卡顿和播放错误。

需要一个强大、灵活的系统

如果您一直关注我们之前的文章，您就知道我们与多家供应商合作，这些供应商为我们提供了来自多个网络的编码流。由于这个过程涉及许多来源和参与者，因此我们收到的视频文件和元数据在流到达Hulu之前通常会以各种方式进行更改。我们遵循多个行业标准来确保系统是以规范、一致的方式接受输入。但是，这些规范通常由各方以不同的方式实现。

为了优化每个输入集的服务，我们开发了独特的配置。我们可以在每个频道，每个提供者或每个供应商的基础上自动或手动应用这些配置。这些配置允许我们根据任何给定流或流集的特性校准处理并指定错误阈值。

时间戳对齐和精度

摄取系统的一个重要功能是识别包含相同视频的不同节目。该系统最初错误地假设所有挂钟时间戳将在比特率阶梯上为相同的内容对齐，这对于客户端在质量之间平滑切换是必要的。为了缓解这个问题，我们添加了一个配置来控制时间戳精度。在某些情况下，这可以设置为十分之一秒，以便正确对齐视频片段的质量。在其他情况下，应用单独的配置，使得这些节目组由公共视频PTS（描述时间戳）值标识。

自动结束广告中断

SCTE-35标记用于指示ad-pods和程序的开始和结束时间。插入元数据的硬件和系统最初是为数字电视和有线电视设计的。SCTE-35规范详细说明了这些消息的发送方式，多年来已经发展并扩展了其范围，但工作流程中的数字系统并不总是能够与最新版本保持同步。不同的供应商通常以不兼容或不可互操作的方式解释规范。SCTE-35规范详细说明了用于OTT兼容性的内容元数据转换，它包含非常宽松的定义，每个频道或提供商通常以不同方式实现这些定义。这些标记由每个电视台生成，并且在到达Hulu之前通过每个提供者和供应商时进行修改。有时候，广告开始标记可能表示广告持续时间不准确，而且有时Hulu根本不会收到广告结束标记。为了防止用户在发送不准确的标记时出现无休止的广告状态，Hulu摄取系统会自动结束广告，并在一段可配置的时间后将用户重新置于程序中。系统的广告时间轴逻辑简单地记录了任何延迟的提示（广告结束）事件，以便之后优化频道的超时限制。

时间戳的完整性

有时，我们会看到带有时间戳的媒体播放列表引用过去或将来的媒体文件。为了确保我们只处理实时视频，在系统摄取之前我们验证输入的播放列表和媒体是否在一个频道的合理的当前时间戳窗口内。

构建最好的系统：微调，微调，微调

我们系统的每个组件都需要经过细微地调整和优化来减少延迟和错误。视频处理很复杂，一个看似很小的错误或延迟可能导致流被错误地摄取或不及时处理，导致无法实时播放。

最短分片时长

视频片段由编码器以4秒的常规节奏进行分割。然而，当节目和广告之间的内容转换时，无论持续时间如何，这些片段都会被缩短，以便媒体片段仅包含广告或节目内容。这是必要的，以便我们可以动态地使用相关的新的广告替换原来的广告播放给每个观众。连续广告标记出现在非常接近的地方，这导致了在一行中出现多个秒级的片段。通常，传输和处理每个段所花费的时间比段的持续时间长，从而导致用户的重新缓冲和较差的播放质量。为了缓解这个问题，我们与视频编码供应商合作，将连续的广告标记组合在一起，以确保最短的片段持续时间为0.5秒。

卡顿事件随着时间的推移进行计数。最小段持续时间更改在21:00之后启用。

分片发布超时

编码供应商首先尝试将媒体文件发布到Hulu的摄取服务，然后是相应的媒体播放列表。在媒体无法在一定时间内发布的情况下，媒体播放列表将包含不连续性信息来表示该段丢失，并且在视频播放期间它将不可用于终端用户。通过与供应商合作，将不同的最小分片发布超时设置在段持续时间的150%(对于较长的段)和段持续时间的250%(对于较短段)之间，我们系统中缺失的分片便减少了52%。这与以前的配置相比，使用的最小超时相当于全部段持续时间的150％。

发布偏移

当我们的打包服务检测到一个频道上有大量缺失的分片时，在系统放弃该段转向摄取较新的视频之前，我们会更改配置以增加等待分片从编码供应商到达系统的时间。此等待时间的增加将导致用户端的延迟更大，但是丢失的分片越少用户将拥有越连续的播放体验，因此我们仅在最有问题的频道上启用这种偏移。减少这种发布延迟会导致更多段丢失，但客户能观看到更实时的内容。通过分析缺失的分片指标，我们发现将等待持续时间设置为段长度的100％会使缺失分片的频率减少63％。

更好的媒体文件传输技巧：私有供应商连接和优化Amazon S3

另一个主要挑战是在摄取过程中加快媒体文件的传输时间。

供应商网络连接

Hulu的编码供应商位于美国各地。我们注意到，将媒体文件从海岸另一端的供应商传输到我们的摄取服务的性能并不是我们想要的，利用公共互联网连接，这会导致延迟和不可预测的性能。为了克服这一挑战，我们与供应商密切合作，设置AWS Direct Connect，并在供应商的发布平台和Hulu的摄取服务之间建立私人连接。这绕过了公共互联网，从而实现了更快、更一致的文件传输速度。

S3文件操作

我们的服务使用S3来临时和永久地存储播放列表和视频片段。我们发现零星的S3文件操作时间是实现一致的用户播放质量的挑战。S3上传和复制操作处理起来至关重要，因为如果一个视频无法及时保存或转移到正确的位置，那么终端用户将无法播放该视频并导致播放中断。为了消除偶发的操作时间，我们不断分析指标，以根据每个文件的大小确定每个文件的当前预期的中值时间。一旦之前的文件发布时间超过此预期时间，发布操作将立即取消并重试发布服务。这种实现方式将S3的低性能操作时间提高了35％，几乎消除了所有播放质量下降的情况。

最慢的1％发布操作时间（毫秒）。重试功能在15:00之前启用。

结论

虽然我们在处理多个输入源和连接时遇到了各种新挑战，但在很多情况下，我们能够识别并减轻原始实现中的问题，以满足我们的初始需求并改进我们的视频摄取频道。总的来说，我们的设计足以支持我们最初的直播电视发布，但是我们正在不断地改进和添加新功能，为观众提供更好的播放体验。