導(dǎo)讀：移動(dòng)互聯(lián)網(wǎng)的興起為人類信息傳播帶來(lái)了更便捷的通道、更立體的視角和更豐富的選擇。視頻直播等多媒體通信技術(shù)在新的時(shí)代背景下逐漸嶄露頭角并不斷滲入到人們的日常生活中，以提高人們的信息傳輸效率、降低信息傳輸成本。

文｜鄭文彬

網(wǎng)易云信云平臺(tái)融合通信技術(shù)團(tuán)隊(duì)負(fù)責(zé)人/架構(gòu)師

直播概覽

進(jìn)入后疫情時(shí)代，視頻直播技術(shù)在眾多行業(yè)市場(chǎng)的應(yīng)用日益廣泛，也吸引了眾多的從業(yè)者投入到相關(guān)技術(shù)領(lǐng)域的學(xué)習(xí)、研究和應(yīng)用開發(fā)中來(lái)。一方面，在電商營(yíng)銷、社交娛樂(lè)、在線教育、金融服務(wù)等垂直行業(yè)，視頻直播技術(shù)能夠推動(dòng)企業(yè)生產(chǎn)經(jīng)營(yíng)活動(dòng)進(jìn)一步提升價(jià)值、控制成本，幫助企業(yè)實(shí)現(xiàn)開源節(jié)流的同時(shí)加速推動(dòng)企業(yè)進(jìn)入數(shù)字化轉(zhuǎn)型的快車道；另一方面，5G 網(wǎng)絡(luò)基礎(chǔ)設(shè)施的加速建設(shè)、云計(jì)算和人工智能技術(shù)的大幅推廣進(jìn)一步催化和加速了視頻直播產(chǎn)業(yè)的升級(jí)和發(fā)展壯大。如圖1所示，在未來(lái)的三年里，國(guó)內(nèi)企業(yè)直播服務(wù)市場(chǎng)的規(guī)模預(yù)計(jì)仍將延續(xù)較高的增長(zhǎng)勢(shì)頭。

?直播架構(gòu)?

對(duì)組織者而言，準(zhǔn)備一場(chǎng)直播活動(dòng)，所需要的工具和依賴的平臺(tái)既可以很簡(jiǎn)單，也可能非常復(fù)雜。

在簡(jiǎn)單使用場(chǎng)景下，主播端借助常見(jiàn)的推流工具（如 OBS）就可以實(shí)現(xiàn)音視頻數(shù)據(jù)的采集和編碼，并將媒體流推送到云端，而播放端也可以借助常見(jiàn)的媒體播放工具（如 VLC）直接拉流播放，如圖2所示。

但是，在某些特定的直播場(chǎng)景，組織者可能會(huì)對(duì)直播活動(dòng)的規(guī)模和品質(zhì)提出多樣性的要求。最典型的需求是支持媒體流的多個(gè)碼率輸出以適配不同觀眾所處環(huán)境的網(wǎng)絡(luò)狀況，其次是支持大量觀眾同時(shí)在線觀看。甚至在一些大型直播活動(dòng)中，比如網(wǎng)絡(luò)在線演唱會(huì)，活動(dòng)方希望能夠?qū)顒?dòng)現(xiàn)場(chǎng)的多個(gè)媒體源或攝像機(jī)位進(jìn)行直播切換控制。為了支持這些復(fù)雜的直播特性和需求，開發(fā)者需要引入更復(fù)雜的直播服務(wù)架構(gòu)，如圖3所示。

?直播流程?

一個(gè)典型的視頻直播完整流程如圖4所示。

主播端負(fù)責(zé)音視頻數(shù)據(jù)的采集、預(yù)處理、編碼壓縮，并將封裝后的媒體流推送到云端的直播媒體網(wǎng)關(guān)。

直播媒體網(wǎng)關(guān)在接收到來(lái)自主播端的媒體流之后，將其轉(zhuǎn)發(fā)給媒體處理服務(wù)（MPS）進(jìn)行云端的媒體加工處理，比如添加水印、轉(zhuǎn)碼等等。處理后的媒體流通過(guò)直播媒體網(wǎng)關(guān)轉(zhuǎn)推到 CDN 網(wǎng)絡(luò)，或者通過(guò) CDN 回源拉流的方式，進(jìn)行媒體流的分發(fā)。

最后，播放端通過(guò)訪問(wèn)直播 URL 地址從 CDN 的下行邊緣節(jié)點(diǎn)拉取指定的媒體流，對(duì)其進(jìn)行解碼并做必要的后處理，然后再輸出到渲染模塊進(jìn)行播放。

