低延時直播與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融合架構設計》系列第三篇,也是最後一篇。

邀請好友使用網易雲信,好友下單成功即可獲得500元京東/嚴選無門檻現金券,點擊立即推薦>>

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章