本文由京東智聯(lián)云的魏偉在LiveVideoStackCon2020線上峰會(huì)的演講內(nèi)容整理而成，他會(huì)從邏輯結(jié)構(gòu)、系統(tǒng)業(yè)務(wù)流程和弱網(wǎng)增強(qiáng)等方面介紹京東智聯(lián)云在RTC方面所做的工作。

1. 簡介 1.1 視頻形態(tài)

視頻形態(tài)可歸為非實(shí)時(shí)視頻（點(diǎn)播視頻）和準(zhǔn)實(shí)時(shí)視頻（直播視頻）。從本質(zhì)上來看，任何一個(gè)視頻系統(tǒng)的完成都是由采集、編碼、連接和播放這一完整的端到端流程組成，不管是點(diǎn)播、直播還是RTC的視頻，它們底層的視頻算法都是基于H.264/H.265等編碼協(xié)議，并基于一些網(wǎng)絡(luò)封裝協(xié)議，包括一些基礎(chǔ)的傳輸網(wǎng)絡(luò)來實(shí)現(xiàn)視頻的連接，而且視頻的采集和播放都使用相同的技術(shù)框架。雖然視頻的形態(tài)非常多，應(yīng)用場景有直播帶貨、娛樂視頻、監(jiān)控視頻、會(huì)議視頻等各種各樣的視頻形態(tài)，其本質(zhì)都是建立在視頻的采集、編碼、連接、傳輸這些基礎(chǔ)的邏輯之上。 但發(fā)展到RTC階段之后，我個(gè)人理解是時(shí)間和空間的轉(zhuǎn)化，設(shè)定在一個(gè)幾乎沒有延遲的條件下，完成一個(gè)視頻的采集、編碼、傳輸和播放，并且不限制視頻形態(tài)和視頻應(yīng)用場景的變化，其底層的視頻編解碼技術(shù)，包括承載視頻的傳輸網(wǎng)絡(luò)都是一樣的。 京東智聯(lián)云在過去兩年內(nèi)推出了很多的視頻底層技術(shù)方面的一些成果，也推出了視頻點(diǎn)播和直播的一些產(chǎn)品，包括在視頻壓縮方面的一些黑科技和在CDN上的建設(shè)和儲(chǔ)備。 1.2 JRTC系統(tǒng)畫像

到達(dá)RTC階段，我們理解的RTC系統(tǒng)畫像并不是一個(gè)獨(dú)立的RTC系統(tǒng)，我們希望建立的RTC系統(tǒng)不僅僅服務(wù)于視頻會(huì)議、娛樂視頻的視頻連麥，除了最基本的實(shí)時(shí)音視頻通信之外，還能支持多種協(xié)議的接入、異構(gòu)系統(tǒng)之間的互通以及實(shí)現(xiàn)不同業(yè)務(wù)之間的接入和資源共享。在點(diǎn)播、直播以及監(jiān)控系統(tǒng)之上構(gòu)建一個(gè)融合的RTC平臺(tái)，實(shí)現(xiàn)業(yè)務(wù)、資源和技術(shù)的融合。我們希望能用一套系統(tǒng)，把包括點(diǎn)播、直播、監(jiān)控等系統(tǒng)在內(nèi)的資源、內(nèi)容和設(shè)備進(jìn)行統(tǒng)一管理，并且在這一整套技術(shù)架構(gòu)之上能實(shí)現(xiàn)資源的共用、系統(tǒng)的統(tǒng)一調(diào)度，還能提供更好的服務(wù)形態(tài)以及更低的使用成本。同時(shí)利用CDN節(jié)點(diǎn)提升邊緣的接入能力，使用戶能夠就近接入，降低延時(shí)，并且充分利用閑置資源來降低系統(tǒng)服務(wù)成本。 所以京東智聯(lián)云RTC是建立在現(xiàn)有視頻點(diǎn)播、直播和媒體處理系統(tǒng)之上的一個(gè)綜合的融合性平臺(tái)。該平臺(tái)可以實(shí)現(xiàn)視頻點(diǎn)播、直播、通信和媒體處理等多種業(yè)務(wù)形態(tài)的融合，也能共用一些現(xiàn)已投入使用的基礎(chǔ)視頻處理資源。視頻編解碼技術(shù)、網(wǎng)絡(luò)傳輸技術(shù)、資源調(diào)度使用技術(shù)都可以在該平臺(tái)上進(jìn)行綜合管理和使用，最終達(dá)到易用、好用、低價(jià)的產(chǎn)品進(jìn)行交互。 1.3 內(nèi)容融合與統(tǒng)一交換

