本文由京東智聯云的魏偉在LiveVideoStackCon2020線上峰會的演講內容整理而成，他會從邏輯結構、系統業務流程和弱網增強等方面介紹京東智聯云在RTC方面所做的工作。

文 / 魏偉

整理 / LiveVideoStack

1. 簡介

1.1 視頻形態

視頻形態可歸為非實時視頻（點播視頻）和準實時視頻（直播視頻）。從本質上來看，任何一個視頻系統的完成都是由采集、編碼、連接和播放這一完整的端到端流程組成，不管是點播、直播還是RTC的視頻，它們底層的視頻算法都是基于H.264/H.265等編碼協議，并基于一些網絡封裝協議，包括一些基礎的傳輸網絡來實現視頻的連接，而且視頻的采集和播放都使用相同的技術框架。雖然視頻的形態非常多，應用場景有直播帶貨、娛樂視頻、監控視頻、會議視頻等各種各樣的視頻形態，其本質都是建立在視頻的采集、編碼、連接、傳輸這些基礎的邏輯之上。

但發展到RTC階段之后，我個人理解是時間和空間的轉化，設定在一個幾乎沒有延遲的條件下，完成一個視頻的采集、編碼、傳輸和播放，并且不限制視頻形態和視頻應用場景的變化，其底層的視頻編解碼技術，包括承載視頻的傳輸網絡都是一樣的。

京東智聯云在過去兩年內推出了很多的視頻底層技術方面的一些成果，也推出了視頻點播和直播的一些產品，包括在視頻壓縮方面的一些黑科技和在CDN上的建設和儲備。

1.2 JRTC系統畫像

到達RTC階段，我們理解的RTC系統畫像并不是一個獨立的RTC系統，我們希望建立的RTC系統不僅僅服務于視頻會議、娛樂視頻的視頻連麥，除了最基本的實時音視頻通信之外，還能支持多種協議的接入、異構系統之間的互通以及實現不同業務之間的接入和資源共享。在點播、直播以及監控系統之上構建一個融合的RTC平臺，實現業務、資源和技術的融合。我們希望能用一套系統，把包括點播、直播、監控等系統在內的資源、內容和設備進行統一管理，并且在這一整套技術架構之上能實現資源的共用、系統的統一調度，還能提供更好的服務形態以及更低的使用成本。同時利用CDN節點提升邊緣的接入能力，使用戶能夠就近接入，降低延時，并且充分利用閑置資源來降低系統服務成本。

所以京東智聯云RTC是建立在現有視頻點播、直播和媒體處理系統之上的一個綜合的融合性平臺。該平臺可以實現視頻點播、直播、通信和媒體處理等多種業務形態的融合，也能共用一些現已投入使用的基礎視頻處理資源。視頻編解碼技術、網絡傳輸技術、資源調度使用技術都可以在該平臺上進行綜合管理和使用，最終達到易用、好用、低價的產品進行交互。

1.3 內容融合與統一交換

在我們構建的RTC平臺之上可以支持基礎RTC的接入，但其中有一些私有化的信令或基于Websocket連接，數據分發傳輸可以支持基于TCP或UDP協議，也支持直播、點播系統，常見的有RTMP協議、HLS協議或者基于HTTP、 TCP傳輸的視頻協議。其次，還有一些視頻會議的系統，其中間有支持SIP或者323的協議接入。監控終端支持的主流協議是GB-28181。

我們會搭建一個統一的媒體協議的網關系統，在統一的網關系統下將視頻從多種多樣的封裝協議或者網絡協議中抽離出來。抽取底層視頻格式的網絡和信令層，得到底層儲存的H.264或者AAC的音視頻流，其中可以調用媒體處理的能力對這些媒體進行處理，再通過媒體傳輸網關在不同的系統之間進行對應系統的網絡封裝或者信令的控制，最終達到在不同的異構系統之間實現媒體內容的融合或者媒體內容的統一交換。