?QoS 指標(biāo)?

在一場(chǎng)直播活動(dòng)中，影響觀眾直播體驗(yàn)（QoE）的因素有哪些呢？下面我們介紹在視頻直播過(guò)程中需要關(guān)注的一些 QoS 指標(biāo)。

• 首屏?xí)r間：即播放器從發(fā)起直播請(qǐng)求到顯示第一幀視頻圖像所需要花費(fèi)的時(shí)間。這個(gè)時(shí)間越短，用戶體驗(yàn)越好。

• 尺寸：即視頻圖像的分辨率（長(zhǎng)度x高度，單位為像素值）。一般情況下視頻的尺寸越大，清晰度越高。

• 幀率：又叫幀速度，即每秒鐘采集的視頻圖像的幀數(shù)量（Frame per Second，fps）。一般而言，視頻幀率越高，播放流暢度也越高，但是較高的幀率也導(dǎo)致了較大的數(shù)據(jù)傳輸量。

• 碼率：即視頻采樣數(shù)據(jù)經(jīng)過(guò)編碼壓縮后，在網(wǎng)絡(luò)上正常傳輸?shù)乃俾?#xff08;Bitrate）。在同等編碼條件下，碼率越高，意味著傳輸?shù)拿襟w數(shù)據(jù)量越大，因此在音視頻的清晰度和流暢度上會(huì)帶來(lái)更好的播放體驗(yàn)，另一方面，高碼率的媒體流將對(duì)傳輸網(wǎng)絡(luò)的帶寬帶來(lái)更大的壓力。

• 延遲：即一幀視頻圖像從開始采集到最終播放，期間所花費(fèi)的時(shí)間。延遲越小，意味著視頻直播的實(shí)時(shí)性越高。從上面的直播流程可以看出，視頻直播從媒體數(shù)據(jù)采集到最后渲染播放經(jīng)歷了很多環(huán)節(jié)，所以影響延遲的因素也很多。

• 抖動(dòng)：即視頻數(shù)據(jù)包在傳輸過(guò)程中由于網(wǎng)絡(luò)擁塞、傳輸緩存或路由變化導(dǎo)致偏離正常傳輸延時(shí)的現(xiàn)象。媒體傳輸?shù)亩秳?dòng)問(wèn)題會(huì)影響到播放的連貫性，引起卡頓等不良體驗(yàn)。

關(guān)鍵技術(shù)

視頻直播的關(guān)鍵技術(shù)主要涉及媒體處理和媒體傳輸兩個(gè)方面。從視頻直播技術(shù)應(yīng)用伊始，針對(duì)這兩個(gè)技術(shù)領(lǐng)域展開的一系列的創(chuàng)新研究和優(yōu)化升級(jí)就從未停止。

?媒體處理?

結(jié)合視頻直播業(yè)務(wù)的特點(diǎn)，我們根據(jù)直播流程中的不同階段將媒體處理分為三大類：主播端媒體處理、云端媒體處理和播放端媒體處理。主播端媒體處理又可細(xì)分為預(yù)處理和編碼，而播放端媒體處理又可細(xì)分為解碼和后處理。

主播端處理

常規(guī)的圖像增強(qiáng)處理方法在視頻預(yù)處理環(huán)節(jié)依然發(fā)揮著主流的作用，比如降噪、補(bǔ)償、平滑、銳化、圖像增強(qiáng)（飽和度/對(duì)比度）等等。隨著視頻業(yè)務(wù)在社會(huì)生活中應(yīng)用場(chǎng)景的不斷拓展，一些有趣的媒體應(yīng)用處理技術(shù)也在視頻直播場(chǎng)景中逐漸普及開來(lái)，比如美顏、瘦臉、換臉、打碼、背景虛化/替換、AR/VR 等等。

另一方面，如何提高視頻編碼壓縮效率是業(yè)界面臨的主要挑戰(zhàn)之一。視頻編碼本質(zhì)上是一種有損壓縮過(guò)程。通常情況下，為了獲得更低的視頻傳輸碼率，編碼器需要增大圖像編碼壓縮率，而這勢(shì)必引起更多視頻圖像細(xì)節(jié)的失真和損耗，從而導(dǎo)致視頻播放質(zhì)量的下降。所以，如何在獲得更低傳輸碼率的基礎(chǔ)上保證足夠好的視頻播放用戶體驗(yàn)，成了圖像處理領(lǐng)域研究者和視頻引擎技術(shù)開發(fā)人員需要研究的重要課題。近些年來(lái)，人們嘗試結(jié)合人眼視覺(jué)系統(tǒng)（Human Visual System, HVS）對(duì)事物感知存在內(nèi)容偏好的生理特性，將人工智能技術(shù)特別是神經(jīng)網(wǎng)絡(luò)和深度學(xué)習(xí)方法引入到了視頻圖像預(yù)處理和編碼壓縮算法中，并在基于顯著性的視頻預(yù)處理、基于紋理分析和綜合的預(yù)處理、端到端神經(jīng)視頻編碼等研究方向上[2]均取得了一些積極的進(jìn)展。

