[譯] 2019 年低延遲直播技術展望

摘要： 低延遲視訊直播是2018年的熱門話題之一。本文通過多個實際用例詳細介紹了不同場景下，影響使用者體驗的延遲範圍，降低延遲的策略並探索可以為使用者提供最佳體驗的不斷髮展的技術。本文來自Mux部落格，LiveVideoStack進行了翻譯。感謝 Hulu Senior Dev Lead 傅...

低延遲視訊直播是2018年的熱門話題之一。本文通過多個實際用例詳細介紹了不同場景下，影響使用者體驗的延遲範圍，降低延遲的策略並探索可以為使用者提供最佳體驗的不斷髮展的技術。本文來自Mux部落格，LiveVideoStack進行了翻譯。感謝 Hulu Senior Dev Lead 傅德良提供的審校支援。

文 / Phil Cluff

譯 / 元寶

審校 / 傅德良

原文 

https://mux.com/blog/the-low-latency-live-streaming-landscape-in-2019/

在過去的2018年，良好效能的低延遲視訊直播一致成為NAB、IBC和Demuxed等公司努力的方向。接下來我們將藉助多個例項探討研究直播延遲如何影響使用者體驗，並探索能夠推動視訊直播產品進一步發展的新技術。

在深入研究視訊直播延遲之前，我們需要明確延遲的定義：我們可以把延遲理解為使用者觀看視訊直播時直播端呈現畫面與現實中主播端記錄下畫面並非同步所出現的時間線偏差。常見型別有端到端延遲、鏡頭-顯示屏延遲等

延遲在什麼時候很重要？

延遲的故事很複雜。延遲的可接受程度完全取決於您要解決的問題。我們將下面的一些用例放在一起，我們認為這些用例通常會對終端使用者感受到的延遲產生挑戰。

語音和實時通訊

基於實時通訊的應用場景更易受到延遲的影響，例如以個人視訊電話為例的一對一線上交流或以視訊會議為例的團隊線上溝通。

通常情況下對於實時通訊而言，200ms（0.2秒）的延遲就會為通訊體驗帶來明顯不良影響；而超過200ms的延遲會使實時通訊變得難以繼續進行，與此同時延遲不單單會為雙方交流的實時性帶來障礙，隨著延遲增加逐漸惡化的噪聲與回聲也使技術界對低延遲的研究越來越迫切。

當實時通訊的延遲高達一秒以上，使用者的實時交流就失去了存在的意義。因此業界在設計相關協議與技術指標時會通過適當降低畫面質量的方式做出一定妥協，從而確保能夠在極端環境下也能提供基本的實時通訊服務。

例子：

• FaceTime

• Google Meet / Hangouts

• Skype

體育和電子競技

體育賽事直播面臨的挑戰並非儘可能實現最低延遲，而是實現多端同步延遲。我們知道現在的大型體育賽事直播都是通過廣播電視網路與衛星通訊等傳統技術手段實現傳輸。對於許多廣播電視公司來說其目標在於讓身處不同傳輸鏈路（網際網路、廣播、有線電視、數字電視等）的所有使用者體驗到同步的延遲，一般延遲為2秒～15秒之間，廣播的平均延遲約為6秒。需要強調的是這種幾秒甚至幾十秒的延遲並非技術缺陷而是人為規定，其主要用於廣播電視的監管機構能夠在直播畫面製作完成到播出之間進行審查。

而對於那些關注度較高的大型體育賽事直播而言，其關鍵點在於實現兩種傳遞策略（網際網路與廣播電視）下的視訊直播畫面的延遲同步，從而能夠將視訊畫面同時呈現給不同端觀眾。例如在上屆世界盃，當英國隊進行點球大戰時你可以在不同時期聽到來自倫敦市中心不同酒吧派對的英格蘭球迷的歡呼聲，其原因便是在互倆網端BBC iPlayer上的超高清視訊流比有線電視晚播出20-30秒，這種不同播放渠道之間高達半分鐘的延遲對當時期待進球結果的球迷而言無疑是對比賽精彩懸念的毀滅，也會讓廣播電視公司的服務水平大打折扣。所以在英國，一般情況下週四晚通過網際網路視訊流在Twitch.tv上播出的球賽會比普通的有線電視廣播提前20秒左右播放。

電子競技面臨的延遲問題則更為有趣，與體育賽事直播不同是，電子競技直播一般不需要廣播電視等傳統媒體傳輸渠道實現視訊流傳輸，其對延遲的敏感程度也低於其他傳統體育賽事直播場景。隨著社交網路與新聞供應商不斷改善畫面延遲，觀眾對延遲的要求越來越高，相信沒有人願意在網際網路瀏覽視訊時被突然出現的延遲推送打擾。

