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

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

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

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

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

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

時間戳對齊和精度

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

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

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

時間戳的完整性

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

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

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

最短分片時長

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

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

分片發(fā)布超時

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

發(fā)布偏移

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

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

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

供應商網(wǎng)絡連接

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

S3文件操作

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

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

結(jié)論

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