網(wǎng)易云信技術(shù)團(tuán)隊(duì)投入了大量研發(fā)資源，致力于 HVS 和 AI 技術(shù)相結(jié)合的視頻圖像處理算法和應(yīng)用的研究工作，而且在圖像紋理增強(qiáng) 、顯著性檢測(cè)處理和 JND 感知編碼技術(shù)等方面的開發(fā)已經(jīng)跨出了卓有成效的一步。該系列技術(shù)研究的成果正在逐步應(yīng)用到云信的直播、點(diǎn)播和 RTC 等業(yè)務(wù)中，為云信的客戶帶來(lái)更好的播放體驗(yàn)和更高的業(yè)務(wù)價(jià)值。

圖5 網(wǎng)易云信視頻引擎優(yōu)化效果

云端處理

除了主播端的媒體處理之外，在很多情況下需要在云端對(duì)媒體流做進(jìn)一步的加工處理，以滿足直播業(yè)務(wù)的特定需求。比如為了輸出單路媒體流需要將多路媒體源進(jìn)行混屏混音、為了支持多種碼率或編碼格式需要進(jìn)行轉(zhuǎn)碼（轉(zhuǎn)換分辨率、碼率或編碼格式）等，甚至為了支持一些個(gè)性化的需求還要實(shí)現(xiàn)添加水印、生成字幕、數(shù)據(jù)加密等擴(kuò)展能力。如前所述，這塊兒加工處理的工作是由云端的媒體處理服務(wù)（MPS）負(fù)責(zé)實(shí)現(xiàn)的。

網(wǎng)易云信搭建了一套全新的 MPS 服務(wù)，支持跨區(qū)域的分布式彈性部署和媒體源的就近接入，為云信的音視頻業(yè)務(wù)提供了豐富的可定制化的實(shí)時(shí)媒體處理能力。在不久的將來(lái)，我們希望能將這些媒體處理能力進(jìn)一步開放給外部客戶和合作伙伴，提供多種服務(wù)接口，以支持云信生態(tài)系統(tǒng)上的客戶和合作伙伴更好地發(fā)展他們的多媒體業(yè)務(wù)。

網(wǎng)易云信 MPS 設(shè)計(jì)實(shí)現(xiàn)了一個(gè)實(shí)時(shí)的媒體處理流水線模型，如圖6所示。該模型封裝并打通了媒體流接收、發(fā)送、編解碼和加工處理等全流程的各個(gè)環(huán)節(jié)，大幅提升了媒體數(shù)據(jù)收發(fā)和處理的效率，并提供了靈活便捷的媒體處理擴(kuò)展能力。

播放端處理

播放端的視頻處理方法包括兩大類，即圖像增強(qiáng)技術(shù)和超分辨率技術(shù)（Super Resolution，SR）。這兩類圖像處理技術(shù)的一個(gè)顯性區(qū)別是，圖像增強(qiáng)技術(shù)不會(huì)改變視頻圖像的分辨率，而超分技術(shù)則主要通過(guò)算法推理提升圖像分辨率的方式，達(dá)到優(yōu)化視覺(jué)效果的目的。

