低延時直播與RTC融合架構設計③：RTC融合架構設計網易雲信

本文整理自網易雲信多媒體資深技術架構師吳桐在 QCon 全球軟件開發大會上海站的演講內容《超高清4K視頻低延時直播與RTC融合架構設計》，爲該系列的第三篇文章。

回顧該系列文章：

《低延時直播與RTC融合架構設計①：5G與將來的網絡格局》

《低延時直播與RTC融合架構設計②： 直播與RTC低延時方案》

本篇文章中，吳桐將向你們介紹網易雲信NRTC融合架構、RTC視頻會議場景優化方案以及他我的一些前瞻性的思考和展望。

網易雲信NRTC融合架構

NRTC是NetEase Real-Time Communication的簡寫，是網易雲信自主設計研發的全功能工業級音視頻技術框架，它可提供如下功能：

（1）NRTC提供實時音視頻與低延時直播功能，這一方案是基於UDP的，低時延流暢，這一能力能夠用於音視頻交友、在線教學、多人視頻會議等多種場景；

（2）NRTC同時也提供傳統直播功能，這一方案是基於TCP的，能夠提供高品質的直播能力，這一能力能夠用於秀場直播、遊戲直播、大班教學等場景；

（3）NRTC也能夠將（1）和（2）的能力結合，提供旁路直播功能，經過上麥下麥控制用戶在連麥和觀衆模式間切換；

（4）NRTC提供點播與轉碼功能，經過融合CDN實現海量分發；

（5）NRTC提供短視頻功能，提供了短視頻SDK；

（6）NRTC同時使用小程序網關和WebRTC網關來接入微信小程序音視頻和WebRTC。

綜上，NRTC可以提供的能力是很是全的，相關的功能也很是成熟穩定，NRTC支撐了網易內外部各個客戶的海量應用，譬如網易雲音樂、網易新聞、有道、雲課堂等等。

那麼咱們是如何將低延時與CDN分發網絡結合的？

低延時部分不管是否有上行數據，都採用UDP協議接入咱們上面提到的低延時網絡中，由低延時分發網絡來保證全部參與方的低延時體驗，若是須要和CDN分發網絡融合，會由其中的一個Mesh節點，將全部上行數據發送給旁路MCU服務器，旁路MCU服務器會向融合CDN控制中心請求調度融合CDN源站節點，旁路MCU服務器作音頻與視頻的混合後，轉發給咱們的融合CDN源站，由融合CDN源站根據融合CDN的配置狀況向一個或者多個CDN推流。

用戶能夠根據本身的需求以及對費用狀況，選擇定製是否要旁路到CDN，選擇融合CDN狀況。

RTC視頻會議場景優化

在融合架構的最後，我想和你們就RTC視頻會議場景作一些交流。

RTC視頻會議場景的需求和複雜度比單向直播要大的多，視頻會議中各個終端的觀看需求不一樣、網絡狀況也各不相同。所以爲了作好視頻會議，咱們須要有一個完善的發佈訂閱系統，同時配合好服務端的智能選擇，這依賴於服務器上的一套智能碼率分配以及碼流選擇算法；另外一個核心功能是要實現服務器的分段QoS，所謂分段QoS就是在服務器上須要分別針對用戶到服務器的上行鏈路和服務器到用戶的下行鏈路作好QoS保障，固然對於服務器來講核心是要作好下行的帶寬估計、擁塞控制和丟包對抗。

一套發佈訂閱系統的基礎功能，其實很好理解。

有A、B、C、D、E、F，每一個人均可以發佈本身的視頻，這些發佈消息會在媒體服務器上作彙總，而後分發給每個與會者。如圖E選擇訂閱B/C/D，那麼媒體服務器就會根據E的訂閱請求將B/C/D的媒體包轉發給E，同理F能夠作出不一樣訂閱，他訂閱A/B/C，那媒體服務器就只會將A/B/C三個用戶的媒體包轉發給F。

這就是訂閱系統的基礎功能，知足不一樣用戶的不一樣需求。有了訂閱系統，咱們就能夠繼續來看看一些進階用戶需求。

咱們知道每一個參會用戶對於不一樣人的清晰度需求是不一樣的，同時每一個用戶的網絡的下行帶寬是不一樣的。舉個例子，發佈者發佈了最大能力是720p 1.5Mbps，用戶A下行帶寬大於1.5Mbps，他在界面上須要看發佈者的大畫面，因此他訂閱720p 1.5Mbps；用戶B的下行帶寬只有700Kbps，他在界面上也須要看發佈者的大畫面，因此他也訂閱的是720p 1.5Mbps；用戶C的下行帶寬 大於 1.5Mbps，可是他因爲界面上只須要發佈者的一個小畫面，所以他只須要訂閱發佈者的360p 600Kbps。

