Janus流媒體服務器框架分析

---

目錄

webrtc多方通信架構

Janus流媒體服務器

---

1. webrtc多方通信架構

1. Mesh 方案

Mesh方案即多個終端之間兩兩進行連接，形成一個網狀結構。

比如 A、B、C 三個終端進行多對多通信，當 A 想要共享它的音視頻流時，它需要分別向 B 和 C 發送數據。當B想要共享媒體，就需要分別向 A、C 發送數據，依次類推。

Mesh方案對各終端的帶寬要求比較高。

優點：

不需要服務器中轉數據，STUN/TUTN 只是負責 NAT 穿越，利用現有 WebRTC 通信模型就可以實現，而不需要開發媒體服務器。

充分利用了客戶端的帶寬資源。

節省了服務器資源，因為服務器帶寬往往是專線，價格昂貴，所以這種方案可以很好地控制成本。

缺點：

共享端共享媒體流的時候，需要給每一個參與人都轉發一份媒體流，對上行帶寬的占用很大。參與人越多，占用的帶寬就越大。除此之外，對 CPU、Memory 等資源也是極大的考驗。客戶端的機器資源、帶寬資源往往是有限的，資源占用和參與人數成線性相關的。這樣導致 多人通信的規模非常有限，超過 4 個人時，就會有非常大的問題。

在多人通信時，如果有部分人不能實現 NAT 穿越，還想與其他人互通，就顯得很麻煩，需要做出更多的可靠性設計。

2. MCU（Multipoint Conferencing Unit）方案，

MCU方案由一個服務器和多個終端組成一個星形結構。

各終端將自己要共享的音視頻流發送給服務器，服務器端會將在同一個房間中的所有終端的音視頻流進行混合，最終生成一個混合后的音視頻流再發給各個終端，這樣各終端就可以看到 / 聽到其他終端的音視頻了。

實際上服務器端就是一個音視頻混合器，這種方案服務器的壓力會非常大。

優點：

技術成熟，在硬件視頻會議中應用非常廣泛。

作為音視頻網關，通過解碼、再編碼可以屏蔽不同編解碼設備的差異化，滿足更多客戶的集成需求，提升用戶體驗和產品競爭力。

將多路視頻混合成一路，所有參與人看到的是相同的畫面，客戶體驗好。

缺點：

重新解碼、編碼、混流，需要大量的運算，對 CPU 資源的消耗很大。

重新解碼、編碼、混流還會帶來延遲。

由于機器資源耗費很大，所以 MCU 所提供的容量有限，一般十幾路視頻就是上限了。

3. SFU（Selective Forwarding Unit）方案，

SFU方案也是由一個服務器和多個終端組成，但與 MCU 不同的是，SFU 不對音視頻進行混流，收到某個終端共享的音視頻流后，就直接將該音視頻流轉發給房間內的其他終端。它實際上就是一個音視頻路由轉發器。

優點：

由于是數據包直接轉發，不需要編碼、解碼，對 CPU 資源消耗很小。

直接轉發也極大地降低了延遲，提高了實時性。

帶來了很大的靈活性，能夠更好地適應不同的網絡狀況和終端類型。

缺點：

由于是數據包直接轉發，參與人觀看多路視頻的時候可能會出現不同步，相同的視頻流，不同的參與人看到的畫面也可能不一致。

參與人同時觀看多路視頻，在多路視頻窗口顯示、渲染等會帶來很多麻煩，尤其對多人實時通信進行錄制，多路流也會帶來很多回放的困難。

目前許多 SFU 方案都支持 SVC 模式和 Simulcast 模式，用于適配 WiFi、4G 等不同網絡狀況，以及 Phone、Pad、PC 等不同終端設備。

1. Simulcast 模式

Simulcast 模式就是指視頻的共享者可以同時向 SFU 發送多路不同分辨率的視頻流（一般為三路，如 1080P、720P、360P）。而 SFU 可以將接收到的三路流根據各終端的情況而選擇其中某一路發送出去。例如，由于 PC 端網絡特別好，給 PC 端發送 1080P 分辨率的視頻；而移動網絡較差，就給 Phone 發送 360P 分辨率的視頻。