在我們構(gòu)建的RTC平臺(tái)之上可以支持基礎(chǔ)RTC的接入，但其中有一些私有化的信令或基于Websocket連接，數(shù)據(jù)分發(fā)傳輸可以支持基于TCP或UDP協(xié)議，也支持直播、點(diǎn)播系統(tǒng)，常見的有RTMP協(xié)議、HLS協(xié)議或者基于HTTP、 TCP傳輸?shù)囊曨l協(xié)議。其次，還有一些視頻會(huì)議的系統(tǒng)，其中間有支持SIP或者323的協(xié)議接入。監(jiān)控終端支持的主流協(xié)議是GB-28181。 我們會(huì)搭建一個(gè)統(tǒng)一的媒體協(xié)議的網(wǎng)關(guān)系統(tǒng)，在統(tǒng)一的網(wǎng)關(guān)系統(tǒng)下將視頻從多種多樣的封裝協(xié)議或者網(wǎng)絡(luò)協(xié)議中抽離出來。抽取底層視頻格式的網(wǎng)絡(luò)和信令層，得到底層儲(chǔ)存的H.264或者AAC的音視頻流，其中可以調(diào)用媒體處理的能力對(duì)這些媒體進(jìn)行處理，再通過媒體傳輸網(wǎng)關(guān)在不同的系統(tǒng)之間進(jìn)行對(duì)應(yīng)系統(tǒng)的網(wǎng)絡(luò)封裝或者信令的控制，最終達(dá)到在不同的異構(gòu)系統(tǒng)之間實(shí)現(xiàn)媒體內(nèi)容的融合或者媒體內(nèi)容的統(tǒng)一交換。

2. JRTC介紹 2.1 JRTC邏輯結(jié)構(gòu)

上圖展示了JRTC系統(tǒng)的邏輯結(jié)構(gòu)，包括最底層的云資源，當(dāng)然現(xiàn)在談到云資源一定會(huì)提到邊緣計(jì)算資源。在云資源上部有多種SDK，包括移動(dòng)端和H5端等，而且SDK不僅有通信的能力，同時(shí)也有一些業(yè)務(wù)屬性。接入層接入JRTC客戶端、直播流、SIP、監(jiān)控等終端，提供信令、媒體、混流服務(wù)。包括網(wǎng)絡(luò)鏈路選擇、傳輸效率提升以及糾錯(cuò)容錯(cuò)能力都是在分發(fā)層實(shí)現(xiàn)。控制和平臺(tái)對(duì)接層更多是實(shí)現(xiàn)不同業(yè)務(wù)之間的連接。頂部是SaaS應(yīng)用，包括視頻會(huì)議、直播連麥等不同應(yīng)用的使用場景。 2.2 JRTC組網(wǎng)圖

融合JRTC系統(tǒng)采用分布式、分層架構(gòu)，利用數(shù)十萬個(gè)邊緣可控節(jié)點(diǎn)提供服務(wù)。圖中左邊是能力增強(qiáng)部分，它融合基礎(chǔ)網(wǎng)絡(luò)能力、CDN分發(fā)能力、媒體處理能力、MCU、多碼率的對(duì)齊和處理、壓縮和轉(zhuǎn)碼、SVC等能力都在媒體處理集訓(xùn)里完成。AI能力平臺(tái)提供采集端的美顏和濾鏡、播放端的超分、平臺(tái)端的內(nèi)容審核、AI結(jié)構(gòu)化處理等能力。 圖右邊是內(nèi)容交換部分，包括視頻監(jiān)控平臺(tái)、直播系統(tǒng)、視頻會(huì)議系統(tǒng)。不管是技術(shù)能力還是異構(gòu)系統(tǒng)都會(huì)在RTC平臺(tái)通過接入網(wǎng)關(guān)融合在一起，再由統(tǒng)一的媒體處理和AI能力進(jìn)行處理，最后再對(duì)外暴露出是面向娛樂視頻、教育視頻、會(huì)議視頻場景等各種低延遲場景下的具體應(yīng)用。 2.3 JRTC開放SDK集