此時A/B/C的訂閱請求到達服務器後，服務器綜合：發佈、訂閱以及下行帶寬估計三個因素，發現沒法獲得最優分配以知足和匹配全部人需求，有一種可行作法是匹配最低訂閱，這樣全部人都看到的是360p 600Kbps的視頻。這時候對A來講，他看到發佈者的畫面就會不清晰，可是他的下行帶寬其實足夠的。爲了解決這個問題，當前的方案已經沒法知足了，須要引入新的能力。

爲了解決這個問題，咱們提出多流的方案，也就是讓發佈者發送多條流給服務器，關於多流業界有一個專有名詞叫simulcast。發佈者開啓多流能力，服務器經過智能決策，能夠得到最佳匹配。

這個方案的要點是，服務器須要有各個分辨率的碼率範圍，同時下行帶寬須要估計準確，在服務器上根據各個下行的帶寬和用戶的具體訂閱需求進行分配。同時服務器須要兼容上行網絡變差時，發佈者將多流切爲單流的狀況，此時在傳輸協議設計時須要考慮如何能夠方便服務器作出正常的選路，這也是咱們前面談到的傳輸協議須要能夠描述多流能力的緣由。

那是否還有其它方案呢？固然有。

咱們還能夠保持發佈者一路流上行，若是發佈者上行是高分辨率，只須要按照下行用戶的需求，轉碼出所需的分辨率便可；而若是發佈者上行的是低分辨率，對於訂閱他高分辨率的下行用戶，能夠採用「超分」方案（下文有簡要介紹）。可是不管是轉碼仍是超分，對服務器的性能負載要求都不小，所以須要謹慎選擇，畢竟全部方案都要考慮性價比。

進階與展望

• 窄帶高清與超分

所謂窄帶高清，其實就是傳輸低帶寬，觀看高清視覺。

不讓馬兒吃草，還讓馬兒跑，大家以爲有這麼便宜的事嗎？還真有，因此說科學技術纔是第一輩子產力。

由深度學習發展，人工神經網絡能夠作到將低分辨率超分爲高分辨率。咱們在工程中採用ESPCN網絡作的超分Demo在旗艦機型上已經能夠實現540p->1080p的超分。不過因爲低分辨率的意義不大，而高分辨率對性能要求實在是很高，因此咱們暫時沒有將這個功能作上線。

我認爲當前超分技術仍是更適合用於點播場景，而實時或者低延時場景還不適用，固然隨着機器性能和算法性能提升，將來仍是可期的。

• 基於機器學習的擁塞控制-PCC

這個演講中，咱們談了不少擁塞控制（回顧 《低延時直播與RTC融合架構設計②： 直播與RTC低延時方案》），不管是GCC和BBR都是一種依賴一種Hardwired Mapping 來控制發送速率的，其實本質上都是對網絡的一種假設。如今有論文提出一種基於機器學習思路的擁塞控制算法，其中PCC是其中的佼佼者。

PCC相似於機器學習，設置一個目標函數，而後不斷地嘗試各類發送速率，最終使得目標函數達到最優，逼近最優解，不過最困難的也是如何設計這個這個目標函數了。PCC如今已經有了第二版本 Vivace在算法和設計上作了進一步的優化，我認爲這是一個很是有意思的方向，建議你們保持關注。

• 展 望

AI人工智能、機器學習和深度學習就不用說了，在將來確定會在各個領域發光發亮。VR也是能夠大大改變和變革用戶體驗的一個手段，隨着5G和芯片性能提升，我相信將來VR眼鏡會變得像手機同樣被普遍使用。伴隨着5G和IPv6的普及，萬物互聯IoT，你能夠和全部設備進行音視頻溝通，想一想就有些期待。

最後，我以爲最快落地的就是5G邊緣計算，正如我在 《低延時直播與RTC融合架構設計①： 5G與將來的網絡格局》舉的例子，5G邊緣計算將改變IDC、CDN乃至雲產商的現有格局。

以上是網易雲信多媒體資深技術架構師吳桐在 QCon 全球軟件開發大會上海站的演講實錄《超高清4K視頻低延時直播與RTC融合架構設計》系列第三篇，也是最後一篇。

歡迎留下評論，與吳桐老師一對一交流。