2. JRTC介紹

2.1 JRTC邏輯結構

上圖展示了JRTC系統的邏輯結構，包括最底層的云資源，當然現在談到云資源一定會提到邊緣計算資源。在云資源上部有多種SDK，包括移動端和H5端等，而且SDK不僅有通信的能力，同時也有一些業務屬性。接入層接入JRTC客戶端、直播流、SIP、監控等終端，提供信令、媒體、混流服務。包括網絡鏈路選擇、傳輸效率提升以及糾錯容錯能力都是在分發層實現。控制和平臺對接層更多是實現不同業務之間的連接。頂部是SaaS應用，包括視頻會議、直播連麥等不同應用的使用場景。

2.2 JRTC組網圖

融合JRTC系統采用分布式、分層架構，利用數十萬個邊緣可控節點提供服務。圖中左邊是能力增強部分，它融合基礎網絡能力、CDN分發能力、媒體處理能力、MCU、多碼率的對齊和處理、壓縮和轉碼、SVC等能力都在媒體處理集訓里完成。AI能力平臺提供采集端的美顏和濾鏡、播放端的超分、平臺端的內容審核、AI結構化處理等能力。

圖右邊是內容交換部分，包括視頻監控平臺、直播系統、視頻會議系統。不管是技術能力還是異構系統都會在RTC平臺通過接入網關融合在一起，再由統一的媒體處理和AI能力進行處理，最后再對外暴露出是面向娛樂視頻、教育視頻、會議視頻場景等各種低延遲場景下的具體應用。

2.3 JRTC開放SDK集

JRTC開放SDK集可以提供基礎通信能力、業務應用能力兩個層面的SDK。

JRTC Client ?Core SDK，即核心SDK，它提供音視頻通信、消息通信、媒體處理控制等基礎能力。此外，我們面向不同的業務應用場景提供不同的SDK，包括視頻會議、直播連麥、視頻客服、低延時直播等SDK。

用戶基于實際情況，可選擇業務應用SDK或視音頻基礎通信能力SDK，滿足快速集成和深度定制的不同需求。提供滿足PC、移動、專業設備系統運行的SDK版本，主要包括Android、iOS、WIN、 H5、MAC、Electron平臺。

2.4 RTC系統業務流程

上圖介紹了RTC系統的系統業務流程。首先，用戶、監控攝像頭、SIP終端首先定位到接入服務器，并建立連接，登記到控制層。當用戶發布流到接入服務器，接入服務器同步流信息到控制層。其次，訂閱流用戶向控制層查詢流信息，通過中轉Relay服務，將流從源服務器調度到接入服務器并訂閱。用戶由接入服務器向媒體處理發起混流請求，混流服務通過Relay拉取多條源流經過混合后，推送到直播系統。最后，用戶向直播系統發起拉直播流操作，經過拉流網關協議轉換后，將流返送到RTC系統。監控等其他系統，通過控制層交換內容列表，通過Relay交換媒體。

整個運作模式就是發布和訂閱模式，在和其他系統應用時也能以比較低的延時實現在直播系統和其他異構系統之間的交互。

2.5 基于優選路徑中轉調度

這部分是關于路徑選擇的簡單描述。左圖中，靜態路由有運營商匹配、區域臨近匹配、跨網搭橋處理。其次是基于探測的動態監測，每一個節點會探測與其臨近的或者需要連接的一些點的網絡聯通性。整個路徑選擇會基于實時探測的故障點檢查、包括擁堵檢查，以最優路徑的方式建立一個端到端的連接。

右圖中可以看到有海量的節點需要通信，同時也有海量的節點作為網絡隧道的承載點來幫助建立更可靠的連接。基于靜態路由和動態檢測的方式可以從海量的節點中（包括邊緣點）來選擇一些比較優秀的節點以構建一個優選的路徑發布。該優選的路徑分發網絡，在新加入的節點需要建立通信的時候可以承載網絡隧道和穿透的能力。