基于 AI 的超分技術(shù)相比傳統(tǒng)的基于差值或重構(gòu)的計(jì)算方法，在超分效果上具有巨大的優(yōu)勢(shì)。不過(guò)在多媒體實(shí)時(shí)傳輸應(yīng)用領(lǐng)域，AI 超分技術(shù)也面臨著兩大挑戰(zhàn)：一方面，網(wǎng)絡(luò)視頻流通常都是經(jīng)過(guò)大幅壓縮編碼后的媒體數(shù)據(jù)流，這種有損壓縮很容易造成圖像紋理細(xì)節(jié)的失真和畫質(zhì)的嚴(yán)重退化，如果將這類圖像直接進(jìn)行拉伸，壓縮損失很容易被放大，因此超分的效果將大打折扣；另一方面， 當(dāng)今流行的 AI 超分算法，如各種深度卷積神經(jīng)網(wǎng)絡(luò)算法，對(duì)播放設(shè)備的計(jì)算能力提出了更高的要求。由于播放設(shè)備機(jī)型品類繁多、算力良莠不齊，播放端的媒體處理能力和播放實(shí)時(shí)性都受到了較大的影響。常規(guī)的解法是為播放端 SDK 設(shè)置一份機(jī)型白名單，SDK 只能在指定型號(hào)的設(shè)備上對(duì)媒體數(shù)據(jù)進(jìn)行渲染播放前的有限優(yōu)化處理，而對(duì)于算力要求較高的 AI 超分技術(shù)，則幾乎絕跡于各種智能移動(dòng)播放設(shè)備。

網(wǎng)易云信提出了一個(gè)基于編碼損失復(fù)原的視頻超分算法方案，采用數(shù)據(jù)驅(qū)動(dòng)和網(wǎng)絡(luò)設(shè)計(jì)雙管齊下的策略，通過(guò)數(shù)據(jù)處理模擬失真場(chǎng)景，從模型設(shè)計(jì)到工程落地進(jìn)行了多重優(yōu)化，對(duì)制約 AI 超分技術(shù)的兩大問(wèn)題進(jìn)行了一定的突破，在模型實(shí)時(shí)性和真實(shí)場(chǎng)景超分效果方面均取得了不錯(cuò)的效果。該算法具有模型小、參數(shù)少、實(shí)時(shí)性好等特點(diǎn)，能夠適配更多的播放設(shè)備。我們通過(guò)圖8可以直觀地對(duì)比一下在視頻圖像細(xì)節(jié)上的算法優(yōu)化效果（左圖為傳統(tǒng)超分方法，右圖為網(wǎng)易云信 AI 超分算法）。

?媒體傳輸?

如果將媒體處理過(guò)程比喻為烹飪一道美食，那么傳輸技術(shù)則是為了把這道美食及時(shí)而又安全地派送到觀眾手中。媒體傳輸技術(shù)涉及到兩個(gè)細(xì)分領(lǐng)域，即傳輸協(xié)議的選型和傳輸網(wǎng)絡(luò)的保障。

傳輸協(xié)議

視頻直播常見(jiàn)的媒體傳輸協(xié)議規(guī)范包括 RTMP、 HTTP+FLV 以及基于 HTTP Adaptive Streaming（HAS）技術(shù)的協(xié)議，如 Apple HLS、Adobe HDS、MPEG DASH 等。一般而言，RTMP 和 HTTP+FLV 相比 HAS 協(xié)議可以獲得更低的直播延遲，但是 HAS 協(xié)議具備更好的網(wǎng)絡(luò)自適應(yīng)能力，可以針對(duì)網(wǎng)絡(luò)可用帶寬的實(shí)時(shí)動(dòng)態(tài)變化選擇傳輸相應(yīng)碼率的媒體流片段。近幾年來(lái)，HAS 協(xié)議設(shè)計(jì)者們陸續(xù)推出了各協(xié)議的低延時(shí)版本，如 LL-HLS（Low-Latency HLS）[3][4]和 LL-DASH（Low-Latency DASH）[5]，這些改進(jìn)版本在理想情況下可以將直播的端到端延遲縮短到2秒左右。

從網(wǎng)絡(luò)協(xié)議四層模型來(lái)看，以上這些應(yīng)用層的直播協(xié)議都是基于傳輸層的 TCP 協(xié)議實(shí)現(xiàn)的。然而，TCP 協(xié)議在當(dāng)今的多媒體通信應(yīng)用領(lǐng)域存在著諸多缺陷，如建連握手時(shí)間長(zhǎng)、擁塞控制不靈活、隊(duì)頭阻塞問(wèn)題嚴(yán)重、抗弱網(wǎng)能力差等等。為了解決 TCP 協(xié)議的這些問(wèn)題，一個(gè)全新的運(yùn)行于用戶態(tài)的傳輸層標(biāo)準(zhǔn)協(xié)議 QUIC[6]應(yīng)運(yùn)而生。QUIC 協(xié)議設(shè)計(jì)了一個(gè)基于 UDP 的多路復(fù)用且安全可靠的傳輸機(jī)制，為應(yīng)用程序提供了區(qū)別于傳統(tǒng)流式傳輸協(xié)議的重要特性：

• 快速的連接握手。支持 0~1RTT 建立連接

