2019年低延迟直播技术展望
低延遲視頻直播是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 上海 音視頻技術大會 講師信息。
總結
以上是生活随笔為你收集整理的2019年低延迟直播技术展望的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： LiveVideoStack：祝大家 2
- 下一篇： B站Up主上传质量调优实践