上部是路徑決策，歷史通信記錄、路由分析、IP的判決結果都會在最上層的路徑決策系統里，結合歷史實時通信結果、靜態路由配置情況和實時探測的情況，形成優選的實時傳輸網絡。

2.6 多路徑并行傳輸

在傳統設備中用得比較多是是多路徑并行傳輸，但在真正的RTC系統中反而用的就較少。因為現在在很多的移動終端會有同時連接WiFi和4/5G信號的情況，包括手機支持雙4G信號的連接。這種情況下我們就可利用雙鏈路的雙路徑并行傳輸來提升傳輸效率和傳輸的可靠性。比如手機上有電信和聯通兩張卡，如果同時使用電信和聯通兩個卡去發送和接收數據，就會有更好的帶寬和網絡保證。

如何將數據在兩個網絡之間進行調配以及如何在兩個鏈路之間進行動態的冗余都有比較大的挑戰。我們有一個比較簡單的方式是先把所有的網卡列舉出來并激活，再進行處理數據和執行并行的數據傳輸。單鏈路會有主鏈路來傳輸音視頻數據，并調用輔助鏈路處理音頻數據，以此來提升音頻的可靠性。在RTC環境里，如果視頻產生一些丟包但能保證音頻的話，這對通信質量也會有比較好的保障。

2.7 弱網增強

弱網增強采用視音頻編解碼、傳輸控制、糾錯算法不同手段綜合實現。在視音頻編輯碼方面有SVC|Simulcast、碼率自適應和AI超分。在RTC或數據通信的場景下，經常會發生網絡帶寬的波動情況，這時候就需要動態地調整音視頻編解碼的實時碼率，如果這時的音視頻編解碼實時碼率能夠和實時傳輸帶寬達到最佳匹配的話，一方面可以最充分的利用網絡帶寬，另一方面也可以保證最佳的視頻效果（即不會產生卡頓也不會降低視頻質量）。但這是比較有挑戰性的，因為網絡傳輸和視頻編碼是兩個非常獨立的模塊，如何將這兩個模塊結合在一起聯動工作，首先要讓音視頻的Codec能夠支持動態地調整碼率、分辨率、幀率等一些基礎邏輯，這樣才有可能通過實時網絡探測的方式將實時網絡情況傳送給音視頻的Codec，再實現音視頻碼率和帶寬的自適應，不浪費網絡帶寬并且提升視頻質量。

AI超分是在播放端實現的，這項技術在RTC場景下顯得尤為重要，因為RTC場景很多時候是在跨網或者跨地域的連接下使用的，不像現在的點播、直播系統可以通過CDN加速，通過網絡連接提升和保障視頻的下載速度。大部分RTC都是基于點對點的連接，而且兩點之間有可能跨越了非常復雜的網絡情況，這直接導致在大部分的RTC情況下，音視頻的帶寬都比較低，此時想要做到1080p的傳輸是比較艱難的，并且很容易因為丟包造成卡頓的情況。AI超分在其中一個很重要的作用是可以在整個RTC鏈路上以一個較低的分辨率、碼率進行通信，在終端播放時通過超分的方式增強視頻的主觀觀看效果。如果提供1.2M的RTC網絡通信能力（ RTC的場景以靜態居多），做1080p的數據傳輸是有一定風險的。1.2M做1080p傳輸的圖像質量不會太高，但在這種情況下結合AI超分，就可以在RTC鏈路上只跑一個540P 1M的視頻流，再在終端通過超分把它提升到1080p，這樣就可以以一個比較穩定且比較低的帶寬占用，實現比較好的最終使用效果。

傳輸控制方面有多源匯聚、多鏈路并傳、緩存自適應、帶寬估算、平滑發送。糾錯算法方面有FEC前向糾錯、主/被動重傳、錯峰多副本、自適應糾錯策略。

2.8 編解碼

