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

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

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

需要一個強大、靈活的系統

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

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

時間戳對齊和精度

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

自動結束廣告中斷

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

時間戳的完整性

有時，我們會看到帶有時間戳的媒體播放列表引用過去或將來的媒體文件。為了確保我們只處理實時視頻，在系統攝取之前我們驗證輸入的播放列表和媒體是否在一個頻道的合理的當前時間戳窗口內。

構建最好的系統：微調，微調，微調

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

最短分片時長

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

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

分片發布超時

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

發布偏移

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

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

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

供應商網絡連接

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

S3文件操作

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

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

結論

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