• 連接多路復(fù)用。支持連接內(nèi)的 multiple streams，避免了隊(duì)頭阻塞問(wèn)題

• 連接遷移。通過(guò) Connection ID 綁定連接，解決了 NAT 映射失效和移動(dòng)設(shè)備多網(wǎng)切換等問(wèn)題

• 靈活的擁塞控制機(jī)制。在用戶空間（而不是內(nèi)核空間）實(shí)現(xiàn)，可結(jié)合應(yīng)用場(chǎng)景靈活配置和調(diào)優(yōu)

另一方面，在多媒體數(shù)據(jù)傳輸如視頻直播的應(yīng)用場(chǎng)景，選擇合適的擁塞控制算法對(duì)提升傳輸效率、降低傳輸延時(shí)尤為重要。Google 公司在2016年提出了一個(gè)全新的擁塞控制算法：BBR（Bottleneck Bandwidth and Round-trip time）[7]。相比基于丟包檢測(cè)的傳統(tǒng)擁塞控制算法（如當(dāng)前 Linux 內(nèi)核默認(rèn)的擁塞控制算法 CUBIC）而言，BBR 基于傳輸帶寬和往返時(shí)延估計(jì)的擁塞發(fā)現(xiàn)機(jī)制更加與時(shí)俱進(jìn)，更適用于新時(shí)代的互聯(lián)網(wǎng)基礎(chǔ)設(shè)施部署環(huán)境。

圖9顯示了一個(gè) TCP 連接中從一端向另一端發(fā)送數(shù)據(jù)時(shí)，數(shù)據(jù)傳輸速率和 RTT 與 inflight 數(shù)據(jù)量（已發(fā)出尚未收到 ack 的數(shù)據(jù)量總和）之間的關(guān)系。在網(wǎng)絡(luò)擁塞尚未發(fā)生時(shí)（即 app-limited 階段），隨著數(shù)據(jù)傳輸速率的持續(xù)提升，RTT 可以保持穩(wěn)定。當(dāng) inflight 數(shù)據(jù)量增加到 BDP（傳輸瓶頸帶寬 BtlBw 與往返時(shí)延 RTprop 的乘積）之后，擁塞開始發(fā)生，瓶頸路由節(jié)點(diǎn)開始緩存數(shù)據(jù)，RTT 開始變大，數(shù)據(jù)傳輸由此進(jìn)入到 bandwidth-limited 階段。當(dāng) inflight 數(shù)據(jù)量持續(xù)增加到 BDP+BtlneckBufSize 之后，意味著 bottleneck buffer 已滿，只能進(jìn)行丟包處理，數(shù)據(jù)傳輸也隨即進(jìn)入到 buffer-limited 階段。

顯而易見(jiàn)，理想的情況下我們希望在 inflight 數(shù)據(jù)量恰好達(dá)到 BDP 時(shí)就可以檢測(cè)到網(wǎng)絡(luò)擁塞的發(fā)生。然而，基于丟包檢測(cè)的 CC 算法需要等到 buffer-limited 階段（即丟包開始發(fā)生時(shí)）才能發(fā)現(xiàn)這一點(diǎn)。這將帶來(lái)兩個(gè)問(wèn)題：當(dāng) BtlneckBufSize 比較大時(shí)，因 bottleneck buffer 溢出丟包才確定擁塞很容易引起高延遲、高抖動(dòng)等 bufferbloat 問(wèn)題；而當(dāng) BtlneckBufSize 較小時(shí)，丟包不一定就意味著擁塞的發(fā)生，此時(shí)的誤判將會(huì)促使發(fā)送端減小發(fā)送窗口，從而造成傳輸吞吐量遲遲無(wú)法提升上去。BBR 的設(shè)計(jì)思路就是在數(shù)據(jù)傳輸過(guò)程中通過(guò)對(duì) BtlBw 和 RTprop 進(jìn)行持續(xù)地探測(cè)和更新評(píng)估，計(jì)算出動(dòng)態(tài)的 BDP 值，從而達(dá)到發(fā)現(xiàn)網(wǎng)絡(luò)擁塞的目的，并依此進(jìn)行數(shù)據(jù)發(fā)送節(jié)奏的控制。BBR 算法在 GCP（Google Cloud Platform）上的部署應(yīng)用為 Google 服務(wù)在優(yōu)化傳輸延遲、提升吞吐量和 QoE 等方面帶來(lái)了大量的收益[8]。

