Janus流媒體服務(wù)器框架分析

---

目錄

webrtc多方通信架構(gòu)

Janus流媒體服務(wù)器

---

1. webrtc多方通信架構(gòu)

1. Mesh 方案

Mesh方案即多個(gè)終端之間兩兩進(jìn)行連接，形成一個(gè)網(wǎng)狀結(jié)構(gòu)。

比如 A、B、C 三個(gè)終端進(jìn)行多對(duì)多通信，當(dāng) A 想要共享它的音視頻流時(shí)，它需要分別向 B 和 C 發(fā)送數(shù)據(jù)。當(dāng)B想要共享媒體，就需要分別向 A、C 發(fā)送數(shù)據(jù)，依次類推。

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

優(yōu)點(diǎn)：

不需要服務(wù)器中轉(zhuǎn)數(shù)據(jù)，STUN/TUTN 只是負(fù)責(zé) NAT 穿越，利用現(xiàn)有 WebRTC 通信模型就可以實(shí)現(xiàn)，而不需要開發(fā)媒體服務(wù)器。

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

節(jié)省了服務(wù)器資源，因?yàn)榉?wù)器帶寬往往是專線，價(jià)格昂貴，所以這種方案可以很好地控制成本。

缺點(diǎn)：

共享端共享媒體流的時(shí)候，需要給每一個(gè)參與人都轉(zhuǎn)發(fā)一份媒體流，對(duì)上行帶寬的占用很大。參與人越多，占用的帶寬就越大。除此之外，對(duì) CPU、Memory 等資源也是極大的考驗(yàn)?？蛻舳说臋C(jī)器資源、帶寬資源往往是有限的，資源占用和參與人數(shù)成線性相關(guān)的。這樣導(dǎo)致 多人通信的規(guī)模非常有限，超過 4 個(gè)人時(shí)，就會(huì)有非常大的問題。

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

2. MCU（Multipoint Conferencing Unit）方案，

MCU方案由一個(gè)服務(wù)器和多個(gè)終端組成一個(gè)星形結(jié)構(gòu)。

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

實(shí)際上服務(wù)器端就是一個(gè)音視頻混合器，這種方案服務(wù)器的壓力會(huì)非常大。

優(yōu)點(diǎn)：

技術(shù)成熟，在硬件視頻會(huì)議中應(yīng)用非常廣泛。

作為音視頻網(wǎng)關(guān)，通過解碼、再編碼可以屏蔽不同編解碼設(shè)備的差異化，滿足更多客戶的集成需求，提升用戶體驗(yàn)和產(chǎn)品競(jìng)爭(zhēng)力。

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

缺點(diǎn)：

重新解碼、編碼、混流，需要大量的運(yùn)算，對(duì) CPU 資源的消耗很大。

重新解碼、編碼、混流還會(huì)帶來延遲。

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

3. SFU（Selective Forwarding Unit）方案，

SFU方案也是由一個(gè)服務(wù)器和多個(gè)終端組成，但與 MCU 不同的是，SFU 不對(duì)音視頻進(jìn)行混流，收到某個(gè)終端共享的音視頻流后，就直接將該音視頻流轉(zhuǎn)發(fā)給房間內(nèi)的其他終端。它實(shí)際上就是一個(gè)音視頻路由轉(zhuǎn)發(fā)器。

優(yōu)點(diǎn)：

由于是數(shù)據(jù)包直接轉(zhuǎn)發(fā)，不需要編碼、解碼，對(duì) CPU 資源消耗很小。

直接轉(zhuǎn)發(fā)也極大地降低了延遲，提高了實(shí)時(shí)性。

帶來了很大的靈活性，能夠更好地適應(yīng)不同的網(wǎng)絡(luò)狀況和終端類型。

缺點(diǎn)：

由于是數(shù)據(jù)包直接轉(zhuǎn)發(fā)，參與人觀看多路視頻的時(shí)候可能會(huì)出現(xiàn)不同步，相同的視頻流，不同的參與人看到的畫面也可能不一致。

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

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

1. Simulcast 模式

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

Simulcast 模式對(duì)移動(dòng)端的終端類型非常有用，它可以靈活而又智能地適應(yīng)不同的網(wǎng)絡(luò)環(huán)境。

2. SVC 模式

SVC是可伸縮視頻編碼技術(shù)，原理是將視頻信號(hào)編碼為兩個(gè)或更多個(gè)碼流，這些碼流也稱為層，這些層中至少有一個(gè)是基本層，其余的為增強(qiáng)層。

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

增強(qiáng)層包含視頻信號(hào)的細(xì)節(jié)信息，接收端將基本層和增強(qiáng)層一起解碼，可以重建出更高質(zhì)量的圖像。

例如將視頻分為多層：基本層為240p編碼數(shù)據(jù)，增強(qiáng)層為480p和720p的細(xì)節(jié)補(bǔ)充編碼數(shù)據(jù)，主播方會(huì)把240p、480p的補(bǔ)充編碼數(shù)據(jù)與720p的補(bǔ)充編碼數(shù)據(jù)都發(fā)出去，接收方則根據(jù)網(wǎng)絡(luò)環(huán)境選擇合適的數(shù)據(jù)包。

若網(wǎng)絡(luò)狀況良好則選取720p，若網(wǎng)絡(luò)狀況不佳則選擇480p甚至240p。

這樣的話無論網(wǎng)絡(luò)環(huán)境如何變化客戶端都可以流暢播放，改變的只是畫面清晰度。

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

4. 開源方案

---

2. Janus流媒體服務(wù)器

使用的janus版本為0.10.4，下圖為janus主要的模塊結(jié)構(gòu)，有一些通用工具模塊沒有列出。

1. 媒體模塊

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

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

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

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

SRTP：加密的RTP，開啟后WebRTC傳輸?shù)腞TP負(fù)載都是加密的；

SDP：提供SDP封/解包的接?，?于協(xié)商媒體的協(xié)議，可以?SDP對(duì)WebRTC的?些功能進(jìn)?設(shè)定（編碼器優(yōu)先、碼率限制），媒體能?的協(xié)商；

candidate：?絡(luò)信息，?絡(luò)協(xié)商；

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

2. 信令傳輸模塊

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

HTTP(s)；

WebSocket(s)；

MQTT；

NanoMsg；

RabbitMQ；

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

3. 插件模塊

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

Echo Test： 回聲測(cè)試，?持通過按鈕控制碼率，從這?我們也可以學(xué)習(xí)到如何控制碼率.

Streaming：播放視頻或?頻流，可?于?絡(luò)直播或轉(zhuǎn)播。

Video Call：?視頻?對(duì)?通話，類似AppRTC的通話，但是?視頻數(shù)據(jù)經(jīng)過Janus進(jìn)?傳輸。

SIP Gateway：SIP?關(guān)演示，允許您在SIP服務(wù)器上注冊(cè)并啟動(dòng)/接收呼叫。

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

Audio Room： ?頻會(huì)議演示，不同?戶之間的?頻將進(jìn)?混?。

Text Room：?字聊天室，通過DataChannels進(jìn)?傳輸。

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

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

Screen Sharing：基于視頻會(huì)議(Video Room )插件實(shí)現(xiàn)的屏幕分享功能。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。