2019年低延迟直播技术展望
低延遲視頻直播是2018年的熱門話題之一。本文通過(guò)多個(gè)實(shí)際用例詳細(xì)介紹了不同場(chǎng)景下，影響用戶體驗(yàn)的延遲范圍，降低延遲的策略并探索可以為用戶提供最佳體驗(yàn)的不斷發(fā)展的技術(shù)。本文來(lái)自Mux博客，LiveVideoStack進(jìn)行了翻譯。感謝?Hulu Senior Dev Lead?傅德良提供的審校支持。
文 / Phil Cluff
譯 / 元寶
審校 / 傅德良
原文?
https://mux.com/blog/the-low-latency-live-streaming-landscape-in-2019/
在過(guò)去的2018年，良好性能的低延遲視頻直播一致成為NAB、IBC和Demuxed等公司努力的方向。接下來(lái)我們將借助多個(gè)實(shí)例探討研究直播延遲如何影響用戶體驗(yàn)，并探索能夠推動(dòng)視頻直播產(chǎn)品進(jìn)一步發(fā)展的新技術(shù)。
在深入研究視頻直播延遲之前，我們需要明確延遲的定義：我們可以把延遲理解為用戶觀看視頻直播時(shí)直播端呈現(xiàn)畫面與現(xiàn)實(shí)中主播端記錄下畫面并非同步所出現(xiàn)的時(shí)間線偏差。常見(jiàn)類型有端到端延遲、鏡頭-顯示屏延遲等
延遲在什么時(shí)候很重要？
延遲的故事很復(fù)雜。延遲的可接受程度完全取決于您要解決的問(wèn)題。我們將下面的一些用例放在一起，我們認(rèn)為這些用例通常會(huì)對(duì)最終用戶感受到的延遲產(chǎn)生挑戰(zhàn)。
語(yǔ)音和實(shí)時(shí)通信
基于實(shí)時(shí)通信的應(yīng)用場(chǎng)景更易受到延遲的影響，例如以個(gè)人視頻電話為例的一對(duì)一在線交流或以視頻會(huì)議為例的團(tuán)隊(duì)在線溝通。
通常情況下對(duì)于實(shí)時(shí)通信而言，200ms（0.2秒）的延遲就會(huì)為通信體驗(yàn)帶來(lái)明顯不良影響；而超過(guò)200ms的延遲會(huì)使實(shí)時(shí)通信變得難以繼續(xù)進(jìn)行，與此同時(shí)延遲不單單會(huì)為雙方交流的實(shí)時(shí)性帶來(lái)障礙，隨著延遲增加逐漸惡化的噪聲與回聲也使技術(shù)界對(duì)低延遲的研究越來(lái)越迫切。
當(dāng)實(shí)時(shí)通信的延遲高達(dá)一秒以上，用戶的實(shí)時(shí)交流就失去了存在的意義。因此業(yè)界在設(shè)計(jì)相關(guān)協(xié)議與技術(shù)指標(biāo)時(shí)會(huì)通過(guò)適當(dāng)降低畫面質(zhì)量的方式做出一定妥協(xié)，從而確保能夠在極端環(huán)境下也能提供基本的實(shí)時(shí)通信服務(wù)。
例子：
FaceTime
Google Meet / Hangouts
Skype
體育和電子競(jìng)技
體育賽事直播面臨的挑戰(zhàn)并非盡可能實(shí)現(xiàn)最低延遲，而是實(shí)現(xiàn)多端同步延遲。我們知道現(xiàn)在的大型體育賽事直播都是通過(guò)廣播電視網(wǎng)絡(luò)與衛(wèi)星通信等傳統(tǒng)技術(shù)手段實(shí)現(xiàn)傳輸。對(duì)于許多廣播電視公司來(lái)說(shuō)其目標(biāo)在于讓身處不同傳輸鏈路（互聯(lián)網(wǎng)、廣播、有線電視、數(shù)字電視等）的所有用戶體驗(yàn)到同步的延遲，一般延遲為2秒～15秒之間，廣播的平均延遲約為6秒。需要強(qiáng)調(diào)的是這種幾秒甚至幾十秒的延遲并非技術(shù)缺陷而是人為規(guī)定，其主要用于廣播電視的監(jiān)管機(jī)構(gòu)能夠在直播畫面制作完成到播出之間進(jìn)行審查。
而對(duì)于那些關(guān)注度較高的大型體育賽事直播而言，其關(guān)鍵點(diǎn)在于實(shí)現(xiàn)兩種傳遞策略（互聯(lián)網(wǎng)與廣播電視）下的視頻直播畫面的延遲同步，從而能夠?qū)⒁曨l畫面同時(shí)呈現(xiàn)給不同端觀眾。例如在上屆世界杯，當(dāng)英國(guó)隊(duì)進(jìn)行點(diǎn)球大戰(zhàn)時(shí)你可以在不同時(shí)期聽(tīng)到來(lái)自倫敦市中心不同酒吧派對(duì)的英格蘭球迷的歡呼聲，其原因便是在互倆網(wǎng)端BBC iPlayer上的超高清視頻流比有線電視晚播出20-30秒，這種不同播放渠道之間高達(dá)半分鐘的延遲對(duì)當(dāng)時(shí)期待進(jìn)球結(jié)果的球迷而言無(wú)疑是對(duì)比賽精彩懸念的毀滅，也會(huì)讓廣播電視公司的服務(wù)水平大打折扣。所以在英國(guó)，一般情況下周四晚通過(guò)互聯(lián)網(wǎng)視頻流在Twitch.tv上播出的球賽會(huì)比普通的有線電視廣播提前20秒左右播放。
電子競(jìng)技面臨的延遲問(wèn)題則更為有趣，與體育賽事直播不同是，電子競(jìng)技直播一般不需要廣播電視等傳統(tǒng)媒體傳輸渠道實(shí)現(xiàn)視頻流傳輸，其對(duì)延遲的敏感程度也低于其他傳統(tǒng)體育賽事直播場(chǎng)景。隨著社交網(wǎng)絡(luò)與新聞供應(yīng)商不斷改善畫面延遲，觀眾對(duì)延遲的要求越來(lái)越高，相信沒(méi)有人愿意在互聯(lián)網(wǎng)瀏覽視頻時(shí)被突然出現(xiàn)的延遲推送打擾。
例子：
體育：BBC iPlayer或Fubo.tv上的FIFA世界杯
電子競(jìng)技：Twitch上的DOTA “The Internationals”
交互式體驗(yàn)和交互式UGC流
隨著UGC直播文化的發(fā)展，我們可以很清晰地發(fā)現(xiàn)視頻直播所涉及的應(yīng)用面不再局限于體育產(chǎn)業(yè)與電子競(jìng)技，而是拓展成為一個(gè)滲透生活多個(gè)方面的全方位流媒體平臺(tái)。與Twitch上的視頻產(chǎn)品普遍強(qiáng)化交互元素不同，UGC直播將特定流媒體用戶社區(qū)之間的溝通交流聊天互動(dòng)作為主要產(chǎn)品導(dǎo)向。
我們?cè)赥witch的朋友長(zhǎng)期以來(lái)一直是低延遲實(shí)時(shí)流媒體技術(shù)領(lǐng)域的踐行者，為降低平臺(tái)流媒體延遲做出了卓越貢獻(xiàn)，降低極端情況下的視頻延遲至幾秒鐘。
我們嘗試進(jìn)一步推進(jìn)良好互動(dòng)直播體驗(yàn)的持續(xù)深入拓展。過(guò)去幾年我們喜聞樂(lè)見(jiàn)的程序之一是HQ Trivia，其背后測(cè)試過(guò)程的艱辛與最終良好直播同步功能的實(shí)現(xiàn)使其整個(gè)開(kāi)發(fā)過(guò)程都令人難忘。由于無(wú)法有效獲得信號(hào)參考點(diǎn)，我們很難精準(zhǔn)衡量HQ Trivia的端到端延遲水平，但僅通過(guò)在直播現(xiàn)場(chǎng)觀察演示者與他人的聊天的回應(yīng)情況，我們依舊能夠非常容易地視其僅在很少的幾秒鐘發(fā)生極端延遲現(xiàn)象。HQ Trivia最令人印象深刻同樣也是其成功的關(guān)鍵便是在多種設(shè)備與網(wǎng)絡(luò)除了在拍賣領(lǐng)域的應(yīng)用，專為博彩行業(yè)建立的直播流媒體服務(wù)也成為當(dāng)下眾多博彩公司競(jìng)相部署的熱點(diǎn)。去年我們看到很多博彩公司開(kāi)始與線下莊家建立針對(duì)二十一點(diǎn)、輪盤賭或撲克等輕量級(jí)博彩活動(dòng)的流媒體平臺(tái)。這些用于博彩的視頻流的有效性也基于能夠確保莊家與眾多玩家互動(dòng)的實(shí)時(shí)性與同步性。
Streamer sodapoppin在視頻賭場(chǎng)下注很大
例子：
拍賣：蘇富比拍賣行
視頻賭場(chǎng)：BetOnline
低延遲權(quán)衡
我們?cè)跒橛脩粼O(shè)計(jì)直播類產(chǎn)品時(shí)需要始終明確，必要時(shí)為了保證產(chǎn)品服務(wù)的實(shí)時(shí)性可以采取一定妥協(xié)與犧牲措施。例如從視頻成為互聯(lián)網(wǎng)內(nèi)容的一部分開(kāi)始我們就使用預(yù)緩沖內(nèi)容的方式盡可能降低不利網(wǎng)絡(luò)條件對(duì)用戶觀看視頻體驗(yàn)的影響，而實(shí)際上任何減少延遲的嘗試都會(huì)導(dǎo)致玩家緩沖內(nèi)容數(shù)量的降低，從而使得最終的用戶體驗(yàn)變得更加糟糕。
在過(guò)去的十年里，視頻行業(yè)一直嘗試優(yōu)化自適應(yīng)比特率技術(shù)（ABR）。此方法通過(guò)使流適應(yīng)用戶的可用帶寬來(lái)改善觀眾的最終用戶體驗(yàn)，其原理是評(píng)估觀眾在播放器請(qǐng)求一段視頻時(shí)的帶寬情況并分析用戶觀看下一段內(nèi)容時(shí)匹配哪種視頻質(zhì)量最佳。在理想環(huán)境下此方法非常有效，隨著模型不斷降低延遲與延遲的減少，其同樣會(huì)引入一些問(wèn)題。
傳統(tǒng)上，為了緩解直播流的延遲，我們會(huì)減少觀眾收到每個(gè)視頻塊持續(xù)的時(shí)間。然而，這不僅意味著需要減少了播放器緩沖流的持續(xù)時(shí)間，而且還意味著觀眾必須更頻繁地請(qǐng)求視頻塊，與此同時(shí)不斷增加的HTTP請(qǐng)求也會(huì)帶來(lái)額外開(kāi)銷。
即便最終降低延遲的目標(biāo)得以實(shí)現(xiàn)時(shí)，ABR技術(shù)的有效性也是伴有一定犧牲的。如客戶端持續(xù)緩沖視頻流的時(shí)間一旦過(guò)長(zhǎng)，回放時(shí)就會(huì)出現(xiàn) 數(shù)據(jù)包丟失，網(wǎng)絡(luò)更改或緩存未命中的彈性就越大。不幸的是，我們看到的一些以低延遲名義銷售的技術(shù)也減少了冗余備份，增加了復(fù)雜性，并引入了大量的供應(yīng)商鎖定。
減少延遲的方法
一般來(lái)說(shuō)，三種主要的方法開(kāi)始成為減少實(shí)時(shí)流技術(shù)領(lǐng)域內(nèi)延遲的常用策略。我們將在下面討論這三種方法，并嘗試將它們分別應(yīng)用到我們?cè)谏厦孀R(shí)別的案例中。
采用短視頻分片長(zhǎng)度
延遲： 30到10秒之間
用例：市面上大部分直播，大多數(shù)運(yùn)動(dòng)和一些電子競(jìng)技
適應(yīng)性：高
支持并發(fā)量：大
正如我們之前討論的那樣，減少ABR驅(qū)動(dòng)流的延遲的傳統(tǒng)方法是減少傳遞給最終用戶的分片持續(xù)時(shí)間。在過(guò)去幾年中，根據(jù)蘋果公司HLS規(guī)范的更新建議，平均分片長(zhǎng)度從大約10秒減少到大約6秒。更短的分片通常會(huì)導(dǎo)致更低的延遲，原因是大多數(shù)播放器都是在開(kāi)始播放之前預(yù)先緩沖一定數(shù)量的分片。例如，iOS設(shè)備和Safari上的嵌入式視頻播放器總是在開(kāi)始播放之前緩沖三個(gè)視頻分片。每個(gè)分片的持續(xù)時(shí)間為2秒（大致是可行的最小時(shí)間）的三個(gè)分片意味著約6秒的最小延遲，這里不考慮攝取，轉(zhuǎn)碼，打包和傳送媒體分片所花費(fèi)的時(shí)間。
DASH協(xié)議稍微改進(jìn)了這種標(biāo)準(zhǔn)，允許manifest文件指定在播放開(kāi)始之前需要緩沖多少流。這包含在minBufferTime屬性中。不幸的是，在現(xiàn)實(shí)世界中，只有個(gè)別DASH播放器和設(shè)備實(shí)現(xiàn)了這種策略，并且許多人在開(kāi)始播放之前會(huì)繼續(xù)下載一定數(shù)量的分片。這在“智能電視”或客廳設(shè)備上尤為常見(jiàn)。
實(shí)時(shí)協(xié)議
延遲： <1秒
用例：語(yǔ)音和實(shí)時(shí)通信，拍賣和賭博
適應(yīng)性：低
支持并發(fā)量：小
Meet / Hangouts，Facebook視頻聊天和許多其他應(yīng)用程序的基礎(chǔ)并且表現(xiàn)良好。然而，任何經(jīng)常使用視頻聊天技術(shù)的用戶都能夠察覺(jué)到這些系統(tǒng)對(duì)弱網(wǎng)環(huán)境或高丟包有多么敏感，而這些網(wǎng)絡(luò)環(huán)境在家庭用戶寬帶或蜂窩網(wǎng)絡(luò)連接條件下非常常見(jiàn)。
由于WebRTC是基于點(diǎn)對(duì)點(diǎn)的傳輸協(xié)議，因此一個(gè)通話中只允許有限數(shù)量的參與者，但是在2018年，我們開(kāi)始看到一些基于WebRTC構(gòu)建的通信直播框架可提供面向多人的大規(guī)模視頻傳輸系統(tǒng)。在大多數(shù)情況下，這是通過(guò)將WebRTC中繼節(jié)點(diǎn)添加到CDN或邊緣計(jì)算網(wǎng)絡(luò)中來(lái)實(shí)現(xiàn)的，從而允許瀏覽器連接到所需的視頻傳輸對(duì)等點(diǎn)。
雖然這種方法是對(duì)WebRTC協(xié)議的創(chuàng)新使用，但其并非WebRTC的真正設(shè)計(jì)目標(biāo)，除非企業(yè)對(duì)在公共云中運(yùn)行自己的WebRTC邊緣服務(wù)器感興趣，否則不一定采取這種方式。我們很高興看到主流CDN供應(yīng)商將在未來(lái)一年中推出更多公共WebRTC產(chǎn)品以幫助其他企業(yè)實(shí)現(xiàn)相似功能——不幸的是，現(xiàn)在僅有一種CDN（Limelight）產(chǎn)品提供類似功能，而過(guò)于專注此方向會(huì)限制企業(yè)的規(guī)模并增加企業(yè)對(duì)供應(yīng)商的依賴。全方位多樣化的CDN使用策略是音視頻企業(yè)過(guò)去幾年最重要的發(fā)展方向之一——使用像Cedexis這樣的工具來(lái)執(zhí)行針對(duì)不同情況活動(dòng)的CDN實(shí)時(shí)切換，可在確保產(chǎn)品服務(wù)正常使用的同時(shí)進(jìn)一步減少延遲并提高終端產(chǎn)品服務(wù)的穩(wěn)定性。
分塊傳輸分段流
延遲： 4到1秒之間
用例： UGC和互動(dòng)體驗(yàn)，體育和電子競(jìng)技。
適應(yīng)性：中等
支持并發(fā)量：大
去年年底，我們開(kāi)始看到一種新的低延遲實(shí)時(shí)流媒體方案開(kāi)始受到多個(gè)機(jī)構(gòu)的關(guān)注并努力實(shí)現(xiàn)其標(biāo)準(zhǔn)化。我們已經(jīng)討論過(guò)分段流媒體如何在今天大規(guī)模運(yùn)行——分塊傳輸解決方案是該解決方案的一個(gè)良好的可向后兼容的擴(kuò)展。
我們知道，一個(gè)視頻片段由許多視頻幀組成，我們將這些被分組的視頻幀稱為GOP——通常一個(gè)視頻片段包含多個(gè)GOP。要解碼一段視頻流，我們通常需要一個(gè)完整的可用GOP，但這并不意味著必須輸入一個(gè)完整的GOP至播放器才能實(shí)現(xiàn)解碼。
通過(guò)利用HTTP 1.1規(guī)范中鮮為人知的稱為“分塊傳輸編碼”的功能，播放器可以對(duì)一段視頻發(fā)出標(biāo)準(zhǔn)的HTTP請(qǐng)求，編碼器可以在整段視頻仍處于編碼狀態(tài)時(shí)使用該段的GOP(通常是一個(gè)完整的GOP)進(jìn)行解碼操作。使得觀眾可從視頻中任意位置開(kāi)始觀看而非必須等待所有視頻幀完成傳輸與解碼之后可觀看。
為實(shí)現(xiàn)這種功能，除了需要一個(gè)支持分塊傳輸與輸出的編碼器和一個(gè)支持此傳輸模式(大多數(shù)CDN已支持)的CDN之外，我們還需要對(duì)播放器進(jìn)行小規(guī)模改進(jìn)以支持這種低延遲流處理方案。然而需要強(qiáng)調(diào)的是盡管此方法可以提供令人印象深刻的低延遲數(shù)據(jù)流表現(xiàn)，但亟需我們解決的挑戰(zhàn)仍然存在，即播放器的緩沖區(qū)減少。對(duì)于遇到卡頓的最終用戶，企業(yè)可能需要考慮使用更高的延遲策略。
客戶端面臨的嚴(yán)峻挑戰(zhàn)之一是此方法在測(cè)量網(wǎng)絡(luò)性能方面帶來(lái)的困難。現(xiàn)如今大多數(shù)播放器都依賴于視頻分片下載性能來(lái)衡量可用帶寬，但是使用基于分塊傳輸?shù)慕鉀Q方案，10秒的分片的下載時(shí)間為10秒是完全正常的，因?yàn)檫@正是編碼器生成塊的速度。
真正的好消息是，人們逐漸重視對(duì)此方案的研發(fā)投入，并努力實(shí)現(xiàn)其標(biāo)準(zhǔn)化。目前，有兩個(gè)小組致力于分塊傳輸分段流的標(biāo)準(zhǔn)化：LHLS（低延遲HLS）社區(qū)目前正在HLS-JS項(xiàng)目中定義RFC，我們可以通過(guò)Github為此項(xiàng)目提出建議；與此同時(shí)CMAF(通用媒體應(yīng)用程序格式)組的標(biāo)準(zhǔn)化工作也在如期推進(jìn)，其采用一種獨(dú)特微妙的方法便是圍繞使用符合CMAF的fMP4子片段，而不是TS流段中包含的GOP - 這顯然與MPEG-DASH的傳輸標(biāo)準(zhǔn)非常一致。
這兩種方法都已經(jīng)得到了許多視頻流媒體巨頭的支持。LHLS目前獲得了來(lái)自Mux，JWPlayer，Wowza，Akamai，Mist Server和AWS Elemental的支持。除了CMAF社區(qū)之外，CMAF方法也得到了很多支持，GPAC，Akamai，Harmonic，Theoplayer，Bitmovin和其他人也做出了貢獻(xiàn)。預(yù)計(jì)在不久的將來(lái)們就可以看到這兩個(gè)群體的融合。特別是，在LHLS manifest中使用CMAF媒體塊的能力將引入一種可互換的媒體格式，據(jù)客戶端的設(shè)備，該格式可以提供2種不同的manifest格式。
雖然這些方法還處于標(biāo)準(zhǔn)化過(guò)程的早期，但不失為一種有效的探索，其優(yōu)勢(shì)在于有效適應(yīng)現(xiàn)有的多CDN策略并為那些無(wú)法支持低延遲策略的播放器提供向后兼容的方法。
專有解決方案
在過(guò)去的12個(gè)月中，我們可以看到許多新的專有低延遲實(shí)時(shí)流媒體解決方案開(kāi)始進(jìn)入市場(chǎng)，其中大多數(shù)使用WebRTC作為傳輸機(jī)制。正如在本文前面已經(jīng)提到的那樣，我們對(duì)WebRTC解決方案的供應(yīng)商封閉與規(guī)模限制感到擔(dān)憂。我們迫切希望看到這些解決方案能夠進(jìn)一步被實(shí)踐與拓展，以便及時(shí)了解這些供應(yīng)商應(yīng)對(duì)挑戰(zhàn)的策略。
以下是我們認(rèn)為非常有趣的一些專有解決方案：
Limelight視頻加速
Limelight與Red5 Pro合作，構(gòu)建了一個(gè)基于WebRTC的解決方案，提供高規(guī)模的低延遲實(shí)時(shí)流媒體體驗(yàn)。我們?cè)贗BC（阿姆斯特丹）看到了令人印象深刻的演示：來(lái)自美國(guó)西海岸的數(shù)據(jù)流可實(shí)現(xiàn)端到端延遲小于500毫秒。
具有超低延遲的Wowza流云
Wowza目前為低延遲實(shí)時(shí)流提供了幾種不同的解決方案，包括稱為“WOWZ”的專有技術(shù)，該技術(shù)可作為其SaaS產(chǎn)品線的一部分使用。當(dāng)使用Wowza自己的播放器時(shí)，WOWZ提供不到3秒的延遲，這使Wowza播放器符合超低延遲的定義，這對(duì)規(guī)模化部署而言十分重要&規(guī)模上是非常令人印象深刻的。正如Wowza的Scott和Jamie在Demuxed 2017中解釋的那樣，WOWZ協(xié)議基于WebSockets。
如果您有支持WebRTC中繼的CDN，例如Limelight，您還可以在Wowza的流媒體引擎中利用WebRTC實(shí)現(xiàn)更多功能。
Phenix
Phenix是市場(chǎng)上一個(gè)相當(dāng)新的播放器，可提供基于對(duì)等網(wǎng)絡(luò)的實(shí)時(shí)流媒體解決方案，聲稱可在全球范圍內(nèi)提供低于500毫秒延遲的流媒體視頻傳輸服務(wù)。即使我們還沒(méi)有看到此解決方案的任何實(shí)際應(yīng)用，但他們聲稱已經(jīng)使用AI來(lái)解決大量用戶突然加入單流時(shí)常見(jiàn)的擁塞問(wèn)題。Phenix似乎在WebRTC的基礎(chǔ)上構(gòu)建了具有專有自定義功能的服務(wù)。
Nanocosmos
我們對(duì)Nanocosmos的解決方案了解不多，但他們聲稱擁有可擴(kuò)展的實(shí)時(shí)流解決方案并在全球?qū)崿F(xiàn)亞秒級(jí)的網(wǎng)絡(luò)延遲。我們還沒(méi)能夠深入研究他們的技術(shù)，但我們有興趣觀察它的發(fā)展并從中獲得啟發(fā)。
Mux的實(shí)時(shí)流媒體延遲頻譜
在過(guò)去的12個(gè)月里，業(yè)內(nèi)有很多建議術(shù)語(yǔ)來(lái)描述流媒體領(lǐng)域的不同延遲。我們花了一些時(shí)間看看那里有什么，并評(píng)估了形勢(shì)，這是我們的建議。
我們要感謝Will Law在這里啟發(fā)了我們的定義。
高延遲
延遲：超過(guò)30秒
技術(shù)： HLS，DASH，平滑 - 10+秒段
用例：延遲無(wú)關(guān)緊要的直播流Standard Latency
標(biāo)準(zhǔn)延遲
延遲： 30到10秒
技術(shù)：短片段HLS，DASH - 6到2秒片段
使用案例：同時(shí)播出不希望超越無(wú)線廣播
低延遲
延遲： 10到4秒
技術(shù)：非常短的段HLS，DASH - 2到1秒段或塊式傳輸HLS / DASH - LHLS / CMAF
用例： UGC，現(xiàn)場(chǎng)體驗(yàn)，拍賣，賭博
超低延遲
延遲： 4到1秒
技術(shù)：分塊轉(zhuǎn)移HLS / DASH - LHLS / CMAF
用例： UGC，現(xiàn)場(chǎng)體驗(yàn)，拍賣，賭博
Sub-Second
延遲：不到1秒
技術(shù)： WebRTC，專有解決方案
用例：視頻會(huì)議，VOIP等
我們還從去年的Demuxed（https://mux.com/blog/youtube-viewers-dont-care-about-video-quality/#3submediasegmentchunkedtransferisbecomingthepreferedwaytoachievelowlatencystreamingatscale）中匯總了我們自己的圖表，展示了我們對(duì)行業(yè)發(fā)展的看法。
Mux實(shí)時(shí)流媒體延遲頻譜 - Mux 2019
點(diǎn)擊【閱讀原文】或掃描圖中二維碼了解更多LiveVideoStackCon 2019 上海 音視頻技術(shù)大會(huì) 講師信息。
總結(jié)
以上是生活随笔為你收集整理的2019年低延迟直播技术展望的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： LiveVideoStack：祝大家 2
- 下一篇： B站Up主上传质量调优实践