例子：

• 體育：BBC iPlayer或Fubo.tv上的FIFA世界盃

• 電子競技：Twitch上的DOTA “The Internationals”

互動式體驗和互動式UGC流

隨著UGC直播文化的發展，我們可以很清晰地發現視訊直播所涉及的應用面不再侷限於體育產業與電子競技，而是拓展成為一個滲透生活多個方面的全方位流媒體平臺。與Twitch上的視訊產品普遍強化互動元素不同，UGC直播將特定流媒體使用者社群之間的溝通交流聊天互動作為主要產品導向。

我們在Twitch的朋友長期以來一直是低延遲實時流媒體技術領域的踐行者，為降低平臺流媒體延遲做出了卓越貢獻，降低極端情況下的視訊延遲至幾秒鐘。

我們嘗試進一步推進良好互動直播體驗的持續深入拓展。過去幾年我們喜聞樂見的程式之一是HQ Trivia，其背後測試過程的艱辛與最終良好直播同步功能的實現使其整個開發過程都令人難忘。由於無法有效獲得訊號參考點，我們很難精準衡量HQ Trivia的端到端延遲水平，但僅通過在直播現場觀察演示者與他人的聊天的迴應情況，我們依舊能夠非常容易地視其僅在很少的幾秒鐘發生極端延遲現象。HQ Trivia最令人印象深刻同樣也是其成功的關鍵便是在多種裝置與網路除了在拍賣領域的應用，專為博彩行業建立的直播流媒體服務也成為當下眾多博彩公司競相部署的熱點。去年我們看到很多博彩公司開始與線下莊家建立針對二十一點、輪盤賭或撲克等輕量級博彩活動的流媒體平臺。這些用於博彩的視訊流的有效性也基於能夠確保莊家與眾多玩家互動的實時性與同步性。

Streamer sodapoppin在視訊賭場下注很大

例子：

• 拍賣：蘇富比拍賣行

• 視訊賭場：BetOnline

低延遲權衡

我們在為使用者設計直播類產品時需要始終明確，必要時為了保證產品服務的實時性可以採取一定妥協與犧牲措施。例如從視訊成為網際網路內容的一部分開始我們就使用預緩衝內容的方式儘可能降低不利網路條件對使用者觀看視訊體驗的影響，而實際上任何減少延遲的嘗試都會導致玩家緩衝內容數量的降低，從而使得最終的使用者體驗變得更加糟糕。

在過去的十年裡，視訊行業一直嘗試優化自適應位元率技術（ABR）。此方法通過使流適應使用者的可用頻寬來改善觀眾的終端使用者體驗，其原理是評估觀眾在播放器請求一段視訊時的頻寬情況並分析使用者觀看下一段內容時匹配哪種視訊質量最佳。在理想環境下此方法非常有效，隨著模型不斷降低延遲與延遲的減少，其同樣會引入一些問題。

傳統上，為了緩解直播流的延遲，我們會減少觀眾收到每個視訊塊持續的時間。然而，這不僅意味著需要減少了播放器緩衝流的持續時間，而且還意味著觀眾必須更頻繁地請求視訊塊，與此同時不斷增加的HTTP請求也會帶來額外開銷。

即便最終降低延遲的目標得以實現時，ABR技術的有效性也是伴有一定犧牲的。如客戶端持續緩衝視訊流的時間一旦過長，回放時就會出現 資料包丟失，網路更改或快取未命中的彈性就越大。不幸的是，我們看到的一些以低延遲名義銷售的技術也減少了冗餘備份，增加了複雜性，並引入了大量的供應商鎖定。

減少延遲的方法

一般來說，三種主要的方法開始成為減少實時流技術領域內延遲的常用策略。我們將在下面討論這三種方法，並嘗試將它們分別應用到我們在上面識別的案例中。

採用短視訊分片長度

• 延遲： 30到10秒之間

• 用例：市面上大部分直播，大多數運動和一些電子競技

• 適應性：高

• 支援併發量：大

正如我們之前討論的那樣，減少ABR驅動流的延遲的傳統方法是減少傳遞給終端使用者的分片持續時間。在過去幾年中，根據蘋果公司HLS規範的更新建議，平均分片長度從大約10秒減少到大約6秒。更短的分片通常會導致更低的延遲，原因是大多數播放器都是在開始播放之前預先緩衝一定數量的分片。例如，iOS裝置和Safari上的嵌入式視訊播放器總是在開始播放之前緩衝三個視訊分片。每個分片的持續時間為2秒（大致是可行的最小時間）的三個分片意味著約6秒的最小延遲，這裡不考慮攝取，轉碼，打包和傳送媒體分片所花費的時間。

