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

如果您剛剛加入我們，在看我們的最后一篇文章之前請看看我們的直播視頻攝取文章系列的第一部分和第二部分。在第一部分中，我們討論了實(shí)時視頻攝取系統(tǒng)的挑戰(zhàn)和設(shè)計(jì)需求，并在第二部分中概述了我們?nèi)绾螛?gòu)建該系統(tǒng)。在本系列的最后一篇文章中，我們將詳細(xì)介紹在構(gòu)建實(shí)時視頻攝取服務(wù)時遇到的最具挑戰(zhàn)性的問題。

與大多數(shù)面向消費(fèi)者的系統(tǒng)不同，由于視頻播放列表和片段發(fā)布的一致性，我們的實(shí)時視頻攝取服務(wù)具有穩(wěn)定且可預(yù)測的請求率。具體來說，我們的目標(biāo)是提供最高可用性的直播流服務(wù)，使觀眾可以在其帶寬可用時觀看最高質(zhì)量的視頻。下面是我們發(fā)現(xiàn)并緩解的一些具體挑戰(zhàn)，以減少我們客戶端播放卡頓和播放錯誤。

需要一個強(qiáng)大、靈活的系統(tǒng)

如果您一直關(guān)注我們之前的文章，您就知道我們與多家供應(yīng)商合作，這些供應(yīng)商為我們提供了來自多個網(wǎng)絡(luò)的編碼流。由于這個過程涉及許多來源和參與者，因此我們收到的視頻文件和元數(shù)據(jù)在流到達(dá)Hulu之前通常會以各種方式進(jìn)行更改。我們遵循多個行業(yè)標(biāo)準(zhǔn)來確保系統(tǒng)是以規(guī)范、一致的方式接受輸入。但是，這些規(guī)范通常由各方以不同的方式實(shí)現(xiàn)。

為了優(yōu)化每個輸入集的服務(wù)，我們開發(fā)了獨(dú)特的配置。我們可以在每個頻道，每個提供者或每個供應(yīng)商的基礎(chǔ)上自動或手動應(yīng)用這些配置。這些配置允許我們根據(jù)任何給定流或流集的特性校準(zhǔn)處理并指定錯誤閾值。

時間戳對齊和精度

攝取系統(tǒng)的一個重要功能是識別包含相同視頻的不同節(jié)目。該系統(tǒng)最初錯誤地假設(shè)所有掛鐘時間戳將在比特率階梯上為相同的內(nèi)容對齊，這對于客戶端在質(zhì)量之間平滑切換是必要的。為了緩解這個問題，我們添加了一個配置來控制時間戳精度。在某些情況下，這可以設(shè)置為十分之一秒，以便正確對齊視頻片段的質(zhì)量。在其他情況下，應(yīng)用單獨(dú)的配置，使得這些節(jié)目組由公共視頻PTS（描述時間戳）值標(biāo)識。

自動結(jié)束廣告中斷

SCTE-35標(biāo)記用于指示ad-pods和程序的開始和結(jié)束時間。插入元數(shù)據(jù)的硬件和系統(tǒng)最初是為數(shù)字電視和有線電視設(shè)計(jì)的。SCTE-35規(guī)范詳細(xì)說明了這些消息的發(fā)送方式，多年來已經(jīng)發(fā)展并擴(kuò)展了其范圍，但工作流程中的數(shù)字系統(tǒng)并不總是能夠與最新版本保持同步。不同的供應(yīng)商通常以不兼容或不可互操作的方式解釋規(guī)范。SCTE-35規(guī)范詳細(xì)說明了用于OTT兼容性的內(nèi)容元數(shù)據(jù)轉(zhuǎn)換，它包含非常寬松的定義，每個頻道或提供商通常以不同方式實(shí)現(xiàn)這些定義。這些標(biāo)記由每個電視臺生成，并且在到達(dá)Hulu之前通過每個提供者和供應(yīng)商時進(jìn)行修改。有時候，廣告開始標(biāo)記可能表示廣告持續(xù)時間不準(zhǔn)確，而且有時Hulu根本不會收到廣告結(jié)束標(biāo)記。為了防止用戶在發(fā)送不準(zhǔn)確的標(biāo)記時出現(xiàn)無休止的廣告狀態(tài)，Hulu攝取系統(tǒng)會自動結(jié)束廣告，并在一段可配置的時間后將用戶重新置于程序中。系統(tǒng)的廣告時間軸邏輯簡單地記錄了任何延遲的提示（廣告結(jié)束）事件，以便之后優(yōu)化頻道的超時限制。

時間戳的完整性

有時，我們會看到帶有時間戳的媒體播放列表引用過去或?qū)淼拿襟w文件。為了確保我們只處理實(shí)時視頻，在系統(tǒng)攝取之前我們驗(yàn)證輸入的播放列表和媒體是否在一個頻道的合理的當(dāng)前時間戳窗口內(nèi)。

構(gòu)建最好的系統(tǒng)：微調(diào)，微調(diào)，微調(diào)

我們系統(tǒng)的每個組件都需要經(jīng)過細(xì)微地調(diào)整和優(yōu)化來減少延遲和錯誤。視頻處理很復(fù)雜，一個看似很小的錯誤或延遲可能導(dǎo)致流被錯誤地?cái)z取或不及時處理，導(dǎo)致無法實(shí)時播放。

