视频传输面临的挑战和解决之道
音視頻行業(yè)的發(fā)展，用戶對音視頻畫質(zhì)的清晰度、播放的流暢度、互動(dòng)的低延遲、突破終端限制等的要求越來越高。這些需求從客觀上對視頻的傳輸提出更高的挑戰(zhàn)，而目前不同業(yè)務(wù)的視頻傳輸方式各有不同，如何基于視頻傳輸現(xiàn)狀，全面系統(tǒng)解決用戶需求，成為業(yè)界面臨的普遍問題。華為云視頻架構(gòu)師黃挺，將從視頻傳輸現(xiàn)狀入手，剖析不同業(yè)務(wù)選擇不同視頻傳輸方式的背后邏輯，分享華為云新媒體網(wǎng)絡(luò)價(jià)值主張。
大家好，我是華為云視頻架構(gòu)師黃挺，非常高興有機(jī)會(huì)參加LiveVideoStackCon音視頻技術(shù)大會(huì)，這次和大家分享的主題是：視頻傳輸面臨的挑戰(zhàn)和解決之道。
內(nèi)容主要涵蓋以下幾個(gè)方面：視頻發(fā)展的特點(diǎn)、影響IPTV/OTT/RTC音視頻傳輸技術(shù)選擇的背后邏輯、結(jié)合對未來音視頻傳輸行業(yè)的洞察，華為云提出的新媒體網(wǎng)絡(luò)價(jià)值主張。
視頻發(fā)展三個(gè)特點(diǎn)
1. 概念
數(shù)字傳輸IP化，在TV領(lǐng)域，從傳統(tǒng)的數(shù)字電視基于Cable的傳輸，到IPTV領(lǐng)域，基于IP傳輸，以及在制作領(lǐng)域，從傳統(tǒng)基于SDI的傳輸，再到基于IP的傳輸，這些都是數(shù)字傳輸IP化的體現(xiàn)。數(shù)字傳輸IP化是視頻分發(fā)公域化的基礎(chǔ)。
視頻分發(fā)公域化，有公域化就有對應(yīng)的私域化，私域化視頻分發(fā)一般是指在可管理網(wǎng)絡(luò)進(jìn)行視頻分發(fā)，公域化一般是指基于互聯(lián)網(wǎng)分發(fā)，常見的有:從IPTV到OTT；從企業(yè)內(nèi)部視頻會(huì)議到在線視頻會(huì)議；視頻分發(fā)公域化與視頻傳輸技術(shù)的發(fā)展密不可分。
業(yè)務(wù)體驗(yàn)多樣化：就是不同業(yè)務(wù)對體驗(yàn)的規(guī)格要求不同，主要存在三個(gè)方面：質(zhì)量，規(guī)模，時(shí)延；如直播時(shí)延<5s；RTC時(shí)延<400ms；云游戲時(shí)延<100ms。
2. 數(shù)字傳輸IP化+視頻分發(fā)公域化
這里我們看一下VR領(lǐng)域正在發(fā)生的變化。目前VR主要有兩類形態(tài)，一類是PC VR 如上圖，玩家在玩VR 游戲的時(shí)候頭盔需要連一根線到PC主機(jī)，游戲運(yùn)行在PC主機(jī)上，活動(dòng)靈活性受限。另外一類是一體機(jī)VR，這是ALL IN ONE 設(shè)計(jì)，沒有這個(gè)“辮子”，活動(dòng)靈活性好，但是因?yàn)橛?jì)算單元也在這個(gè)頭盔上，所以受限于功耗的問題，算力比較小。
目前有一個(gè)一體機(jī)+PC的方案，既沒有“辮子”，同時(shí)也可以使用PC的算力，即通過Wifi 將PC渲染出來的圖像經(jīng)過編碼后傳輸?shù)絍R 頭盔。相對于PC VR，它可以看成是數(shù)字傳輸?shù)腎P化。
云VR 是更近一步的方案。云VR 直接使用云端的算力對游戲進(jìn)行渲染，這個(gè)時(shí)候視頻就需要在公域網(wǎng)咯進(jìn)行分發(fā)了，同時(shí)為了滿足體驗(yàn)的要求，也需要通信技術(shù)和視頻傳輸技術(shù)的進(jìn)一步優(yōu)化。目前的體驗(yàn)效果與理想狀況，還有一定差距。
3. 業(yè)務(wù)體驗(yàn)多樣化
前面講到除了時(shí)延還有很多體驗(yàn)上的差異，比如在規(guī)模上，不同的業(yè)務(wù)對分發(fā)的要求也不一樣。例如云游戲除了對時(shí)延的要求較高，對質(zhì)量的要求也同樣很高，如果大家玩過王者榮耀，就應(yīng)該知道，如果只開30幀，會(huì)明顯感覺游戲畫面不夠順暢。
對不同應(yīng)用場景下視頻需求的理解，也能更好的幫助我們理解不同業(yè)務(wù)領(lǐng)域?qū)夹g(shù)的選型邏輯，能夠讓我們更快的發(fā)現(xiàn)當(dāng)前技術(shù)的不足。接下來，會(huì)分別從IPTV、OTT、RTC業(yè)務(wù)的角度，梳理音視頻傳輸技術(shù)選型背后的邏輯。
IPTV、OTT、RTC音視頻傳輸技術(shù)選擇背后邏輯
1. IPTV
1.1 IPTV 介紹
IPTV是由運(yùn)營商主導(dǎo)建設(shè)的一套系統(tǒng)，IPTV的主要業(yè)務(wù)包括直播、點(diǎn)播、時(shí)移、回看和NPVR等，并且同時(shí)要達(dá)到TV級的質(zhì)量要求，全天候不間斷的直播。IPTV主要的優(yōu)勢是運(yùn)營商可以自建一套可管理的網(wǎng)絡(luò)，來保障TV級別的用戶體驗(yàn)。
IPTV使用的傳輸方式主要有兩種：一個(gè)是組播技術(shù)，主要應(yīng)用在直播業(yè)務(wù)。這個(gè)技術(shù)大大降低了業(yè)務(wù)峰值時(shí)，流媒體服務(wù)器的壓力。另一個(gè)是單播技術(shù)，使用了RTSP 進(jìn)行媒體信令控制，使用RTP 協(xié)議進(jìn)行音視頻數(shù)據(jù)傳輸，單播技術(shù)主要應(yīng)用在點(diǎn)播、時(shí)移、回看、NPVR等業(yè)務(wù)。
1.2 IPTV 直播業(yè)務(wù)（組播）挑戰(zhàn)
IPTV首要解決的問題是傳輸丟包帶來的花屏、卡頓等體驗(yàn)問題。
目前采用了2個(gè)手段解決這個(gè)問題：FEC和ARQ（也叫RET）。FEC主要應(yīng)用在組播場景；對于隨機(jī)丟包比較有效，同時(shí)因?yàn)槭穷l道級別的冗余生成，不需要為每個(gè)用戶獨(dú)立生成冗余報(bào)文，所以效率比較高。ARQ可以應(yīng)用在組播和單播場景。他可以較好的解決連續(xù)丟包問題。組播場景下，一般這2個(gè)技術(shù)會(huì)同時(shí)使用。
IPTV一個(gè)關(guān)鍵的體驗(yàn)指標(biāo)是頻道切換時(shí)長。
頻道切換時(shí)長主要是指，用戶按下遙控器切臺(tái)按鈕到對應(yīng)畫面出現(xiàn)的時(shí)間。這里我主要介紹一下組播場景下如何縮短這個(gè)時(shí)間。首先我們知道要讓畫面快速顯示，就要能夠快速解碼。而機(jī)頂盒加入組播組的時(shí)間取決于用戶何時(shí)切臺(tái)，這是隨機(jī)的，所以最初機(jī)頂盒收到的報(bào)文并不能立即開始解碼，這樣就會(huì)降低頻道切換的速度。
我們通過引入一個(gè)獨(dú)立的FCC服務(wù)器，機(jī)頂盒在加入組播組的同時(shí)向這個(gè)服務(wù)器請求一個(gè)單播流，FCC服務(wù)器可以確保每次請求都從I幀開始發(fā)送。這樣機(jī)頂盒最初收到報(bào)文時(shí)就可以解碼，從而提高頻道切換的速度。優(yōu)化前頻道切換時(shí)長需要1-3s，優(yōu)化后可以縮短到300-500ms。
IPTV本質(zhì)上是TV領(lǐng)域音視頻傳輸技術(shù)的IP化，因?yàn)榫W(wǎng)絡(luò)條件比較好，所以在技術(shù)選擇上沒有太復(fù)雜，更多強(qiáng)調(diào)的是系統(tǒng)穩(wěn)定性和跨廠家易集成性。
2.?OTT
2.1? OTT 視頻點(diǎn)播
由于在線觀看用戶數(shù)龐大，OTT 視頻平臺(tái)首要解決的是視頻內(nèi)容規(guī)?；职l(fā)的問題。首先，服務(wù)的范圍廣，需要面向全球用戶分發(fā)，視頻傳輸公域化、跨運(yùn)營商提供服務(wù)；其次，用戶規(guī)模大；最后，需要低成本的同時(shí)保證服務(wù)穩(wěn)定可靠。
目前主流解決方案是采用成熟的第三方CDN服務(wù)進(jìn)行分發(fā)。例如Netflix，隨著業(yè)務(wù)規(guī)模的增大，走向自建CDN（Open Connect），但依舊對第三方CDN友好，這樣當(dāng)自建CDN出現(xiàn)故障后，可以快速將流量切給第三方CDN的服務(wù)，確保業(yè)務(wù)的可用性。
此外，OTT視頻點(diǎn)播還面臨一系列體驗(yàn)問題：例如：帶寬質(zhì)量不穩(wěn)定，導(dǎo)致播放體驗(yàn)下降；終端因?yàn)镃PU被占用影響播放器解碼穩(wěn)定性；由于國家和地區(qū)的平均接入條件不同，如何讓一個(gè)內(nèi)容同時(shí)滿足不同用戶不同終端的體驗(yàn)要求。
2009開始相繼出現(xiàn)了HLS、MSS、DASH 等ABR技術(shù)，ABR 技術(shù)根據(jù)實(shí)時(shí)檢測用戶帶寬和終端側(cè)CPU 使用率，調(diào)整視頻流的質(zhì)量。這些技術(shù)對HTTP CDN 也是友好的。不過，ABR 只是標(biāo)準(zhǔn)化了服務(wù)器與客戶端的實(shí)現(xiàn)規(guī)范。體驗(yàn)的好壞，還取決于碼率自適應(yīng)算法的優(yōu)劣。
2.2?OTT 視頻直播
直播可以細(xì)分為E2E時(shí)延不敏感和敏感兩類。
第一類：例如新聞直播等，因?yàn)闆]有和觀眾互動(dòng)的要求屬于時(shí)延不敏感性。所以它們依然可以選擇對CDN友好的HLS和DASH協(xié)議，但是時(shí)延會(huì)高達(dá)10-30s。
第二類：例如網(wǎng)紅直播等，需要與觀眾進(jìn)行彈幕、評論等互動(dòng)，所以要求直播的E2E時(shí)延必須低于5s，這類廠家選擇的技術(shù)棧為時(shí)延更低的RTMP和HTTP FLV方式。
海外的技術(shù)棧選擇和國內(nèi)有一些不同，因?yàn)楹Ｍ庖紤]大量web端客戶，低時(shí)延傳輸技術(shù)基本以CMAF格式為基礎(chǔ)。目前有三類技術(shù)：分別是DASH LL、LLHLS和LHLS?；谶@個(gè)技術(shù)棧E2E時(shí)延也可以做到5s以內(nèi)。
OTT個(gè)人直播體驗(yàn)，還有一個(gè)非常重要的點(diǎn)就是上行推流的穩(wěn)定性，因?yàn)橐坏┩屏髻|(zhì)量不好，全網(wǎng)的觀看質(zhì)量都會(huì)下降。目前推流協(xié)議主要有三類：分別是RTMP、SRT和RIST，其中RTMP是主流，優(yōu)勢是：成熟、穩(wěn)定、生態(tài)好，各類編碼工具基本都支持。SRT和RIST是基于UDP傳輸，主要優(yōu)勢是：長距離傳輸（例如：跨洋）、大碼率傳輸、弱網(wǎng)傳輸。另外相較于TCP層的擁塞算法優(yōu)化，SRT和RIST可以在應(yīng)用層優(yōu)化傳輸算法，更新比較方便。一些大型跨洋直播的第一公里推流會(huì)使用這類協(xié)議。
SRT 有相對成熟的開源社區(qū)支持。RIST只定義了標(biāo)準(zhǔn)化的語法，允許實(shí)現(xiàn)廠家在此基礎(chǔ)上進(jìn)行算法創(chuàng)新，而又不影響互相操作。
3. RTC
隨著疫情的持續(xù)，實(shí)時(shí)互動(dòng)類需求快速爆發(fā)，RTC技術(shù)在文娛、直播連麥、在線教育、在線會(huì)議、醫(yī)療金融等場景下，有較為廣泛的應(yīng)用。
3.1 RTC 架構(gòu)的選擇
RTC 主要有MESH、SFU、MCU三類架構(gòu)，MESH架構(gòu)的優(yōu)勢是簡單，不需要服務(wù)器參與。不足是當(dāng)與會(huì)人越來越多，對客戶端CPU、網(wǎng)絡(luò)資源的壓力就會(huì)越來越大，最大不超過6人同時(shí)與會(huì)，改進(jìn)方向是增加服務(wù)器，集中式架構(gòu)：SFU、MCU。
SFU服務(wù)器只負(fù)責(zé)轉(zhuǎn)發(fā)客戶端的數(shù)據(jù)，相比較MESH 的方式客戶端的上行帶寬壓力和CPU 資源消耗都大大降低了。不足是：下行依舊需要多條流。通過MCU在服務(wù)端混流、轉(zhuǎn)碼可以解決這個(gè)問題，不足是：服務(wù)器端計(jì)算壓力變大，畫面組合靈活性不夠，部署成本相較于SFU更高。
集中式SFU和MCU架構(gòu)適用小規(guī)模場景，例如傳統(tǒng)的企業(yè)內(nèi)部視頻通話這類的私域化場景。隨著公域化業(yè)務(wù)興起，集中式的SFU和MCU架構(gòu)就不能滿足要求了。舉個(gè)例子：一場會(huì)議其中用戶a、b在中國，用戶c、d在美國，集中式SFU如果部署在美國，則用戶a 和 b之間的通信效果不好；反之，則用戶c 和d之間的通信效果不好。
級聯(lián)式SFU 架構(gòu)，允許一個(gè)會(huì)議跨越多個(gè)SFU。級聯(lián)SFU 的優(yōu)勢是：允許會(huì)議加入方的人數(shù)動(dòng)態(tài)增長；通過合適的路由策略，降低跨國、跨運(yùn)營商傳輸帶寬成本；通過本地就近接入，使得終端可以與就近的SFU 進(jìn)行快速的錯(cuò)誤恢復(fù)，進(jìn)而改善實(shí)時(shí)音視頻通信的體驗(yàn)；架構(gòu)的演進(jìn)部分解決了RTC 業(yè)務(wù)公域化和規(guī)?；膯栴}。
而級聯(lián)SFU還有一部分問題沒有解決，例如：如何同時(shí)滿足同一房間內(nèi)，不同網(wǎng)絡(luò)情況觀眾的體驗(yàn)沒有問題，業(yè)界一般有2個(gè)技術(shù)：分別是SVC 和Simulcast。
Simulcast 也叫聯(lián)播，是由發(fā)送端向SFU 發(fā)送多個(gè)視頻流，質(zhì)量級別不同，SFU 根據(jù)網(wǎng)絡(luò)條件，屏幕布局等情況，決定發(fā)送哪條流給接收端。聯(lián)播優(yōu)勢是對傳統(tǒng)解碼器沒有額外的要求；劣勢是帶寬占用大。
SVC：即可伸縮編碼，以分層方式創(chuàng)建單個(gè)視頻流的編碼技術(shù)。每一層都增加了上一層的質(zhì)量，支持時(shí)域、空域、質(zhì)量域三種方式，SFU決定發(fā)送哪幾層流給接收端，目前主流是時(shí)域模式。優(yōu)勢是帶寬占用小；劣勢是只有部分解碼器支持SVC解碼。
對比OTT ABR在服務(wù)器側(cè)完成多碼率編碼，RTC在端測完成多碼率編碼，減少了一次轉(zhuǎn)碼，這樣可以降低E2E時(shí)延，這也是業(yè)務(wù)體驗(yàn)多樣化對技術(shù)選型帶來的不同。
因?yàn)镽TC 主要應(yīng)用于對低時(shí)延要求較高的業(yè)務(wù)場景，所以RTC采用了更為“積極” 的方式，應(yīng)對網(wǎng)絡(luò)變化，來改進(jìn)用戶體驗(yàn)。
首先RTC 從傳輸?shù)讓蛹夹g(shù)上就選擇了RTP over UDP 實(shí)時(shí)流媒體傳輸方式，這為后續(xù)積極的應(yīng)對策略提供了基礎(chǔ)。RTC共域傳輸較于IPTV私域傳輸更加豐富的丟包恢復(fù)手段，包括：FEC、NACK、RED、RTX和PLI等。
光有這些丟包恢復(fù)方法還不夠，客戶端還是需要有一定的Buffer，來抵抗網(wǎng)絡(luò)的抖動(dòng)和丟包，否則重傳之后，這1幀可能就過時(shí)了。但是增加buffer又會(huì)帶來時(shí)延的增加，所以我們的端側(cè)有一個(gè)動(dòng)態(tài)Jitter Buffer的算法，來解決丟包、亂序以及延遲到達(dá)的問題。同時(shí)也可以平滑顯示的幀率。
低時(shí)延核心的問題是避免網(wǎng)絡(luò)擁塞，一旦網(wǎng)絡(luò)中存在大量buffer，就會(huì)導(dǎo)致時(shí)延變大，這個(gè)時(shí)候就需要通過擁塞控制算法來解決。擁塞控制算法的目標(biāo)是：讓“發(fā)送速率” 逼近 “可用速率”，同時(shí)保持盡可能低的“隊(duì)列占用率”。
RMCAT是一個(gè)IETF小組；他們的工作內(nèi)容包括：定義需求；設(shè)計(jì)基于RTP的實(shí)時(shí)流媒體協(xié)議傳輸?shù)膿砣刂扑惴?。目前有三種RMCAT算法包括：GCC、NADA和SCReAM。其中GCC因?yàn)閼?yīng)用在Chrome瀏覽器上，是目前比較成熟的算法。包括GCC-REMB和新版本GCC-TFB。新版本的優(yōu)勢是：由一端來控制算法，有利于版本演進(jìn)，同時(shí)發(fā)端可以根據(jù)內(nèi)容屬性的不同，分配不同的帶寬進(jìn)行傳輸，更加靈活。
未來音視頻傳輸行業(yè)的洞察
1. 音視頻傳輸未來面臨三大挑戰(zhàn)
第一業(yè)務(wù)多。邊緣業(yè)務(wù)類型越來越多，從現(xiàn)在已經(jīng)成熟的下載、點(diǎn)播、直播、RTC，在到正在快速發(fā)展的云游戲、云XR等；同一節(jié)點(diǎn)部署不同類型的服務(wù)，包括緩存、推流、拉流、轉(zhuǎn)發(fā)、云渲染等；而煙囪式架構(gòu)面臨一系列問題：包括網(wǎng)絡(luò)、計(jì)算、存儲(chǔ)資源管理、差異化體驗(yàn)管理等。
第二要求高。新的媒體表現(xiàn)形式沉浸感更強(qiáng)，對音視頻傳輸?shù)囊蟾摺６疫@種提高是全方位的，主要包括：
提升帶寬：從1M到10M再到VR屏幕的100M。
降低時(shí)延：從直播的5s到RTC的400ms到云游戲100ms再到云XR的20ms；同時(shí)新的業(yè)務(wù)也產(chǎn)生了對新的時(shí)延類型的要求，例如云游戲要解決的input lag，云XR在3dof場景下要解決rotation lag和在6dof場景下的position lag問題。
提高幀率：從平面視頻的30P，到未來的60P，甚至120P，而VR內(nèi)容60P只是起步，90P算及格。未來如果需要滿足人眼極限要求的VR內(nèi)容每秒需要大約2Gbps的數(shù)據(jù)。這還是經(jīng)過壓縮之后的碼率。
增強(qiáng)渲染：從平面視頻的2D渲染，到VR中的3D渲染、空間音頻渲染，這樣沉浸感才能更強(qiáng)。
平面視頻的主要指標(biāo)：包括秒開率，卡頓率、和播放成功率，而影響VR沉浸感體驗(yàn)的因素則更多。
第三發(fā)展快。在行業(yè)競爭日益激烈的環(huán)境下，要求企業(yè)需要有差異化體驗(yàn)，客觀上要求創(chuàng)新速度快，技術(shù)發(fā)展快， 在這個(gè)過程中我們的客戶遇到的痛點(diǎn)有：
開發(fā)工作量大，適配不同終端機(jī)型
耗電快，圖形處理為計(jì)算密集型處理
手機(jī)型號有要求，部分用戶無法享受
安裝包變大，影響app推廣和用戶下載體驗(yàn)
2. 華為云新媒體網(wǎng)絡(luò)價(jià)值主張
如何應(yīng)對這三大挑戰(zhàn)，我們提出了華為云新媒體網(wǎng)絡(luò)的價(jià)值主張。愿景是打造一張面向娛樂視頻、通信視頻、行業(yè)視頻的新媒體網(wǎng)絡(luò)，來滿足視頻高效傳輸?shù)囊蟆?/p>
其中我們的價(jià)值主張是：
低時(shí)延、全互聯(lián)、大規(guī)模實(shí)時(shí)音視頻分發(fā)
高通量、沉浸式新媒體傳輸
端、邊、云協(xié)同創(chuàng)新，靈活定義媒體處理流水線
新媒體網(wǎng)絡(luò)同時(shí)具備以下特征：
扁平化：1套網(wǎng)絡(luò)，1套架構(gòu)
廣覆蓋：全網(wǎng)2500+節(jié)點(diǎn)，全球覆蓋
全場景：使能娛樂、通信、行業(yè)視頻等各種場景
多連接：實(shí)現(xiàn)海量的、面向不同類型終端的連接
超體驗(yàn)：從1080P至8K，毫秒級時(shí)延，極致抗丟包
低時(shí)延：利用邊緣云技術(shù)，支持毫秒級的低時(shí)延應(yīng)用
3. 價(jià)值主張案例
低時(shí)延、全互聯(lián)、大規(guī)模實(shí)時(shí)音視頻分發(fā)
基于華為云的新媒體網(wǎng)絡(luò)，我們支持在線教育技術(shù)升級，打造更優(yōu)的在線教育平臺(tái)。在傳統(tǒng)架構(gòu)下，實(shí)現(xiàn)低時(shí)延互動(dòng)與大規(guī)模分發(fā)需要用到2個(gè)產(chǎn)品RTC 和CDN，這樣存在4個(gè)問題：
CDN和RTC兩個(gè)網(wǎng)絡(luò)，問題定界困難，問題修復(fù)周期長。
旁路直播引入延時(shí)，學(xué)生在觀看和互動(dòng)間切換存在3-5秒以上時(shí)差。
互動(dòng)直播和直播兩套SDK，對接困難。
針對普通直播觀看學(xué)生，無法實(shí)現(xiàn)共享屏幕與教師畫面同步傳輸。
基于華為云新媒體網(wǎng)絡(luò)的架構(gòu)，只需要一個(gè)華為RTC服務(wù)，就可以實(shí)現(xiàn)原來2個(gè)產(chǎn)品的功能，主要優(yōu)勢有：
一套實(shí)時(shí)音視頻網(wǎng)絡(luò)，問題定位簡單，降低運(yùn)維成本。
可支持學(xué)生在互動(dòng)和觀看間自由無感切換，無時(shí)延。
統(tǒng)一架構(gòu)，一套SDK覆蓋連麥，推流和播放，對接簡單，資源包消耗小。
可保證共享屏幕與教師畫面同步性。
高通量、沉浸式新媒體傳輸
華為云的Tile wise Streaming技術(shù)，解決了目前VR產(chǎn)業(yè)的兩大難題：第一VR頭盔算力有限，無法支持VR 8K內(nèi)容的硬件要求；第二VR內(nèi)容全量傳輸，帶寬消耗過大。
我們的解決方案是：將原始8K VR內(nèi)容進(jìn)行預(yù)處理，轉(zhuǎn)碼成兩條流，一個(gè)是4K全景背景流和一個(gè)高清前景流。同時(shí)對高清前景流進(jìn)行Tile劃分。播放器會(huì)根據(jù)用戶的視場角，選擇對應(yīng)的高清晰Tile分塊進(jìn)行下載，同時(shí)下載4K全景背景流，用于轉(zhuǎn)頭時(shí)短暫使用。
這個(gè)方案的優(yōu)勢是：4k硬解終端可以播放8K VR內(nèi)容；網(wǎng)絡(luò)下載帶寬降低75%；我們通過端邊云協(xié)同，實(shí)現(xiàn)了用戶轉(zhuǎn)頭到高清畫面展示的延遲只需要100-200ms，人眼幾乎無法感知。
端、邊、云協(xié)同創(chuàng)新，靈活定義媒體處理流水線
目前斗魚攜手華為云打造云端特效市場，用算力釋放想象力，打造更佳互動(dòng)的直播體驗(yàn)。
這個(gè)方案的有幾大優(yōu)勢：第一、為直播品臺(tái)提供了創(chuàng)新的玩法：特效直接在上云運(yùn)行、APP消耗更低，主播再也不用擔(dān)心電池問題；云端服務(wù)器性能強(qiáng)勁，特效效果更優(yōu)，高級特效算法選擇更多。
第二點(diǎn)形成算法生態(tài)：云端算法生態(tài)聚集各種特效，例如:不同臉型、膚色的美顏效果；創(chuàng)新周期更短，主播可以更快體驗(yàn)到各種特效。
第三點(diǎn)優(yōu)質(zhì)的體驗(yàn)：依托華為云新媒體網(wǎng)絡(luò)，基于華為RTC的實(shí)時(shí)美顏，時(shí)延可以做到低于400ms；新特效實(shí)時(shí)生效，無需更新APP。
總結(jié)? ? ?
視頻發(fā)展的三個(gè)特點(diǎn)：
數(shù)字傳輸IP化
視頻分發(fā)公域化
業(yè)務(wù)體驗(yàn)多樣化
視頻傳輸技術(shù)選型的三大法寶：
業(yè)務(wù)需求：規(guī)模、質(zhì)量、時(shí)延
視頻分發(fā)網(wǎng)絡(luò)：公域、私域
技術(shù)實(shí)施代價(jià)：技術(shù)復(fù)雜度、成本、生態(tài)
華為云新媒體網(wǎng)絡(luò)的三大價(jià)值主張：
低時(shí)延、全互聯(lián)、大規(guī)模實(shí)時(shí)音視頻分發(fā)；
高通量、沉浸式新媒體傳輸
端、邊、云協(xié)同創(chuàng)新，靈活定義媒體處理流水線
本次的分享就到這里，感謝各位專家的聆聽，希望未來能夠與大家在工作中進(jìn)行深入的交流與合作，謝謝大家。
總結(jié)
以上是生活随笔為你收集整理的视频传输面临的挑战和解决之道的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： LiveVideoStackCon 20
- 下一篇： AMD收购Xilinx、Zoom为全体用