JRTC開放SDK集可以提供基礎(chǔ)通信能力、業(yè)務(wù)應(yīng)用能力兩個(gè)層面的SDK。 JRTC Client Core SDK，即核心SDK，它提供音視頻通信、消息通信、媒體處理控制等基礎(chǔ)能力。此外，我們面向不同的業(yè)務(wù)應(yīng)用場景提供不同的SDK，包括視頻會(huì)議、直播連麥、視頻客服、低延時(shí)直播等SDK。 用戶基于實(shí)際情況，可選擇業(yè)務(wù)應(yīng)用SDK或視音頻基礎(chǔ)通信能力SDK，滿足快速集成和深度定制的不同需求。提供滿足PC、移動(dòng)、專業(yè)設(shè)備系統(tǒng)運(yùn)行的SDK版本，主要包括Android、iOS、WIN、 H5、MAC、Electron平臺(tái)。 2.4 RTC系統(tǒng)業(yè)務(wù)流程

上圖介紹了RTC系統(tǒng)的系統(tǒng)業(yè)務(wù)流程。首先，用戶、監(jiān)控?cái)z像頭、SIP終端首先定位到接入服務(wù)器，并建立連接，登記到控制層。當(dāng)用戶發(fā)布流到接入服務(wù)器，接入服務(wù)器同步流信息到控制層。其次，訂閱流用戶向控制層查詢流信息，通過中轉(zhuǎn)Relay服務(wù)，將流從源服務(wù)器調(diào)度到接入服務(wù)器并訂閱。用戶由接入服務(wù)器向媒體處理發(fā)起混流請求，混流服務(wù)通過Relay拉取多條源流經(jīng)過混合后，推送到直播系統(tǒng)。最后，用戶向直播系統(tǒng)發(fā)起拉直播流操作，經(jīng)過拉流網(wǎng)關(guān)協(xié)議轉(zhuǎn)換后，將流返送到RTC系統(tǒng)。監(jiān)控等其他系統(tǒng)，通過控制層交換內(nèi)容列表，通過Relay交換媒體。 整個(gè)運(yùn)作模式就是發(fā)布和訂閱模式，在和其他系統(tǒng)應(yīng)用時(shí)也能以比較低的延時(shí)實(shí)現(xiàn)在直播系統(tǒng)和其他異構(gòu)系統(tǒng)之間的交互。 2.5 基于優(yōu)選路徑中轉(zhuǎn)調(diào)度