DASH協議稍微改進了這種標準，允許manifest檔案指定在播放開始之前需要緩衝多少流。這包含在 minBufferTime屬性中。不幸的是，在現實世界中，只有個別DASH播放器和裝置實現了這種策略，並且許多人在開始播放之前會繼續下載一定數量的分片。這在“智慧電視”或客廳裝置上尤為常見。

實時協議

• 延遲： <1秒

• 用例：語音和實時通訊，拍賣和賭博

• 適應性：低

• 支援併發量：小

Meet / Hangouts，Facebook視訊聊天和許多其他應用程式的基礎並且表現良好。然而，任何經常使用視訊聊天技術的使用者都能夠察覺到這些系統對弱網環境或高丟包有多麼敏感，而這些網路環境在家庭使用者寬頻或蜂窩網路連線條件下非常常見。

由於WebRTC是基於點對點的傳輸協議，因此一個通話中只允許有限數量的參與者，但是在2018年，我們開始看到一些基於WebRTC構建的通訊直播框架可提供面向多人的大規模視訊傳輸系統。在大多數情況下，這是通過將WebRTC中繼節點新增到CDN或邊緣計算網路中來實現的，從而允許瀏覽器連線到所需的視訊傳輸對等點。

雖然這種方法是對WebRTC協議的創新使用，但其並非WebRTC的真正設計目標，除非企業對在公共雲中執行自己的WebRTC邊緣伺服器感興趣，否則不一定採取這種方式。我們很高興看到主流CDN供應商將在未來一年中推出更多公共WebRTC產品以幫助其他企業實現相似功能——不幸的是，現在僅有一種CDN（Limelight）產品提供類似功能，而過於專注此方向會限制企業的規模並增加企業對供應商的依賴。全方位多樣化的CDN使用策略是音視訊企業過去幾年最重要的發展方向之一——使用像Cedexis這樣的工具來執行鍼對不同情況活動的CDN實時切換，可在確保產品服務正常使用的同時進一步減少延遲並提高終端產品服務的穩定性。

分塊傳輸分段流

• 延遲： 4到1秒之間

• 用例： UGC和互動體驗，體育和電子競技。

• 適應性：中等

• 支援併發量：大

去年年底，我們開始看到一種新的低延遲實時流媒體方案開始受到多個機構的關注並努力實現其標準化。我們已經討論過分段流媒體如何在今天大規模執行——分塊傳輸解決方案是該解決方案的一個良好的可向後相容的擴充套件。

我們知道，一個視訊片段由許多視訊幀組成，我們將這些被分組的視訊幀稱為GOP——通常一個視訊片段包含多個GOP。要解碼一段視訊流，我們通常需要一個完整的可用GOP，但這並不意味著必須輸入一個完整的GOP至播放器才能實現解碼。

通過利用HTTP 1.1規範中鮮為人知的稱為“分塊傳輸編碼”的功能，播放器可以對一段視訊發出標準的HTTP請求，編碼器可以在整段視訊仍處於編碼狀態時使用該段的GOP(通常是一個完整的GOP)進行解碼操作。使得觀眾可從視訊中任意位置開始觀看而非必須等待所有視訊幀完成傳輸與解碼之後可觀看。

為實現這種功能，除了需要一個支援分塊傳輸與輸出的編碼器和一個支援此傳輸模式(大多數CDN已支援)的CDN之外，我們還需要對播放器進行小規模改進以支援這種低延遲流處理方案。然而需要強調的是儘管此方法可以提供令人印象深刻的低延遲資料流表現，但亟需我們解決的挑戰仍然存在，即播放器的緩衝區減少。對於遇到卡頓的終端使用者，企業可能需要考慮使用更高的延遲策略。

客戶端面臨的嚴峻挑戰之一是此方法在測量網路效能方面帶來的困難。現如今大多數播放器都依賴於視訊分片下載效能來衡量可用頻寬，但是使用基於分塊傳輸的解決方案，10秒的分片的下載時間為10秒是完全正常的，因為這正是編碼器生成塊的速度。

真正的好訊息是，人們逐漸重視對此方案的研發投入，並努力實現其標準化。目前，有兩個小組致力於分塊傳輸分段流的標準化：LHLS（低延遲HLS）社群目前正在HLS-JS專案中定義RFC，我們可以通過Github為此專案提出建議；與此同時CMAF(通用媒體應用程式格式)組的標準化工作也在如期推進，其採用一種獨特微妙的方法便是圍繞使用符合CMAF的fMP4子片段，而不是TS流段中包含的GOP - 這顯然與MPEG-DASH的傳輸標準非常一致。

