Hulu在其博客發(fā)布了建立直播服務(wù)遇到的挑戰(zhàn)及解決方案，這對(duì)于以前只提供點(diǎn)播服務(wù)的系統(tǒng)而言是一次徹底的升級(jí)。LiveVideoStack對(duì)原文進(jìn)行了摘譯。本文是系列文章的第二篇，第一篇見(jiàn)這里。

文 / Allison Deal

譯 / 許海燕

原文：https://medium.com/hulu-tech-blog/the-challenges-of-live-linear-video-ingest-part-two-system-design-and-implementation-ca0e387a3cbe

在本系列的第一部分中，我們討論了用于直播電視的視頻攝取系統(tǒng)的工程和設(shè)計(jì)需求。回顧一下，我們現(xiàn)有的視頻傳輸途徑無(wú)法支持實(shí)時(shí)視頻攝取，因此當(dāng)我們構(gòu)建一個(gè)用于實(shí)時(shí)視頻攝取的新系統(tǒng)時(shí)，我們將其設(shè)計(jì)為靈活，可靠且對(duì)我們的觀眾來(lái)說(shuō)表現(xiàn)良好的。

如何運(yùn)作

Hulu與那些為我們提供HLS流的供應(yīng)商合作，這些供應(yīng)商向我們提供已經(jīng)分片并轉(zhuǎn)碼為多個(gè)流，每個(gè)視頻流組提供不同的視頻或音頻質(zhì)量。

這些分片流通過(guò)HLS提供給我們，HLS是我們所有供應(yīng)商都能夠支持的協(xié)議。

主播放列表

供應(yīng)商首先使用主播放列表初始化頻道，該播放列表描述了接下來(lái)將遵循的各種媒體播放列表; 每個(gè)視頻流組將有一個(gè)媒體播放列表。

Master Playlist主播放列表

每個(gè)視頻流組包含相同的內(nèi)容，但視頻或音頻質(zhì)量不同，允許播放器根據(jù)客戶端的功能和連接速度選擇最適合的組合。所列出的媒體播放列表的數(shù)量因網(wǎng)絡(luò)和供應(yīng)商而異，范圍在4到8個(gè)之間。

一個(gè)節(jié)目代表了許多小的音頻/視頻文件，每個(gè)文件的長(zhǎng)度大約為4秒。連續(xù)播放這些4秒的片段可以創(chuàng)建一個(gè)連續(xù)的視頻流。

媒體分片

在發(fā)送主播放列表后，供應(yīng)商將包含H.264視頻和壓縮音頻的未加密、多路復(fù)用的MPEG-TS文件發(fā)布到Hulu的攝取服務(wù)。

在Hulu攝取服務(wù)接收每個(gè)MPEG-TS段時(shí)，該文件是：

解析視頻元數(shù)據(jù)，該元數(shù)據(jù)暫時(shí)存儲(chǔ)在Amazon ElastiCache的Redis服務(wù)中。之后這些元數(shù)據(jù)將被永久存儲(chǔ)并用于視頻播放給用戶。

存儲(chǔ)在Amazon S3中。這些原始的未加密文件不會(huì)提供給用戶，而是暫時(shí)保存以供調(diào)試使用

用于生成AES-CTR加密的fMP4文件副本，并應(yīng)用于PlayReady / Widevine DRM。生成的音頻和視頻fMP4以及init文件存儲(chǔ)在S3中的臨時(shí)位置。

用于生成AES-CBC加密的MPEG-TS文件副本，并應(yīng)用于FairPlay DRM。該副本也存儲(chǔ)在S3中的臨時(shí)位置。

在收到每個(gè)媒體文件之前，我們甚至知道它屬于哪個(gè)頻道或節(jié)目，這樣就可以處理每個(gè)媒體文件，從而允許Hulu以最小的延遲向用戶提供視頻。

媒體播放列表

在媒體片段之后，接收HLS媒體播放列表（先前在主播放列表中定義），其中列出了已經(jīng)發(fā)布給我們的對(duì)于給定節(jié)目的最近視頻片段。我們的系統(tǒng)現(xiàn)在擁有關(guān)于它所接收的每個(gè)視頻片段的信息：每個(gè)先前處理的媒體文件與之相關(guān)聯(lián)的頻道和節(jié)目，以及在流中播放每個(gè)視頻片段的順序。

媒體播放列表使用滾動(dòng)窗口僅保留上下文中的最新片段。此處，當(dāng)VIDEO_1_E.ts可用時(shí)，VIDEO_1_A.ts會(huì)從播放列表的頂部滾降。