這部分是關(guān)于路徑選擇的簡單描述。左圖中，靜態(tài)路由有運(yùn)營商匹配、區(qū)域臨近匹配、跨網(wǎng)搭橋處理。其次是基于探測的動(dòng)態(tài)監(jiān)測，每一個(gè)節(jié)點(diǎn)會(huì)探測與其臨近的或者需要連接的一些點(diǎn)的網(wǎng)絡(luò)聯(lián)通性。整個(gè)路徑選擇會(huì)基于實(shí)時(shí)探測的故障點(diǎn)檢查、包括擁堵檢查，以最優(yōu)路徑的方式建立一個(gè)端到端的連接。 右圖中可以看到有海量的節(jié)點(diǎn)需要通信，同時(shí)也有海量的節(jié)點(diǎn)作為網(wǎng)絡(luò)隧道的承載點(diǎn)來幫助建立更可靠的連接。基于靜態(tài)路由和動(dòng)態(tài)檢測的方式可以從海量的節(jié)點(diǎn)中（包括邊緣點(diǎn)）來選擇一些比較優(yōu)秀的節(jié)點(diǎn)以構(gòu)建一個(gè)優(yōu)選的路徑發(fā)布。該優(yōu)選的路徑分發(fā)網(wǎng)絡(luò)，在新加入的節(jié)點(diǎn)需要建立通信的時(shí)候可以承載網(wǎng)絡(luò)隧道和穿透的能力。 上部是路徑?jīng)Q策，歷史通信記錄、路由分析、IP的判決結(jié)果都會(huì)在最上層的路徑?jīng)Q策系統(tǒng)里，結(jié)合歷史實(shí)時(shí)通信結(jié)果、靜態(tài)路由配置情況和實(shí)時(shí)探測的情況，形成優(yōu)選的實(shí)時(shí)傳輸網(wǎng)絡(luò)。 2.6 多路徑并行傳輸

在傳統(tǒng)設(shè)備中用得比較多是是多路徑并行傳輸，但在真正的RTC系統(tǒng)中反而用的就較少。因?yàn)楝F(xiàn)在在很多的移動(dòng)終端會(huì)有同時(shí)連接WiFi和4/5G信號(hào)的情況，包括手機(jī)支持雙4G信號(hào)的連接。這種情況下我們就可利用雙鏈路的雙路徑并行傳輸來提升傳輸效率和傳輸?shù)目煽啃浴１热缡謾C(jī)上有電信和聯(lián)通兩張卡，如果同時(shí)使用電信和聯(lián)通兩個(gè)卡去發(fā)送和接收數(shù)據(jù)，就會(huì)有更好的帶寬和網(wǎng)絡(luò)保證。 如何將數(shù)據(jù)在兩個(gè)網(wǎng)絡(luò)之間進(jìn)行調(diào)配以及如何在兩個(gè)鏈路之間進(jìn)行動(dòng)態(tài)的冗余都有比較大的挑戰(zhàn)。我們有一個(gè)比較簡單的方式是先把所有的網(wǎng)卡列舉出來并激活，再進(jìn)行處理數(shù)據(jù)和執(zhí)行并行的數(shù)據(jù)傳輸。單鏈路會(huì)有主鏈路來傳輸音視頻數(shù)據(jù)，并調(diào)用輔助鏈路處理音頻數(shù)據(jù)，以此來提升音頻的可靠性。在RTC環(huán)境里，如果視頻產(chǎn)生一些丟包但能保證音頻的話，這對(duì)通信質(zhì)量也會(huì)有比較好的保障。 2.7 弱網(wǎng)增強(qiáng)