最短分片時長

視頻片段由編碼器以4秒的常規(guī)節(jié)奏進(jìn)行分割。然而，當(dāng)節(jié)目和廣告之間的內(nèi)容轉(zhuǎn)換時，無論持續(xù)時間如何，這些片段都會被縮短，以便媒體片段僅包含廣告或節(jié)目內(nèi)容。這是必要的，以便我們可以動態(tài)地使用相關(guān)的新的廣告替換原來的廣告播放給每個觀眾。連續(xù)廣告標(biāo)記出現(xiàn)在非常接近的地方，這導(dǎo)致了在一行中出現(xiàn)多個秒級的片段。通常，傳輸和處理每個段所花費(fèi)的時間比段的持續(xù)時間長，從而導(dǎo)致用戶的重新緩沖和較差的播放質(zhì)量。為了緩解這個問題，我們與視頻編碼供應(yīng)商合作，將連續(xù)的廣告標(biāo)記組合在一起，以確保最短的片段持續(xù)時間為0.5秒。

卡頓事件隨著時間的推移進(jìn)行計(jì)數(shù)。最小段持續(xù)時間更改在21:00之后啟用。

分片發(fā)布超時

編碼供應(yīng)商首先嘗試將媒體文件發(fā)布到Hulu的攝取服務(wù)，然后是相應(yīng)的媒體播放列表。在媒體無法在一定時間內(nèi)發(fā)布的情況下，媒體播放列表將包含不連續(xù)性信息來表示該段丟失，并且在視頻播放期間它將不可用于終端用戶。通過與供應(yīng)商合作，將不同的最小分片發(fā)布超時設(shè)置在段持續(xù)時間的150%(對于較長的段)和段持續(xù)時間的250%(對于較短段)之間，我們系統(tǒng)中缺失的分片便減少了52%。這與以前的配置相比，使用的最小超時相當(dāng)于全部段持續(xù)時間的150％。

發(fā)布偏移

當(dāng)我們的打包服務(wù)檢測到一個頻道上有大量缺失的分片時，在系統(tǒng)放棄該段轉(zhuǎn)向攝取較新的視頻之前，我們會更改配置以增加等待分片從編碼供應(yīng)商到達(dá)系統(tǒng)的時間。此等待時間的增加將導(dǎo)致用戶端的延遲更大，但是丟失的分片越少用戶將擁有越連續(xù)的播放體驗(yàn)，因此我們僅在最有問題的頻道上啟用這種偏移。減少這種發(fā)布延遲會導(dǎo)致更多段丟失，但客戶能觀看到更實(shí)時的內(nèi)容。通過分析缺失的分片指標(biāo)，我們發(fā)現(xiàn)將等待持續(xù)時間設(shè)置為段長度的100％會使缺失分片的頻率減少63％。

更好的媒體文件傳輸技巧：私有供應(yīng)商連接和優(yōu)化Amazon S3

另一個主要挑戰(zhàn)是在攝取過程中加快媒體文件的傳輸時間。

供應(yīng)商網(wǎng)絡(luò)連接

Hulu的編碼供應(yīng)商位于美國各地。我們注意到，將媒體文件從海岸另一端的供應(yīng)商傳輸?shù)轿覀兊臄z取服務(wù)的性能并不是我們想要的，利用公共互聯(lián)網(wǎng)連接，這會導(dǎo)致延遲和不可預(yù)測的性能。為了克服這一挑戰(zhàn)，我們與供應(yīng)商密切合作，設(shè)置AWS Direct Connect，并在供應(yīng)商的發(fā)布平臺和Hulu的攝取服務(wù)之間建立私人連接。這繞過了公共互聯(lián)網(wǎng)，從而實(shí)現(xiàn)了更快、更一致的文件傳輸速度。

S3文件操作

我們的服務(wù)使用S3來臨時和永久地存儲播放列表和視頻片段。我們發(fā)現(xiàn)零星的S3文件操作時間是實(shí)現(xiàn)一致的用戶播放質(zhì)量的挑戰(zhàn)。S3上傳和復(fù)制操作處理起來至關(guān)重要，因?yàn)槿绻粋€視頻無法及時保存或轉(zhuǎn)移到正確的位置，那么終端用戶將無法播放該視頻并導(dǎo)致播放中斷。為了消除偶發(fā)的操作時間，我們不斷分析指標(biāo)，以根據(jù)每個文件的大小確定每個文件的當(dāng)前預(yù)期的中值時間。一旦之前的文件發(fā)布時間超過此預(yù)期時間，發(fā)布操作將立即取消并重試發(fā)布服務(wù)。這種實(shí)現(xiàn)方式將S3的低性能操作時間提高了35％，幾乎消除了所有播放質(zhì)量下降的情況。

最慢的1％發(fā)布操作時間（毫秒）。重試功能在15:00之前啟用。

結(jié)論

雖然我們在處理多個輸入源和連接時遇到了各種新挑戰(zhàn)，但在很多情況下，我們能夠識別并減輕原始實(shí)現(xiàn)中的問題，以滿足我們的初始需求并改進(jìn)我們的視頻攝取頻道?？偟膩碚f，我們的設(shè)計(jì)足以支持我們最初的直播電視發(fā)布，但是我們正在不斷地改進(jìn)和添加新功能，為觀眾提供更好的播放體驗(yàn)。