Hulu直播服务难点解析（一）：系统需求

640?wx_fmt=jpeg

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

文 / Allison Deal

译 / 许海燕

原文：https://medium.com/hulu-tech-blog/the-anatomy-of-a-live-ott-service-c8f6078b24d3

https://medium.com/hulu-tech-blog/the-challenges-of-live-linear-video-ingest-part-one-live-versus-on-demand-system-requirements-89238f3af4f6

“Anatomy”系列是一组视觉效果，它展示了幕后OTT电视的系统功能。

我们可以看到电视在几十年里最重大的转变：观众可以在旅途中或任何设备上观看更多电视节目。流媒体的收视率持续上升，dMVPD正在建立新的系统和流程，以便通过互联网提供电视直播。

要把Hulu和Live TV一起带给我们的观众，这个幕后有很多工作要做。下面这张图展示了从我们的网络合作伙伴接收内容并将其发送到全国各地的观众设备上的复杂过程。

640?wx_fmt=png

在去年5月推出直播电视服务之前，Hulu向数百万的观众提供了点播内容，为他们提供了一个最大的内容库以及他们最喜欢的当季播出的节目。虽然我们的视频摄取系统对于SVOD来说并不简单，但添加直播电视后又再增加了一层复杂性，这就给Hulu的小规模但强大的视频团队带来了独特的挑战。

直播电视需要与SVOD截然不同的系统，我们的团队不得不使用一个全新的技术栈来启动直播服务。现有的SVOD系统也需要修改，这样我们就可以同时支持这两种产品。在这个系列的文章的第一部分中，我将高度概述在设计我们的实时视频摄取系统时我们所要考虑的主要挑战和需求。

建立一个SVOD直播系统

直播服务的需求与SVOD服务的需求有很大的不同，我们现有的点播视频和元数据摄取处理系统无法充分支持实时线性流的摄取，原因如下：

1、直播系统必须具有高可用性和弹性，因为从丢失的数据中恢复过来的灵活性很小。对于点播视频，内容通常在被发送给观众之前的数小时甚至数天内收到，如果我们遇到文件问题，我们就有时间要求内容合作伙伴修改或重新提交文件。这使我们有时间在平台提供内容之前解决内容的任何技术问题。但是，这种策略不适用于直播服务。

2、点播视频是在内容（事件）级别上摄取的，但是频道的线性流需要连续的24/7摄取。

3、点播元数据也是基于内容的，而直播流元数据是以频道和时间戳为导向的。一个节目的持续时间是针对视频点播内容预先设置的，并且不会改变，但直播节目具有灵活的节目界限，当长时间的体育赛事或突发新闻发生时，这些界限可能会发生变化。

除了应对这些挑战之外，我们还需要在构建新的摄取系统时满足一些需求和设计目标。

需求和设计目标

功能

我们的直播电视需要将视频传送到各种各样的设备上，这意味着该服务需要同时生成基于HTTP的动态自适应流媒体（MPEG-DASH）和Apple的HTTP直播流媒体（HLS）媒体格式。在较高的层次上，我们的系统必须从供应商处获取视频流，重新封装和打包成视频片段，并将它们发布到CDN的源站。除了视频工作流之外，该服务还需要能够处理从摄取的流中获得的广告和节目标记，以准确的开始和结束时间，以及识别广告部分来将直播内容作为节目（而不是简单地作为频道）呈现。

可靠性

我们的直播电视服务无论是有无计划的都不应该有任何停止播放的时候。视频播放对于观众来说应该是连续无缝的。

兼容性

我们的视频摄取系统需要与多个供应商和网络兼容，这些供应商和网络提供了来自全国各地的频道的视频内容。它需要适应供应商特定的编码输出，包括不同的段长度，段命名方案以及不同的分辨率和码率。

安全性

内容保护对于MPEG-DASH和HLS格式都至关重要。我们的实时摄取服务需要使用基于MPEG公共加密（CENC）规范的AES-128加密媒体片段，将它们打包为fMP4和MPEG-TS文件格式，并在所有流格式中应用商业DRM。

容错性

这个系统需要具有容错能力，以至于一个频道的播放卡顿或者其他问题不会影响任何其他频道的摄取从而影响我们观众的体验

性能

为了向观众提供实时体验，系统必须具有高性能并且要在平均每个片段播放给观众所花费的时间内处理每个片段，以避免大量的作业队列。

可伸缩性

系统必须能够扩展到能同时处理数千个频道，以便当我们的内容合作伙伴的数量增长时，系统可以处理其他频道。