在編解碼部分我將介紹一些基礎的視頻能力，它們都會在MCU中使用。其中端上也會有去噪、銳化、AI增強、動態編碼、ROI編碼。ROI編碼會增強畫面中的人臉部分，并弱化畫面中的非人臉部分，在比較小的網絡帶寬環境下提供更好的主觀效果。

在極速轉碼方面有解碼復用、隨源快轉、源流水印、倍速轉碼。

終端超分方面有實時超分、2×超分、渲染處理、細節增強。

多碼率切換方面有幀對齊、無縫切換、直播切換。

舒適音頻方面有降噪、齊量、均衡、舒適。

質量檢測方面有文件合規性、黑屏、靜幀、花屏、靜音。

以上是我們在視頻方面對RTC進行的一些工作。

2.9 移動端增強超分

上圖的右半部分是移動端增強超分的流程圖，在視頻解碼之后會得到YUV圖像，并將它在低分辨率的情況下進行亮度的增強、超分增強、色度增強、色度上采樣增強等處理，以及高分辨率的一些重建工作。整個過程在實際的測試效果中，雖然大家都懷疑從540P到1080P超分的效果是不是不太好，但實際上1M 540P的主觀感受基本上可以接近2.5M 1080P的效果。

我們也針對移動端上功耗的問題進行了很多優化，主要是用GPU加速的方式來實現超分的卷積框架。相比于屏幕顯示的功耗，超分算法的功耗是比較低的。

2.10 邊緣節點管理

因為RTC需要就近的連接才能提供更低的延時和更多的路由選擇，但不管是公有云機房還是CDN等地方，我們都有一些RTC能力的部署。上圖左部分列舉的一個簡單對比，CDN節點的量級一般在千級別，可用性也比較高，全國各省都會分布幾個機房點。但實際上最終要接入網絡的設備數可能是億級別的量級，設備接入并通過網絡進行數據通信。我們將邊緣計算層定義成Edge層，這一層是百萬級別的設備，但這些設備沒有CDN節點那么高的可靠性，處理能力也不如CDN節點里部署的服務器那么強，但它就是利用邊緣閑置的一些計算資源來提供一些分布式的計算和連接能力。因為部署在邊緣的這些計算資源也具備計算、存儲和網絡通信的能力，雖然每一個點的絕對計算能力都不是非常的強，但它可以在低延時通信領域里作為一個數據流轉發或者提供比較小的數據存儲和連接能力。從整體上來說，未來的網絡一定是從“云-管-端”的架構發展到“云-管-邊-端”，在云的邊緣會有一層百萬量級的邊緣設備作為邊緣計算節點來對外提供服務。

這些節點一方面跟核心控制平臺有連接，它有自我升級和管理的能力，通過平臺的控制邏輯下發指令，這些節點就可以進行自我管理和自我凈化。

自我管理包括自身計算能力的分配、自有存儲空間的管理等。因為這些節點有網絡能力之后，可以探測自身的一些網絡連接狀況，管理熱點文件，并根據自身的存儲空間進行整個全生命周期的管理。而且，每個節點都是一個自制的節點，來完成自己存儲空間、臨近節點路由和網絡連通性的管理，并將自身情況數據上報給平臺管理層，平臺管理層可以結合每一個節點的自制能力進行全局的管理。每個節點也可以實現按照平臺邏輯做數據防護和加密，整個“云-管-邊-端”架構也是京東云RTC基礎運行的物理存在環境。

一切為了QoE

音視頻服務追求的不僅是單純QoS，而是用戶最終的極致體驗,本次LiveVideoStackCon 2020 北京站我們也將邀請講師討論體驗質量方面的分析與探索，點擊【閱讀原文】可了解更多講師及話題信息。

LiveVideoStackCon 2020?北京

2020年10月31日-11月1日

點擊【閱讀原文】了解更多詳細信息

總結

以上是生活随笔為你收集整理的京东智联云分布式低延时RTC系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。