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部分中，我們將討論在開發實時視頻攝取服務時遇到的主要挑戰以及每種挑戰的解決方案。

總結

以上是生活随笔為你收集整理的Hulu直播服务难点解析（二）：系统设计与实现的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。