隨着廣告資金和觀眾不斷從傳統電視轉移到現在，內容所有者和廣播公司正在尋求支持廣告的直播活動流媒體，以吸引新的觀眾並通過OTT (OTT)流媒體增加收入。 OTT提供了新的發布機會，使出版商能夠播放以前在廣播電視上沒有位置的許可內容並將其盈利。 但在發行商開始串流直播事件之前，必須先考慮串流視訊工作流程第一步的技術障礙：
- 地點和攝取點之間的連接質量和帶寬可用性可能是工作流中的薄弱環節。 必須內置冗餘和可靠性。
- 實時源必須編碼為各種自適應比特率格式和協議，如Apple HLS和MPEG-DASH，同時最大程度地減少延遲。
- 上傳和編碼解決方案必須面向未來，可靠且可擴展，以應對4K和其他高質量格式的出現。
- 影片工作流應能夠支援伺服器端廣告插入，以獲得最佳的觀眾體驗和最適時的營利策略。
在這篇技術部落格中，我們將了解我們如何構建平臺，使出版商能夠優化流影片工作流的第一步，了解其中涉及的一些挑戰，並解釋我們如何編碼直播流以實現高性能，低延遲，支援廣告的直播流。
Background：切片器
在我們深入探討編碼的技術考量之前，我們需要先說明我們的技術，稱為「切片器」。 Slicer是一個功能強大的軟體客戶端，它將您的場地的實時流傳輸到我們的雲影片平臺。 它簡化了極其復雜的任務，而不會犧牲靈活性和功能。 Slicer是擁有廣泛技術資源和沒有資源的廣播公司能夠利用我們的平臺創建強大差異化OTT體驗的關鍵原因。
切片器會準備內容進行編碼，計算理想的編碼設定，並管理廣告插入標記。 您可以在安全硬體上執行Slicer，也可以選擇雲無關位置的成本節省和可擴展性，支援各種格式，包括SDI，IP影片，RTP/FEC和RTMP。
Slicer會將您的內容分成小塊，並在將內容發送到我們的ISO認證雲編碼堆棧之前對其進行加密，讓您放心，因為您知道內容始終是安全的。 它提供了一系列靈活的工作流，從簡單的一鍵配置到選擇的程式語言中更高級的腳本，再到編寫雲功能以觸發通知，作業處理和機器學習集成的工作流。
我們的“實時切片器”是切片器的一種版本，針對直播事件流進行了優化。 HD-SDI或基於IP的饋送可快速攝取，並以所需的最高比特率分塊為2秒或4秒的加密段，將1080p的帶寬要求降低到3–5 Mbps，4K的帶寬要求約為15 Mbps。 我們的流程會自動保留帶內和帶外元數據和消息，以觸發計劃和廣告中斷或替換內容。 我們的插件架構允許您創建自定義腳本，以處理您獨特的信令事件要求。 即時切片器也可以聆聽SCTE 35 / 104訊息，或接收API呼叫，以插入廣告中斷，內容開始或中斷觸發。
OTT流是通過實時線性源生成的，前期投資最少，帶寬要求低。
最小化帶寬
既然您已經了解了標準，您可能會想知道為什麼我們要開發前端軟體組件，將直播流從活動轉移到雲。 例如，為什麼發布者不能通過RTMP (實時消息協議)流發送？ (如果您願意，您可以這樣做，但我們的大多數客戶都會利用切片器。)答案與消費者對高品質直播流的期望相同，與應對現場場地的帶寬挑戰同樣相關。 這是在許多競爭因素之間找到適當平衡的問題。 一方面，您需要盡可能多地保留原始影片源，並著眼於更高質量的格式和4K。 另一方面，您需要優化流媒體，以便高效交付，而不會因額外開銷(如個性化廣告)而陷入困境。 在影片工作流程的這一步驟中，找到適當的平衡點至關重要。
以下是切片器至關重要的地方。 如上所述，它通過在站點上創建最高比特率配置文件並僅將該配置文件發送到雲來顯著降低給定源所需的帶寬。 根據我們的觀察(基於向全球數十億觀眾流式傳輸數百萬小時的直播影片)，向雲發送大量RTMP流的替代方法不會顯著提高觀看體驗的質量。 但它確實顯著增加了帶寬，從而增加了成本。
回程成本會迅速增加。 如果您的需求是這樣，您需要衛星上行鍊路，例如Ka波段卡車，每天租金約為2,000美元，帶寬約為每小時400美元。 考慮到某些場所(如酒店或會議中心，甚至全球的體育場館)的不一致和帶寬受限的情況，最重要的一點是，儘量降低上傳帶寬要求，同時確保向觀眾提供類似廣播的體驗，這始終是一個好主意。
編碼障礙
即時視訊饋送離開會場後，工作流程的下一步就是編碼。 在這裏，視頻編碼器以不同的比特率，分辨率和質量級別創建音頻和視頻的多個版本或變體。 然後將變體分成小文件或媒體段。 必須執行多個附加步驟，例如爲每個變體創建一個媒體播放列表，其中包含指向變體媒體段的URL列表。 生成的主播放列表是播放器選擇的最適合設備的變體以及當前測量的帶寬或可用帶寬。
兩種主要的影片流協議增加了復雜性，而其他協議可能需要支援以覆蓋大量潛在的播放設備。 HLS是Apple實施的基於HTTP的媒體流通信協議。 它支援所有Apple設備以及大多數Google，Android，Linux和Microsoft瀏攬器和設備。 大部分但不是全部。 您還需要MPEG-DASH，這是一種競爭的基於HTTP的媒體流協議。 您可能還需要添加對Microsoft Smooth Streaming for gaming console的支援。
DRM還需要自己的多種格式集來支援大量受眾要求，從而使編碼變得復雜。 例如，不支援DRM的較舊播放器需要HLS和128。 舊版iOS裝置需要HLS和FairPlay。 較新的iOS設備支援HLS和FairPlay以及CMAF CBC。 舊版Windows和Android僅支援CMAF CTR。 較新的Android，Windows和iOS應支援所有CMAF格式。 您的內容必須以多種格式打包，才能在所有設備上播放。
如果這聽起來很多編碼工作正常，您是對的。 隨著解析度的提高和編解碼器變得越來越復雜，在單臺計算機上編碼完整的ABR編碼梯子變得越來越困難，無論是在雲中還是在本地。 如果您的編碼硬體無法跟上實時源，您可能需要減少編碼梯級上的梯級數，這可能最終影響您的觀眾體驗。
為了跟上更復雜的編碼要求，傳統模式意味著生產商必須不斷投資新硬體以保持速度和質量。 最終，對於像Edgio (以前稱為Verizon Digital Media Services)這樣的流媒體服務，1:1流到編碼器模型無法提供滿足客戶期望所需的可靠性，靈活性和可擴展性。
相反，我們開發了一套精密的代理系統，允許使用我們需要的任意多個編碼器，所有編碼器都在基於雲的基礎設施中執行。 代理系統從切片器實例接收內容塊，並將其移至最優的編碼器。 此操作可防止編碼進程給特定計算機造成過重負擔，並使數據塊在系統中移動到存儲設備，然後再移到查看器。
仲介程序可無縫擴展我們的雲編碼器基礎架構，更重要的是，它可以自動擴展。
在我們的實施中，代理實例充當切片器和編碼器之間的管理器。 代理確保任何新的切片器都將其數據路由到正確的編碼器，並驗證編碼器是否可以處理工作負載。 此外，我們還擁有非常強大的擴展基礎設施。 如果我們突然被需要編碼的數百萬小時VOD內容傾倒，我們可以快速增加伺服器實例並開始處理內容。 我們也可以儘快縮減規模以節省資源。 此經紀人流程可無縫地管理我們的整個雲基礎設施，更重要的是，它可以自動管理。
無狀態編碼器
當然，如果仲介系統能夠做的只是將切片器指向單個編碼器，而該編碼器可能也可能無法跟上直播流的需求，則仲介系統的價值將是有限的，這是4K的嚴重問題。 我們開發的解決方案涉及使用無狀態編碼器。 每個編碼器一次只接收一個2或4秒的視頻段，而不是將單個計算機用於整個流。 每個數據段都包含足夠的資訊來灌注編碼器，以便編碼器可以對該數據段進行編碼並丟棄任何不必要的資訊，例如導入和導出資訊。 此時，整個段已完成並準備就緒，釋放編碼器，以便開始對另一通道或其它任何內容的另一段內容進行編碼。
此型號的系統中還內置了大量冗餘。 例如，如果編碼器在處理數據段時崩潰，則同一數據段會在另一臺計算機上啓動，並在數據流中發現任何問題之前及時完成。
這種方法還允許使用更具成本效益的硬體。 例如，如果我們知道速度較慢的計算機可能需要8秒來處理來自交叉分析篩選器的4秒文件，則可以將工作負載分散到多個編碼器上，如下所示：服務器A獲得分片1，服務器B獲得分片2，依此類推。 然後，由於這些數據塊都在可預測的時間完成，因此沒有出現問題。 如下圖所示，此示例將導致延遲滯後16–20秒。
在雲中使用多個編碼器可最大程度地減少延遲，並允許使用無法跟上實時源的伺服器。
最終，雲中的伺服器數量(即使單個伺服器速度較慢)意味著編碼過程可以始終跟上實時需求。 如果您想要使用傳統模型設定編碼基礎架構，您需要投資購買昂貴的高性能機器或專業硬體，每臺機器都能夠處理整個傳入影片，無需實時幫助。 通過利用雲的可擴展性，我們顯著降低了編碼成本。
無狀態雲編碼的另一個優點是，我們可以輕鬆地將工作負載遷移到備用雲提供商，因為我們沒有專門的伺服器需求。 擁有250 Tbps以上容量的網路，多雲方法具有固有的優勢。
經濟高效的直播流媒體
對於直播內容製作商而言，準備雲端串流直播影片的技術考量，可能會造成難以克服的障礙。 您將面臨各種問題，從場地帶寬限制到與編碼器和流協議有關的複雜問題。 儘管這並不能消除場地上某些連接的需要，但簡化的工作流以及前端帶寬要求的降低可以顯著減少前期和持續支出，同時提供觀眾期望的高質量，低延遲流媒體。