QUIC 協(xié)議和 BBR 算法的珠聯(lián)璧合為業(yè)務(wù)應(yīng)用的優(yōu)化帶來(lái)了新的選擇。網(wǎng)易云信視頻直播系統(tǒng)在推流端和拉流端同時(shí)集成了對(duì) QUIC 協(xié)議和 BBR 算法的支持，在直播活動(dòng)上下行的第一公里或最后一公里通過(guò) RTMP over QUIC 進(jìn)行媒體流的傳輸能夠有效地改善媒體數(shù)據(jù)的傳輸效率以及抗弱網(wǎng)和抗抖動(dòng)的能力，進(jìn)一步提升了視頻直播的用戶體驗(yàn)。

傳輸網(wǎng)絡(luò)

常見(jiàn)的視頻直播傳輸網(wǎng)絡(luò)環(huán)境包括公共互聯(lián)網(wǎng)（公網(wǎng)）、專線網(wǎng)絡(luò)、CDN 網(wǎng)絡(luò)和RTN 網(wǎng)絡(luò)等。

公網(wǎng)是運(yùn)營(yíng)成本最低的傳輸網(wǎng)絡(luò)，但是它的缺點(diǎn)也很明顯，那就是網(wǎng)絡(luò)可靠性（帶寬、延遲、抖動(dòng)等）缺乏保障，所以通常被用于直播的最初或最后一公里鏈路。

使用專線網(wǎng)絡(luò)可以解決網(wǎng)絡(luò)可靠性的問(wèn)題，但是缺點(diǎn)是使用成本較高。

CDN（Content Delivery Network）是一種在互聯(lián)網(wǎng)中被廣泛使用的網(wǎng)絡(luò)基礎(chǔ)設(shè)施。在視頻直播應(yīng)用場(chǎng)景中，CDN 可以為直播用戶提供廉價(jià)的跨區(qū)域的大規(guī)模的數(shù)據(jù)分發(fā)能力，它的主要問(wèn)題是傳輸延遲較大（秒級(jí)）且各 CDN 廠商的服務(wù)能力參差不齊。

RTN（Realtime Transmission Network），顧名思義，就是設(shè)計(jì)用于提供實(shí)時(shí)數(shù)據(jù)傳輸能力的大規(guī)模分布式網(wǎng)絡(luò)傳輸系統(tǒng)。RTN 基于公網(wǎng)基礎(chǔ)設(shè)施，通過(guò)純軟件方式實(shí)現(xiàn)，不依賴硬件也不借助專線網(wǎng)絡(luò)進(jìn)行優(yōu)化，而能夠?qū)⒍说蕉说难舆t控制在百毫秒級(jí)別。另一方面，為了實(shí)現(xiàn) RTN 實(shí)時(shí)穩(wěn)定的數(shù)據(jù)傳輸能力，RTN 廠商不僅要投入研發(fā)資源進(jìn)行路線探測(cè)、路由調(diào)度等各種算法的持續(xù)升級(jí)調(diào)優(yōu)，也需要在網(wǎng)絡(luò)節(jié)點(diǎn)部署、帶寬租用等方面投入大量的資金，其投入成本堪比 CDN。

網(wǎng)易云信自研推出了新一代大規(guī)模分布式傳輸網(wǎng)絡(luò)，即WE-CAN（Communications Acceleration Network）。WE-CAN是一個(gè)架設(shè)在公網(wǎng)之上，通過(guò)智能鏈路探測(cè)算法和智能路由調(diào)度策略將數(shù)據(jù)從全球任意端點(diǎn)快速、穩(wěn)定、高效地發(fā)送到任意目標(biāo)端點(diǎn)的多功能實(shí)時(shí)傳輸網(wǎng)絡(luò)系統(tǒng)，如圖10所示。

相比傳統(tǒng)的 RTN 網(wǎng)絡(luò)，WE-CAN 的傳輸速度更快，傳輸成本更低，適用場(chǎng)景也更加豐富。WE-CAN 不僅能夠?qū)?RTC 媒體流進(jìn)行高到達(dá)、低延遲的傳輸，也能對(duì)視頻直播流進(jìn)行大規(guī)模、低延遲的分發(fā)，還能對(duì)信令、即時(shí)消息（IM）和其他業(yè)務(wù)數(shù)據(jù)進(jìn)行可靠傳輸。WE-CAN 的媒體數(shù)據(jù)傳輸在全球范圍內(nèi)延遲不超過(guò) 250ms，而優(yōu)質(zhì)傳輸率則達(dá)到了 99% 以上。

