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

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

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

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

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

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

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

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

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

上圖介紹了RTC系統(tǒng)的系統(tǒng)業(yè)務(wù)流程。首先，用戶、監(jiān)控攝像頭、SIP終端首先定位到接入服務(wù)器，并建立連接，登記到控制層。當用戶發(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交換媒體。 整個運作模式就是發(fā)布和訂閱模式，在和其他系統(tǒng)應(yīng)用時也能以比較低的延時實現(xiàn)在直播系統(tǒng)和其他異構(gòu)系統(tǒng)之間的交互。 2.5 基于優(yōu)選路徑中轉(zhuǎn)調(diào)度

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

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

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

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

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

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