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

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

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

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

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

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

時(shí)間戳對(duì)齊和精度

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

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

SCTE-35標(biāo)記用于指示ad-pods和程序的開始和結(jié)束時(shí)間。插入元數(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)換，它包含非常寬松的定義，每個(gè)頻道或提供商通常以不同方式實(shí)現(xiàn)這些定義。這些標(biāo)記由每個(gè)電視臺(tái)生成，并且在到達(dá)Hulu之前通過每個(gè)提供者和供應(yīng)商時(shí)進(jìn)行修改。有時(shí)候，廣告開始標(biāo)記可能表示廣告持續(xù)時(shí)間不準(zhǔn)確，而且有時(shí)Hulu根本不會(huì)收到廣告結(jié)束標(biāo)記。為了防止用戶在發(fā)送不準(zhǔn)確的標(biāo)記時(shí)出現(xiàn)無休止的廣告狀態(tài)，Hulu攝取系統(tǒng)會(huì)自動(dòng)結(jié)束廣告，并在一段可配置的時(shí)間后將用戶重新置于程序中。系統(tǒng)的廣告時(shí)間軸邏輯簡(jiǎn)單地記錄了任何延遲的提示（廣告結(jié)束）事件，以便之后優(yōu)化頻道的超時(shí)限制。

時(shí)間戳的完整性

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

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

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

最短分片時(shí)長(zhǎng)

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

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

分片發(fā)布超時(shí)

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

發(fā)布偏移

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

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

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

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

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

S3文件操作

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

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

結(jié)論

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