本文整理自網易雲信多媒體資深技術架構師吳桐在 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融合架構設計》系列第三篇，也是最後一篇。 歡迎留下評論，與吳桐老師一對一交流。