Hulu在其博客发布了建立直播服务遇到的挑战及解决方案，这对于以前只提供点播服务的系统而言是一次彻底的升级。LiveVideoStack对原文进行了摘译。本文是系列文章的第二篇，第一篇见这里。
文 / Allison Deal
译 / 许海燕
原文：https://medium.com/hulu-tech-blog/the-challenges-of-live-linear-video-ingest-part-two-system-design-and-implementation-ca0e387a3cbe
在本系列的第一部分中，我们讨论了用于直播电视的视频摄取系统的工程和设计需求。回顾一下，我们现有的视频传输途径无法支持实时视频摄取，因此当我们构建一个用于实时视频摄取的新系统时，我们将其设计为灵活，可靠且对我们的观众来说表现良好的。
如何运作
Hulu与那些为我们提供HLS流的供应商合作，这些供应商向我们提供已经分片并转码为多个流，每个视频流组提供不同的视频或音频质量。
这些分片流通过HLS提供给我们，HLS是我们所有供应商都能够支持的协议。
主播放列表
供应商首先使用主播放列表初始化频道，该播放列表描述了接下来将遵循的各种媒体播放列表; 每个视频流组将有一个媒体播放列表。
Master Playlist主播放列表
每个视频流组包含相同的内容，但视频或音频质量不同，允许播放器根据客户端的功能和连接速度选择最适合的组合。所列出的媒体播放列表的数量因网络和供应商而异，范围在4到8个之间。
一个节目代表了许多小的音频/视频文件，每个文件的长度大约为4秒。连续播放这些4秒的片段可以创建一个连续的视频流。
媒体分片
在发送主播放列表后，供应商将包含H.264视频和压缩音频的未加密、多路复用的MPEG-TS文件发布到Hulu的摄取服务。
在Hulu摄取服务接收每个MPEG-TS段时，该文件是：
解析视频元数据，该元数据暂时存储在Amazon ElastiCache的Redis服务中。之后这些元数据将被永久存储并用于视频播放给用户。
存储在Amazon S3中。这些原始的未加密文件不会提供给用户，而是暂时保存以供调试使用
用于生成AES-CTR加密的fMP4文件副本，并应用于PlayReady / Widevine DRM。生成的音频和视频fMP4以及init文件存储在S3中的临时位置。
用于生成AES-CBC加密的MPEG-TS文件副本，并应用于FairPlay DRM。该副本也存储在S3中的临时位置。
在收到每个媒体文件之前，我们甚至知道它属于哪个频道或节目，这样就可以处理每个媒体文件，从而允许Hulu以最小的延迟向用户提供视频。
媒体播放列表
在媒体片段之后，接收HLS媒体播放列表（先前在主播放列表中定义），其中列出了已经发布给我们的对于给定节目的最近视频片段。我们的系统现在拥有关于它所接收的每个视频片段的信息：每个先前处理的媒体文件与之相关联的频道和节目，以及在流中播放每个视频片段的顺序。
媒体播放列表使用滚动窗口仅保留上下文中的最新片段。此处，当VIDEO_1_E.ts可用时，VIDEO_1_A.ts会从播放列表的顶部滚降。
将服务将之前收到的所有这些单独的片段与媒体播放列表中列出的文件关联起来，一旦确认收到这些片段，它们就会从S3中的临时存储位置移动到永久存储位置，这个位置是用作分发源。所有主播放列表和媒体播放列表位置、媒体段元数据、频道配置和SCTE-35消息都永久存储在Amazon Aurora MySQL集群中。
HLS媒体播放列表还包含SCTE-35广告和节目消息，它们在HLS媒体播放列表的＃EXT-X-DATERANGE标记中显示。这些消息通过base64或十六进制编码到达，经过解析，存储在清单生成期间供以后访问，并与Hulu元数据服务共享以确定程序扩展。
实现
Hulu的摄取服务API层是用Go编写的。视频操作，包括remux版视频，SCTE-35事件消息解析，以及添加用C语言编写的Nielsen水印ID3标签，这些标签使用cgo进行了简化。为了简化开发和提高性能，我们选择使用Go和C的这种组合。这个Go应用程序在Donki的AWS上运行，这是Hulu用于托管Web应用程序的内部平台。使用Donki，当Hulu的直播电视节目中添加新频道时，我们可以根据需要轻松地扩展和添加其他的Amazon EC2后端。这些服务器都能够处理任何频道的播放列表和视频文件，从而简化了扩展和故障转移。
在设计我们的系统时，一个主要问题是包含所有播放列表和段信息的永久数据存储的大小和增长率。对于每个频道，大约每四秒钟需要添加每个节目的新媒体播放列表和片段元数据，因为每个视频片段的长度决定了接收传入片段的速率。我们的设计构造了这些信息，以便在Amazon Aurora MySQL集群中为每个频道分配自己的数据库。
这样做是可行的，因为每个频道都是独立处理的，而不依赖于其他频道的元数据。我们还发现，在数据库出现故障的情况下，最好使用单独的数据库来防止多个频道的广泛中断。摄取应用程序EC2后端和MySQL集群都分布在多个可用区域中，以确保资源始终可用。每个AWS区域都具有多个可用区域，以保护数据持久性和服务可用性。
为了使服务更具容错性，系统利用配置切换，允许它忽略频道级别的视频或元数据。如果一个频道包含增加系统延迟的视频或元数据，则可以立即忽略它以防止其他频道上的摄取延迟。围绕分段发布超时、视频元数据精确度和跨节目的段同步的其他特定于供应商和频道的配置允许系统在更细粒度级别上优化流程。
为了进一步提高可用性，我们的系统会为每个频道选取多个不同的供应商源，以便在主流中断的情况下为用户提供备份流。
结论
我们的实时媒体摄取服务旨在提供高可用性，减少延迟，为观众提供最佳体验，同时确保我们可以在未来扩展和添加新功能。但是，我们的系统会受到不一致的输入和条件的影响，在本系列文章的第3部分中，我们将讨论在开发实时视频摄取服务时遇到的主要挑战以及每种挑战的解决方案。