通過(guò)集成 WE-CAN 和國(guó)內(nèi)外眾多主流的 CDN 廠商，網(wǎng)易云信設(shè)計(jì)實(shí)現(xiàn)了一套基于推流線路智能切換和融合 CDN 智能調(diào)度的高可用直播服務(wù)框架，如圖11所示。

在傳輸網(wǎng)絡(luò)上，網(wǎng)易云信直播服務(wù)具備以下幾個(gè)主要特點(diǎn)：

• 上行推流多線路智能切換。?通過(guò)主備推流多條線路的自動(dòng)識(shí)別和切換機(jī)制，保障了上行推流的高可用；

• 下行融合多CDN智能調(diào)度。根據(jù)實(shí)時(shí)的 CDN QoS 監(jiān)控機(jī)制進(jìn)行播放拉流的調(diào)度分配，保障了下行拉流的最優(yōu)解；

• 端到端的全鏈路數(shù)據(jù)安全。除了常規(guī)的傳輸層加密、防盜鏈和推拉流黑白名單等安全應(yīng)用，還支持在媒體封裝層進(jìn)行加密，該層加密對(duì)媒體傳輸協(xié)議和網(wǎng)絡(luò)透明，且只有授權(quán)的客戶端才能進(jìn)行解密播放；

• 支持低延時(shí)直播應(yīng)用場(chǎng)景。通過(guò)集成 WE-CAN 網(wǎng)絡(luò)和最后一公里的 WebRTC 技術(shù)，可以做到1秒以內(nèi)的端到端直播延遲；

• 千萬(wàn)級(jí)用戶并發(fā)在線能力。得益于融合 CDN 解決方案的落地和 WE-CAN 系統(tǒng)的大規(guī)模部署節(jié)點(diǎn)覆蓋，網(wǎng)易云信已經(jīng)具備了支持千萬(wàn)量級(jí)大型直播活動(dòng)的技術(shù)能力。

技術(shù)趨勢(shì)

如同自然界萬(wàn)物生靈周而復(fù)始、生生不息地繁衍進(jìn)化，視頻直播技術(shù)也在不斷地迭代演進(jìn)發(fā)展中。近年來(lái)，隨著視頻直播應(yīng)用場(chǎng)景的不斷拓展和深入，相關(guān)技術(shù)的研究和應(yīng)用方向呈現(xiàn)出兩個(gè)明顯的發(fā)展趨勢(shì)，一個(gè)是低碼高清，另一個(gè)是降低延遲。?

?低碼高清?

所謂低碼高清技術(shù)，就是在更低碼率的傳輸條件下為用戶呈現(xiàn)出更清晰流暢的視頻播放效果。“既要馬兒跑得快，又要馬兒不吃草”是驅(qū)動(dòng)低碼高清技術(shù)不斷向前發(fā)展的永恒的追求。通過(guò)低碼高清技術(shù)的應(yīng)用實(shí)踐，視頻直播活動(dòng)可以適配更差的用戶網(wǎng)絡(luò)帶寬狀況，覆蓋更多的觀眾群體，帶來(lái)更好的視頻播放體驗(yàn)，同時(shí)，也能大幅降低企業(yè)的媒體數(shù)據(jù)傳輸成本。

網(wǎng)易云信在視頻圖像預(yù)處理、視覺(jué)感知編碼和 AI 超分等低碼高清技術(shù)領(lǐng)域的研發(fā)方面已經(jīng)邁出了堅(jiān)實(shí)的一步，相關(guān)技術(shù)成果通過(guò)持續(xù)的迭代優(yōu)化正在逐步落地應(yīng)用到 RTC、直播和點(diǎn)播等業(yè)務(wù)中來(lái)。

?降低延遲?

在某些特定的視頻直播場(chǎng)景中，主播和觀眾之間除了要推送直播媒體流之外，還需要傳遞實(shí)時(shí)的互動(dòng)信令，如在線搶答、文字互動(dòng)、搶紅包等，這對(duì)媒體流的傳輸延遲提出了更高的要求。傳統(tǒng)的直播技術(shù)動(dòng)輒5秒以上的端到端延遲已經(jīng)無(wú)法滿足這類場(chǎng)景的互動(dòng)需求，即便是 LL-HLS 和 LL-DASH 技術(shù)想方設(shè)法將延遲縮短到最小2秒左右，也難以帶來(lái)令人滿意的用戶體驗(yàn)。真正的低延時(shí)直播應(yīng)用需要將端對(duì)端的延遲控制在2秒以內(nèi)，甚至在1秒左右。

