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