這兩種方法都已經得到了許多視訊流媒體巨頭的支援。LHLS目前獲得了來自Mux，JWPlayer，Wowza，Akamai，Mist Server和AWS Elemental的支援。除了CMAF社群之外，CMAF方法也得到了很多支援，GPAC，Akamai，Harmonic，Theoplayer，Bitmovin和其他人也做出了貢獻。預計在不久的將來們就可以看到這兩個群體的融合。特別是，在LHLS manifest中使用CMAF媒體塊的能力將引入一種可互換的媒體格式，據客戶端的裝置，該格式可以提供2種不同的manifest格式。

雖然這些方法還處於標準化過程的早期，但不失為一種有效的探索，其優勢在於有效適應現有的多CDN策略併為那些無法支援低延遲策略的播放器提供向後相容的方法。

專有解決方案

在過去的12個月中，我們可以看到許多新的專有低延遲實時流媒體解決方案開始進入市場，其中大多數使用WebRTC作為傳輸機制。正如在本文前面已經提到的那樣，我們對WebRTC解決方案的供應商封閉與規模限制感到擔憂。我們迫切希望看到這些解決方案能夠進一步被實踐與拓展，以便及時瞭解這些供應商應對挑戰的策略。

以下是我們認為非常有趣的一些專有解決方案：

Limelight視訊加速

Limelight與Red5 Pro合作，構建了一個基於WebRTC的解決方案，提供高規模的低延遲實時流媒體體驗。我們在IBC（阿姆斯特丹）看到了令人印象深刻的演示：來自美國西海岸的資料流可實現端到端延遲小於500毫秒。

具有超低延遲的Wowza流雲

Wowza目前為低延遲實時流提供了幾種不同的解決方案，包括稱為“WOWZ”的專有技術，該技術可作為其SaaS產品線的一部分使用。當使用Wowza自己的播放器時，WOWZ提供不到3秒的延遲，這使Wowza播放器符合超低延遲的定義，這對規模化部署而言十分重要&規模上是非常令人印象深刻的。正如Wowza的Scott和Jamie在Demuxed 2017中解釋的那樣，WOWZ協議基於WebSockets。

如果您有支援WebRTC中繼的CDN，例如Limelight，您還可以在Wowza的流媒體引擎中利用WebRTC實現更多功能。

Phenix

Phenix是市場上一個相當新的播放器，可提供基於對等網路的實時流媒體解決方案，聲稱可在全球範圍內提供低於500毫秒延遲的流媒體視訊傳輸服務。即使我們還沒有看到此解決方案的任何實際應用，但他們聲稱已經使用AI來解決大量使用者突然加入單流時常見的擁塞問題。Phenix似乎在WebRTC的基礎上構建了具有專有自定義功能的服務。

Nanocosmos

我們對Nanocosmos的解決方案瞭解不多，但他們聲稱擁有可擴充套件的實時流解決方案並在全球實現亞秒級的網路延遲。我們還沒能夠深入研究他們的技術，但我們有興趣觀察它的發展並從中獲得啟發。

Mux的實時流媒體延遲頻譜

在過去的12個月裡，業內有很多建議術語來描述流媒體領域的不同延遲。我們花了一些時間看看那裡有什麼，並評估了形勢，這是我們的建議。

我們要感謝Will Law在這裡啟發了我們的定義。

高延遲

• 延遲：超過30秒

• 技術： HLS，DASH，平滑 - 10+秒段

• 用例：延遲無關緊要的直播流Standard Latency

標準延遲

• 延遲： 30到10秒

• 技術：短片段HLS，DASH - 6到2秒片段

• 使用案例：同時播出不希望超越無線廣播

低延遲

• 延遲： 10到4秒

• 技術：非常短的段HLS，DASH - 2到1秒段或塊式傳輸HLS / DASH - LHLS / CMAF

• 用例： UGC，現場體驗，拍賣，賭博

超低延遲

• 延遲： 4到1秒

• 技術：分塊轉移HLS / DASH - LHLS / CMAF

• 用例： UGC，現場體驗，拍賣，賭博

Sub-Second

• 延遲：不到1秒

• 技術： WebRTC，專有解決方案

• 用例：視訊會議，VOIP等

我們還從去年的Demuxed（https://mux.com/blog/youtube-viewers-dont-care-about-video-quality/#3submediasegmentchunkedtransferisbecomingthepreferedwaytoachievelowlatencystreamingatscale）中彙總了我們自己的圖表，展示了我們對行業發展的看法。

Mux實時流媒體延遲頻譜 - Mux 2019

點選【 閱讀原文 】或掃描圖中二維碼瞭解更多LiveVideoStackCon 2019 上海 音視訊技術大會 講師資訊。