業(yè)界在降低傳輸延時(shí)技術(shù)方向上進(jìn)行了諸多探索和嘗試，引入了 RTN 并應(yīng)用了一些基于 UDP 的實(shí)時(shí)數(shù)據(jù)傳輸協(xié)議，如 QUIC、SRT、RTP 等，如圖12所示。目前主流的低延時(shí)直播技術(shù)，在推流端主要通過(guò) RTMP（或 RTMP over QUIC）進(jìn)行推流，在云端通過(guò) RTN 網(wǎng)絡(luò)將媒體流快速分發(fā)到各個(gè)下行邊緣節(jié)點(diǎn)，最后利用 RTC 技術(shù)將媒體流實(shí)時(shí)傳輸?shù)讲シ哦?#xff0c;完成最后一公里的投遞。

網(wǎng)易云信在低延時(shí)直播技術(shù)領(lǐng)域也進(jìn)行了布局，通過(guò)集成 WE-CAN 網(wǎng)絡(luò)和 NE-RTC 技術(shù)，網(wǎng)易云信直播服務(wù)可以提供1秒以內(nèi)的端到端直播延遲能力。

總結(jié)展望

我們生活在一個(gè)數(shù)字化的時(shí)代，視頻直播技術(shù)依然處于信息傳播應(yīng)用普及的黃金賽道，發(fā)展前景向好。將來(lái)隨著新業(yè)務(wù)應(yīng)用形態(tài)的不斷涌現(xiàn)，必將產(chǎn)生新的技術(shù)訴求及其應(yīng)對(duì)之道。

網(wǎng)易云信在視頻直播技術(shù)領(lǐng)域積累了豐富的經(jīng)驗(yàn)，特別在大型直播高可用解決方案、分布式媒體處理服務(wù)、低碼高清直播和低延時(shí)直播等技術(shù)方向逐漸建立起了自身的核心技術(shù)競(jìng)爭(zhēng)力。網(wǎng)易云信將繼續(xù)順應(yīng)技術(shù)發(fā)展趨勢(shì)，持續(xù)優(yōu)化打磨媒體處理和傳輸能力，持續(xù)研究創(chuàng)新技術(shù)，以更好地助力客戶和合作伙伴內(nèi)生成長(zhǎng)、創(chuàng)造更多美好的價(jià)值。

?作者介紹?

鄭文彬，?網(wǎng)易云信云平臺(tái)融合通信技術(shù)團(tuán)隊(duì)負(fù)責(zé)人、架構(gòu)師，在實(shí)時(shí)多媒體處理和傳輸技術(shù)、網(wǎng)絡(luò)會(huì)議和視頻直播系統(tǒng)等技術(shù)領(lǐng)域深耕多年。

?參考文獻(xiàn)?

• [1] 艾瑞咨詢. 2021年中國(guó)企業(yè)直播服務(wù)行業(yè)發(fā)展研究報(bào)告.

• [2] Dandan Ding, Zhan Ma, Di Chen, et al. Advances in Video Compression System Using Deep Neural Network: A Review and Case Studies.

• [3] APPLE.COM. Enabling Low-Latency HLS. https://developer.apple.com/documentation/http_live_streaming/enabling_low-latency_hls?

• [4] Roger Pantos. HLS 2nd Edition. https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis?

• [5] DASH-IF. Low-latency Modes for DASH. https://dashif.org/docs/CR-Low-Latency-Live-r8.pdf?

• [6] Jana Iyengar, Martin Thomson. QUIC: A UDP-Based Multiplexed and Secure Transport. https://datatracker.ietf.org/doc/html/rfc9000?

• [7] Neal Cardwell, Yuchung Cheng, C. Stephen Gunn, et al. BBR: Congestion-Based Congestion Control. https://dl.acm.org/doi/pdf/10.1145/3012426.3022184

• [8] GOOGLE.COM. TCP BBR congestion control comes to GCP – your Internet just got faster. https://cloud.google.com/blog/products/networking/tcp-bbr-congestion-control-comes-to-gcp-your-internet-just-got-faster

?相關(guān)閱讀推薦?

• 技術(shù)干貨 | 網(wǎng)易云信本地服務(wù)端集群錄制探索與實(shí)踐

• 技術(shù)干貨 | WebRTC 系列之 GPU 方案的探索與落地

• 技術(shù)干貨 | 實(shí)時(shí)音視頻性能評(píng)價(jià)實(shí)踐
  

總結(jié)

以上是生活随笔為你收集整理的技术干货 | 视频直播关键技术和趋势的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。