Simulcast 模式對移動端的終端類型非常有用，它可以靈活而又智能地適應不同的網絡環境。

2. SVC 模式

SVC是可伸縮視頻編碼技術，原理是將視頻信號編碼為兩個或更多個碼流，這些碼流也稱為層，這些層中至少有一個是基本層，其余的為增強層。

基本層包含視頻信號基本的也是最重要的信息，接收端接收到基本層就可重建得到基本質量的圖像

增強層包含視頻信號的細節信息，接收端將基本層和增強層一起解碼，可以重建出更高質量的圖像。

例如將視頻分為多層：基本層為240p編碼數據，增強層為480p和720p的細節補充編碼數據，主播方會把240p、480p的補充編碼數據與720p的補充編碼數據都發出去，接收方則根據網絡環境選擇合適的數據包。

若網絡狀況良好則選取720p，若網絡狀況不佳則選擇480p甚至240p。

這樣的話無論網絡環境如何變化客戶端都可以流暢播放，改變的只是畫面清晰度。

所以可以采取大小流模式，例如有些客戶需要480p，另一些客戶需要720p，那么發送端便可針對240p、480p、720p發兩路或者三路，且不會相互干擾。

4. 開源方案

---

2. Janus流媒體服務器

使用的janus版本為0.10.4，下圖為janus主要的模塊結構，有一些通用工具模塊沒有列出。

1. 媒體模塊

Janus不是簡單轉發WebRTC的媒體流，還有?定的控制能?，因此需要?持WebRTC的媒體能?，其媒體功能包含以下基本模塊：

ICE：打洞，負責與Peer的連通，Janus可以部署在NAT后?，使?了libnice；

DTLS：UDP版的TLS，就是加密的UDP，WebRTC?來傳遞SRTP的密鑰，使?了OpenSSL/BoringSSL；

RTP/RTCP：提供RTP/RTCP 封包解包的接?，需要發送?些WebRTC?持的RTCP包，例如FIR、PLI、RR等；

SRTP：加密的RTP，開啟后WebRTC傳輸的RTP負載都是加密的；

SDP：提供SDP封/解包的接?，?于協商媒體的協議，可以?SDP對WebRTC的?些功能進?設定（編碼器優先、碼率限制），媒體能?的協商；

candidate：?絡信息，?絡協商；

SCTP：WebRTC的數據通道使?的協議，就是加上了流控的UDP，可以傳輸任意數據；

2. 信令傳輸模塊

除了媒體協議，Janus還要提供信令交互的協議，傳統的信令協議有SIP、XMPP等，Janus上的信令應?協議可以定制，底層主要的傳輸協議有：

HTTP(s)；

WebSocket(s)；

MQTT；

NanoMsg；

RabbitMQ；

其中WebSocket使?了libwebsockets，HTTP使?了libmicrohttpd。

3. 插件模塊

Janus的APP?持插件式開發，?前Janus官?給出的插件案例：

Echo Test： 回聲測試，?持通過按鈕控制碼率，從這?我們也可以學習到如何控制碼率.

Streaming：播放視頻或?頻流，可?于?絡直播或轉播。

Video Call：?視頻?對?通話，類似AppRTC的通話，但是?視頻數據經過Janus進?傳輸。

SIP Gateway：SIP?關演示，允許您在SIP服務器上注冊并啟動/接收呼叫。

Video Room：視頻會議演示，允許您加?最多有六個?戶的視頻會議室。.

Audio Room： ?頻會議演示，不同?戶之間的?頻將進?混?。

Text Room：?字聊天室，通過DataChannels進?傳輸。

Voice Mail：演示語?郵件功能，可以錄制?秒的?頻，然后可以進?回放。

Recorder/Playout：演示錄制?頻、視頻，然后通過WebRTC進?回放.

Screen Sharing：基于視頻會議(Video Room )插件實現的屏幕分享功能。

總結

以上是生活随笔為你收集整理的Janus流媒体服务器框架分析的全部內容，希望文章能夠幫你解決所遇到的問題。

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