弱網(wǎng)增強(qiáng)采用視音頻編解碼、傳輸控制、糾錯(cuò)算法不同手段綜合實(shí)現(xiàn)。在視音頻編輯碼方面有SVC|Simulcast、碼率自適應(yīng)和AI超分。在RTC或數(shù)據(jù)通信的場景下，經(jīng)常會(huì)發(fā)生網(wǎng)絡(luò)帶寬的波動(dòng)情況，這時(shí)候就需要?jiǎng)討B(tài)地調(diào)整音視頻編解碼的實(shí)時(shí)碼率，如果這時(shí)的音視頻編解碼實(shí)時(shí)碼率能夠和實(shí)時(shí)傳輸帶寬達(dá)到最佳匹配的話，一方面可以最充分的利用網(wǎng)絡(luò)帶寬，另一方面也可以保證最佳的視頻效果（即不會(huì)產(chǎn)生卡頓也不會(huì)降低視頻質(zhì)量）。但這是比較有挑戰(zhàn)性的，因?yàn)榫W(wǎng)絡(luò)傳輸和視頻編碼是兩個(gè)非常獨(dú)立的模塊，如何將這兩個(gè)模塊結(jié)合在一起聯(lián)動(dòng)工作，首先要讓音視頻的Codec能夠支持動(dòng)態(tài)地調(diào)整碼率、分辨率、幀率等一些基礎(chǔ)邏輯，這樣才有可能通過實(shí)時(shí)網(wǎng)絡(luò)探測的方式將實(shí)時(shí)網(wǎng)絡(luò)情況傳送給音視頻的Codec，再實(shí)現(xiàn)音視頻碼率和帶寬的自適應(yīng)，不浪費(fèi)網(wǎng)絡(luò)帶寬并且提升視頻質(zhì)量。 AI超分是在播放端實(shí)現(xiàn)的，這項(xiàng)技術(shù)在RTC場景下顯得尤為重要，因?yàn)镽TC場景很多時(shí)候是在跨網(wǎng)或者跨地域的連接下使用的，不像現(xiàn)在的點(diǎn)播、直播系統(tǒng)可以通過CDN加速，通過網(wǎng)絡(luò)連接提升和保障視頻的下載速度。大部分RTC都是基于點(diǎn)對(duì)點(diǎn)的連接，而且兩點(diǎn)之間有可能跨越了非常復(fù)雜的網(wǎng)絡(luò)情況，這直接導(dǎo)致在大部分的RTC情況下，音視頻的帶寬都比較低，此時(shí)想要做到1080p的傳輸是比較艱難的，并且很容易因?yàn)閬G包造成卡頓的情況。AI超分在其中一個(gè)很重要的作用是可以在整個(gè)RTC鏈路上以一個(gè)較低的分辨率、碼率進(jìn)行通信，在終端播放時(shí)通過超分的方式增強(qiáng)視頻的主觀觀看效果。如果提供1.2M的RTC網(wǎng)絡(luò)通信能力（ RTC的場景以靜態(tài)居多），做1080p的數(shù)據(jù)傳輸是有一定風(fēng)險(xiǎn)的。1.2M做1080p傳輸?shù)膱D像質(zhì)量不會(huì)太高，但在這種情況下結(jié)合AI超分，就可以在RTC鏈路上只跑一個(gè)540P 1M的視頻流，再在終端通過超分把它提升到1080p，這樣就可以以一個(gè)比較穩(wěn)定且比較低的帶寬占用，實(shí)現(xiàn)比較好的最終使用效果。 傳輸控制方面有多源匯聚、多鏈路并傳、緩存自適應(yīng)、帶寬估算、平滑發(fā)送。糾錯(cuò)算法方面有FEC前向糾錯(cuò)、主/被動(dòng)重傳、錯(cuò)峰多副本、自適應(yīng)糾錯(cuò)策略。 2.8 編解碼

在編解碼部分我將介紹一些基礎(chǔ)的視頻能力，它們都會(huì)在MCU中使用。其中端上也會(huì)有去噪、銳化、AI增強(qiáng)、動(dòng)態(tài)編碼、ROI編碼。ROI編碼會(huì)增強(qiáng)畫面中的人臉部分，并弱化畫面中的非人臉部分，在比較小的網(wǎng)絡(luò)帶寬環(huán)境下提供更好的主觀效果。 在極速轉(zhuǎn)碼方面有解碼復(fù)用、隨源快轉(zhuǎn)、源流水印、倍速轉(zhuǎn)碼。 終端超分方面有實(shí)時(shí)超分、2×超分、渲染處理、細(xì)節(jié)增強(qiáng)。 多碼率切換方面有幀對(duì)齊、無縫切換、直播切換。 舒適音頻方面有降噪、齊量、均衡、舒適。 質(zhì)量檢測方面有文件合規(guī)性、黑屏、靜幀、花屏、靜音。 以上是我們在視頻方面對(duì)RTC進(jìn)行的一些工作。 2.9 移動(dòng)端增強(qiáng)超分