將服務(wù)將之前收到的所有這些單獨(dú)的片段與媒體播放列表中列出的文件關(guān)聯(lián)起來(lái)，一旦確認(rèn)收到這些片段，它們就會(huì)從S3中的臨時(shí)存儲(chǔ)位置移動(dòng)到永久存儲(chǔ)位置，這個(gè)位置是用作分發(fā)源。所有主播放列表和媒體播放列表位置、媒體段元數(shù)據(jù)、頻道配置和SCTE-35消息都永久存儲(chǔ)在Amazon Aurora MySQL集群中。

HLS媒體播放列表還包含SCTE-35廣告和節(jié)目消息，它們?cè)贖LS媒體播放列表的＃EXT-X-DATERANGE標(biāo)記中顯示。這些消息通過(guò)base64或十六進(jìn)制編碼到達(dá)，經(jīng)過(guò)解析，存儲(chǔ)在清單生成期間供以后訪問(wèn)，并與Hulu元數(shù)據(jù)服務(wù)共享以確定程序擴(kuò)展。

實(shí)現(xiàn)

Hulu的攝取服務(wù)API層是用Go編寫(xiě)的。視頻操作，包括remux版視頻，SCTE-35事件消息解析，以及添加用C語(yǔ)言編寫(xiě)的Nielsen水印ID3標(biāo)簽，這些標(biāo)簽使用cgo進(jìn)行了簡(jiǎn)化。為了簡(jiǎn)化開(kāi)發(fā)和提高性能，我們選擇使用Go和C的這種組合。這個(gè)Go應(yīng)用程序在Donki的AWS上運(yùn)行，這是Hulu用于托管Web應(yīng)用程序的內(nèi)部平臺(tái)。使用Donki，當(dāng)Hulu的直播電視節(jié)目中添加新頻道時(shí)，我們可以根據(jù)需要輕松地?cái)U(kuò)展和添加其他的Amazon EC2后端。這些服務(wù)器都能夠處理任何頻道的播放列表和視頻文件，從而簡(jiǎn)化了擴(kuò)展和故障轉(zhuǎn)移。

在設(shè)計(jì)我們的系統(tǒng)時(shí)，一個(gè)主要問(wèn)題是包含所有播放列表和段信息的永久數(shù)據(jù)存儲(chǔ)的大小和增長(zhǎng)率。對(duì)于每個(gè)頻道，大約每四秒鐘需要添加每個(gè)節(jié)目的新媒體播放列表和片段元數(shù)據(jù)，因?yàn)槊總€(gè)視頻片段的長(zhǎng)度決定了接收傳入片段的速率。我們的設(shè)計(jì)構(gòu)造了這些信息，以便在Amazon Aurora MySQL集群中為每個(gè)頻道分配自己的數(shù)據(jù)庫(kù)。

這樣做是可行的，因?yàn)槊總€(gè)頻道都是獨(dú)立處理的，而不依賴于其他頻道的元數(shù)據(jù)。我們還發(fā)現(xiàn)，在數(shù)據(jù)庫(kù)出現(xiàn)故障的情況下，最好使用單獨(dú)的數(shù)據(jù)庫(kù)來(lái)防止多個(gè)頻道的廣泛中斷。攝取應(yīng)用程序EC2后端和MySQL集群都分布在多個(gè)可用區(qū)域中，以確保資源始終可用。每個(gè)AWS區(qū)域都具有多個(gè)可用區(qū)域，以保護(hù)數(shù)據(jù)持久性和服務(wù)可用性。

為了使服務(wù)更具容錯(cuò)性，系統(tǒng)利用配置切換，允許它忽略頻道級(jí)別的視頻或元數(shù)據(jù)。如果一個(gè)頻道包含增加系統(tǒng)延遲的視頻或元數(shù)據(jù)，則可以立即忽略它以防止其他頻道上的攝取延遲。圍繞分段發(fā)布超時(shí)、視頻元數(shù)據(jù)精確度和跨節(jié)目的段同步的其他特定于供應(yīng)商和頻道的配置允許系統(tǒng)在更細(xì)粒度級(jí)別上優(yōu)化流程。

為了進(jìn)一步提高可用性，我們的系統(tǒng)會(huì)為每個(gè)頻道選取多個(gè)不同的供應(yīng)商源，以便在主流中斷的情況下為用戶提供備份流。

結(jié)論

我們的實(shí)時(shí)媒體攝取服務(wù)旨在提供高可用性，減少延遲，為觀眾提供最佳體驗(yàn)，同時(shí)確保我們可以在未來(lái)擴(kuò)展和添加新功能。但是，我們的系統(tǒng)會(huì)受到不一致的輸入和條件的影響，在本系列文章的第3部分中，我們將討論在開(kāi)發(fā)實(shí)時(shí)視頻攝取服務(wù)時(shí)遇到的主要挑戰(zhàn)以及每種挑戰(zhàn)的解決方案。

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。