上圖的右半部分是移動(dòng)端增強(qiáng)超分的流程圖，在視頻解碼之后會(huì)得到Y(jié)UV圖像，并將它在低分辨率的情況下進(jìn)行亮度的增強(qiáng)、超分增強(qiáng)、色度增強(qiáng)、色度上采樣增強(qiáng)等處理，以及高分辨率的一些重建工作。整個(gè)過程在實(shí)際的測試效果中，雖然大家都懷疑從540P到1080P超分的效果是不是不太好，但實(shí)際上1M 540P的主觀感受基本上可以接近2.5M 1080P的效果。 我們也針對(duì)移動(dòng)端上功耗的問題進(jìn)行了很多優(yōu)化，主要是用GPU加速的方式來實(shí)現(xiàn)超分的卷積框架。相比于屏幕顯示的功耗，超分算法的功耗是比較低的。 2.10 邊緣節(jié)點(diǎn)管理

因?yàn)镽TC需要就近的連接才能提供更低的延時(shí)和更多的路由選擇，但不管是公有云機(jī)房還是CDN等地方，我們都有一些RTC能力的部署。上圖左部分列舉的一個(gè)簡單對(duì)比，CDN節(jié)點(diǎn)的量級(jí)一般在千級(jí)別，可用性也比較高，全國各省都會(huì)分布幾個(gè)機(jī)房點(diǎn)。但實(shí)際上最終要接入網(wǎng)絡(luò)的設(shè)備數(shù)可能是億級(jí)別的量級(jí)，設(shè)備接入并通過網(wǎng)絡(luò)進(jìn)行數(shù)據(jù)通信。我們將邊緣計(jì)算層定義成Edge層，這一層是百萬級(jí)別的設(shè)備，但這些設(shè)備沒有CDN節(jié)點(diǎn)那么高的可靠性，處理能力也不如CDN節(jié)點(diǎn)里部署的服務(wù)器那么強(qiáng)，但它就是利用邊緣閑置的一些計(jì)算資源來提供一些分布式的計(jì)算和連接能力。因?yàn)椴渴鹪谶吘壍倪@些計(jì)算資源也具備計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)通信的能力，雖然每一個(gè)點(diǎn)的絕對(duì)計(jì)算能力都不是非常的強(qiáng)，但它可以在低延時(shí)通信領(lǐng)域里作為一個(gè)數(shù)據(jù)流轉(zhuǎn)發(fā)或者提供比較小的數(shù)據(jù)存儲(chǔ)和連接能力。從整體上來說，未來的網(wǎng)絡(luò)一定是從“云-管-端”的架構(gòu)發(fā)展到“云-管-邊-端”，在云的邊緣會(huì)有一層百萬量級(jí)的邊緣設(shè)備作為邊緣計(jì)算節(jié)點(diǎn)來對(duì)外提供服務(wù)。 這些節(jié)點(diǎn)一方面跟核心控制平臺(tái)有連接，它有自我升級(jí)和管理的能力，通過平臺(tái)的控制邏輯下發(fā)指令，這些節(jié)點(diǎn)就可以進(jìn)行自我管理和自我凈化。 自我管理包括自身計(jì)算能力的分配、自有存儲(chǔ)空間的管理等。因?yàn)檫@些節(jié)點(diǎn)有網(wǎng)絡(luò)能力之后，可以探測自身的一些網(wǎng)絡(luò)連接狀況，管理熱點(diǎn)文件，并根據(jù)自身的存儲(chǔ)空間進(jìn)行整個(gè)全生命周期的管理。而且，每個(gè)節(jié)點(diǎn)都是一個(gè)自制的節(jié)點(diǎn)，來完成自己存儲(chǔ)空間、臨近節(jié)點(diǎn)路由和網(wǎng)絡(luò)連通性的管理，并將自身情況數(shù)據(jù)上報(bào)給平臺(tái)管理層，平臺(tái)管理層可以結(jié)合每一個(gè)節(jié)點(diǎn)的自制能力進(jìn)行全局的管理。每個(gè)節(jié)點(diǎn)也可以實(shí)現(xiàn)按照平臺(tái)邏輯做數(shù)據(jù)防護(hù)和加密，整個(gè)“云-管-邊-端”架構(gòu)也是京東云RTC基礎(chǔ)運(yùn)行的物理存在環(huán)境。