互動直播之WebRTC服務開源技術選型

【轉載請注明出處】： https://www.jianshu.com/p/73f2615dc3ef

1 直播基礎知識

最原始的直播系統其實并沒有想象的那麼複雜，無非就是主播端将音視訊資料推送到伺服器，觀衆端則從伺服器拉取資料播放。

1.1 基本常識

1.1.1 基礎概念

• 推流

  推流，是直播中的一個術語，意思是将流媒體資料推送到伺服器。如何推流，關鍵就在于使用的推流協定。

• 拉流

  拉流，指的是

  觀衆端

  流媒體資料的拉取，同樣也需要通過約定的拉流協定來拉取。

• 視訊幀

  幀，是視訊的一個基本概念，表示一張畫面，如上面的翻頁動畫書中的一頁，就是一幀。一個視訊就是由許許多多幀組成的。

• 幀率

  幀率，即機關時間内幀的數量，機關為：幀/秒 或fps（frames per second）。如動畫書中，一秒内包含多少張圖檔，圖檔越多，畫面越順滑，過渡越自然。

幀率的一般以下幾個典型值：

• 24/25 fps：1秒 24/25 幀，一般的電影幀率。
• 30/60 fps：1秒 30/60 幀，遊戲的幀率，30幀可以接受，60幀會感覺更加流暢逼真。
• 85 fps以上人眼基本無法察覺出來了，是以更高的幀率在視訊裡沒有太大意義。

• 色彩空間

  這裡我們隻講常用到的兩種色彩空間。

  • RGB

    RGB的顔色模式應該是我們最熟悉的一種，在現在的電子裝置中應用廣泛。通過R G B三種基礎色，可以混合出所有的顔色。

  • YUV

    YUV是一種亮度與色度分離的色彩格式。早期的電視都是黑白的，即隻有亮度值，即Y。有了彩色電視以後，加入了UV兩種色度，形成現在的YUV，也叫YCbCr。

Y：亮度，就是灰階值。除了表示亮度信号外，還含有較多的綠色通道量。

U：藍色通道與亮度的內插補點。

V：紅色通道與亮度的內插補點。

因為人眼對亮度敏感，對色度不敏感，是以減少部分UV的資料量，人眼卻無法感覺出來，這樣可以通過壓縮UV的分辨率，在不影響觀感的前提下，減小視訊的體積。

• 采樣率

  采樣率即采樣的頻率。采樣率要大于原聲波頻率的2倍，人耳能聽到的最高頻率為20kHz，是以為了滿足人耳的聽覺要求，采樣率至少為40kHz，通常為44.1kHz，更高的通常為48kHz。

• 采樣位數

  采樣位數涉及到聲波的振幅量化。波形振幅在模拟信号上也是連續的樣本值，而在數字信号中，信号一般是不連續的，是以模拟信号量化以後，隻能取一個近似的整數值，為了記錄這些振幅值，采樣器會采用一個固定的位數來記錄這些振幅值，通常有8位、16位、32位。位數越多，記錄的值越準确，還原度越高。

由于數字信号是由0，1組成的，是以，需要将幅度值轉換為一系列0和1進行存儲，也就是編碼，最後得到的資料就是數字信号：一串0和1組成的資料。

• 聲道數

  聲道數，是指支援能不同發聲（注意是不同聲音）的音響的個數。

單聲道：1個聲道

雙聲道：2個聲道

立體聲道：預設為2個聲道

立體聲道（4聲道）：4個聲道

• 碼率

  碼率，是指一個資料流中每秒鐘能通過的資訊量，機關bps（bit per second）

碼率 = 采樣率 * 采樣位數 * 聲道數

1.1.2 視訊編碼

編碼可以大大減小音視訊資料的大小，讓音視訊更容易存儲和傳送。視訊編碼格式有很多，比如H26x系列和MPEG系列的編碼，這些編碼格式都是為了适應時代發展而出現的。

其中，H26x（1/2/3/4/5）系列由ITU（International Telecommunication Union）國際電傳視訊聯盟主導。MPEG（1/2/3/4）系列由MPEG（Moving Picture Experts Group, ISO旗下的組織）主導。

1.1.3 音頻編碼

原始的PCM音頻資料也是非常大的資料量，是以也需要對其進行壓縮編碼。

和視訊編碼一樣，音頻也有許多的編碼格式，如：WAV、MP3、WMA、APE、FLAC等等。

在MP4視訊中的音頻資料，大多數時候都是采用AAC壓縮格式。AAC是新一代的音頻有損壓縮技術，一種高壓縮比的音頻壓縮算法。

1.1.4 音視訊容器

我們熟悉的視訊格式，如mp4、rmvb、avi、mkv、mov...，其實是包裹了音視訊編碼資料的容器，用來把以特定編碼标準編碼的視訊流和音頻流混在一起，成為一個檔案。

例如：mp4支援H264、H265等視訊編碼和AAC、MP3等音頻編碼。

1.1.5 硬解碼和軟解碼

在手機或者PC上，都會有CPU、GPU或者解碼器等硬體。通常，我們的計算都是在CPU上進行的，也就是我們軟體的執行晶片，而GPU主要負責畫面的顯示（是一種硬體加速）。

所謂軟解碼，就是指利用CPU的計算能力來解碼，通常如果CPU的能力不是很強的時候，一則解碼速度會比較慢，二則手機可能出現發熱現象。但是，由于使用統一的算法，相容性會很好。

硬解碼，指的是利用手機上專門的解碼晶片來加速解碼。通常硬解碼的解碼速度會快很多，但是由于硬解碼由各個廠家實作，品質參差不齊，非常容易出現相容性問題。

1.2 基礎直播流程

通過下面這個資料流程圖，能清晰地看到整個直播的過程。

可以看到，主播用戶端 處理的事情，其實就是短視訊開發中最重要的内容：

流程	詳細操作
音視訊資料采集	通過攝像頭和麥克風采集
音視訊濾鏡	通過 OpenGL 和 SoundTouch 等工具實作音視訊編輯
音視訊編碼	通過系統寫死 或 FFmpeg 軟編碼，将資料編碼為 H264 和 AAC
資料封裝打包	将編碼好的資料封裝成指定的格式

唯一不一樣的地方，短視訊會将封裝好的資料儲存到本地，直播則是通過

推流協定

将資料推送到伺服器。

1.3 直播中的重難點

在直播中，有幾個非常重要的地方，會直接影響直播效果，導緻使用者流失。

 1.3.1 首屏時間

首屏時間，即從觀衆打開直播，到看到畫面呈現出來的時間。影響這個時間的是

H264

編碼中的一個概念：

GOP

。

GOP：Group of Picture，即一組幀組成的一個序列。在

H264

中，分别有 I幀、P幀、B幀 三種幀類型。

GOP

就是由一個

I幀

和多個

P幀

或

B幀

組成的一組相近的畫面 。

在H264中，三種類型的幀資料分别為

I幀：幀内編碼幀。就是一個完整幀。

P幀：前向預測編碼幀。是一個非完整幀，通過參考前面的I幀或P幀生成。

B幀：雙向預測内插編碼幀。參考前後圖像幀編碼生成。B幀依賴其前最近的一個I幀或P幀及其後最近的一個P幀。

解碼器可以直接解碼

I幀

，但是

P幀

和

B幀

必須依賴

I幀

，或者前後的

P或B

才能解碼。首次連上直播間時，需要抛棄掉

P

B

幀，等待

I幀

。是以，影響首屏時間最重要的因素就是

I幀

，也就是兩個

GOP

之間的間隔時間。

GOP 間隔的設定并非越小越好，太小則兩個

I幀

之間的

P/B幀

越少，壓縮率越低，畫面品質越差，需要做好權衡。

 1.3.2 穩定性問題

我們知道網絡是不穩定的，經常會出現網速慢，甚至斷網的問題，是以穩定性優化也是非常重要的。 比如以下幾個方面：

• 碼率控制

  同樣分辨率下，碼率越高，視訊越清晰，同時需要的帶寬也越大。相反，碼率越低，視訊越模糊，資料越小。

• 弱網優化

  根據不同的網速切換不同的碼率進行播放等。

• 斷線重連

  網絡斷開時的重聯機制。

 1.3.3 全局負載均衡

随着業務的發展，如果主播和觀衆的數量越來越多以後，系統可能會面臨高并發情景，直播卡頓，甚至系統奔潰，解決這種情況的一個好辦法就是使用

CDN

CDN内容分發 解決因分布、帶寬、伺服器性能帶來的通路延遲問題，适用于站點加速、點播、直播。

加入 CDN 後，整個直播系統架構如下：

 1.3.4 其他

除了以上提到的内容，當今的直播系統還要包括以下内容：錄制、轉碼、鑒黃、截屏、權鑒防盜、回聲消除、連麥 等等，整套下來，需要非常多的知識儲備，以及大量的時間精力，才能完成。

1.4 幾種常見的流媒體網絡傳輸協定

直播協定包含了上面提到的

推流

拉流

協定。

1.4.1 RTP

實時傳輸協定（

Real-time Transport Protocol

，縮寫RTP）是一個網絡傳輸協定，它是由IETF的多媒體傳輸工作小組1996年在RFC 1889中公布的。

RTP協定詳細說明了在網際網路上傳遞音頻和視訊的标準資料包格式。它一開始被設計為一個多點傳播協定，但後來被用在很多單點傳播應用中。RTP協定常用于流媒體系統（配合RTSP協定），視訊會議和一鍵通（Push to Talk）系統（配合H.323或SIP），使它成為IP電話産業的技術基礎。RTP協定和RTP控制協定RTCP一起使用，而且它是建立在UDP協定上的。

1.4.2 RTMP

實時消息協定（

Real-Time Messaging Protocol

，縮寫RTMP）也稱實時消息傳輸協定，是最初由Macromedia為通過網際網路在Flash播放器與一個伺服器之間傳輸流媒體音頻、視訊和資料而開發的一個專有協定。Macromedia後被Adobe Systems收購，該協定也已釋出了不完整的規範供公衆使用。

RTMP協定有許多變種：

1. 預設使用TCP端口1935的純粹（plain）協定。
2. RTMPS，通過一個TLS/SSL連接配接傳輸RTMP。
3. RTMPE，使用Adobe自有安全機制加密的RTMP。雖然實作的細節為專有，但該機制使用行業标準的密碼學原函數。
4. RTMPT，用HTTP封裝以穿透防火牆。RTMPT通常在TCP通信端口80和443上使用明文請求來繞過大多數的公司流量過濾。封裝的會話中可能攜帶純粹的RTMP、RTMPS或RTMPE資料包。
5. RTMFP, 使用UDP而非TCP的RTMP，取代RTMP Chunk Stream。Adobe Systems開發了安全的實時媒體流協定包，可以讓最終使用者直接地互相連接配接（P2P）。

 1.4.3 WebRTC标準

WebRTC

是一個由谷歌、Mozilla和Opera等支援的開源技術。它通過簡單的api為浏覽器和移動應用程式提供實時通信(RTC)功能。為浏覽器、移動平台和物聯網裝置開發豐富、高品質的RTC應用程式，并允許它們通過一組通用協定進行通信。

支援的浏覽器和平台：

• Chrome
• Firefox
• Opera
• Android
• iOS

特點：

• 基于浏覽器，且主流浏覽器都支援，跨平台能力強
• 預設P2P，但是需要TURN伺服器作為fallback
• 自适應碼率

 1.4.4 HLS

HTTP Live Streaming

（縮寫是HLS）是一個由蘋果公司提出的基于HTTP的流媒體網絡傳輸協定。它的工作原理是把整個流分成一個個小的基于HTTP的檔案來下載下傳，每次隻下載下傳一些。當媒體流正在播放時，用戶端可以選擇從許多不同的備用源中以不同的速率下載下傳同樣的資源，允許流媒體會話适應不同的資料速率。在開始一個流媒體會話時，用戶端會下載下傳一個包含中繼資料的extended M3U (m3u8) playlist檔案，用于尋找可用的媒體流。

HLS隻請求基本的HTTP封包，與實時傳輸協定（RTP）不同，HLS可以穿過任何允許HTTP資料通過的防火牆或者代理伺服器。它也很容易使用内容分發網絡（CDN）來傳輸媒體流。

2 WebRTC技術

2.1 為什麼選擇WebRTC

目前 WebRTC 提供了在 Web、iOS、Android、Mac、Windows、Linux 在内的所有平台的 API，保證了 API 在所有平台的一緻性。使用 WebRTC 的好處主要有以下幾個方面：

1. 免費的使用 GIPS 先進的音視訊引擎；
2. 由于音視訊傳輸是基于點對點傳輸的，是以實作簡單的 1 對 1 通話場景，需要較少的伺服器資源，借助免費的 STUN/TURN 伺服器可以大大節約成本開銷；
3. 開發 Web 版本的應用非常友善，使用簡單的 JS 接口，無需安裝任何插件，即可實作音視訊互通；
4. WebRTC 适用的場景非常廣泛，如當下比較火的社交、遊戲、體育、電視、相親類的直播，以及互動連麥、線上教育、線上醫療、金融證券線上開戶、智能硬體（如無人機）、智能家居裝置如攝像頭監控以及智能語音裝置；
5. WebRTC還可以錄制音視訊到本地檔案；
6. WebRTC提供音視訊加密功能；
7. WebRTC最大的優勢就是“标準化”，它解決的問題就是給所有需要進行實時通信的終端提供一套統一的、開放的實時通信能力描述和連接配接建立标準；

2.2 什麼是打洞伺服器

P2P(peer to peer)對等通信。 即在p2p的網絡中，所有網絡節點都是同等地位，沒有服務端和用戶端之分，一個節點即是服務端也是用戶端。用戶端之間可以進行直接的通信，不需要在經過服務端的中轉，進而提高網絡傳輸速度和減小伺服器壓力，這是非常有用的。P2P雖然通信模式非常理想，但是有一些問題需要解決：

1. 用戶端通信之前，必須知曉接受端的公網IP和端口
2. 用戶端的p2p通信資料包必須能夠穿透NAT(network address translate) 網絡位址翻譯

解決方案：

1. 第一個問題比較簡單，可以通過一台擁有公網IP的節點來記錄線上用戶端的公網IP和端口，所有用戶端可以通過該節點讀取接受用戶端的IP和port
2. 第二個問題比較複雜，主要針對私有網絡之間的通信，由于ip的匮乏，是以網絡上不可能所有節點都位于同一個網段（即擁有公網IP）

事實上，大部分的節點都處于正常網絡的邊緣，甚至在DNS所能查詢的範圍之外，是以在處于網絡的邊緣的節點不能直接通信的。

為了能讓用戶端在不同的網絡之間通信，我們就需要穿過防火牆，而且我們還要面對ISP所設定的種種限制。是以為了繞開這些限制，以及在接收端的防火牆上打開一個口讓媒體通過，我們就需要依賴STUN/TURN伺服器，目的是找到一條正确的路徑（STUN），或者是作為一個中繼伺服器用來傳輸媒體（TURN）

上圖中的Relay server即為TURN中繼伺服器，而STUN server的作用是通過收集NAT背後peer端(即：躲在路由器或交換機後的電腦）對外暴露出來的ip和端口，找到一條可穿透路由器的鍊路，俗稱“打洞”。STUN/TURN伺服器通常要部署在公網上，能被所有peer端通路到。

2.3 什麼是WebRTC伺服器

WebRTC被認為是一種點對點技術，浏覽器可以直接通信而無需任何類型的基礎設施。此模型足以建立基本應用程式，但難以在其之上實作諸如組通信，媒體流記錄，媒體廣播或媒體轉碼之類的功能。是以，許多應用程式都需要使用媒體伺服器。

從概念上講，WebRTC媒體伺服器隻是一種“多媒體中間件”，從源到目的地時，媒體流量會通過該中間件。媒體伺服器能夠處理媒體流并提供不同的類型，包括組通信（将一個對等方生成的媒體流配置設定給多個接收方，即充當多會議單元，MCU），混合（将多個傳入流轉換為一個單一的複合流） ，轉碼（在不相容的用戶端之間适應編解碼器和格式），錄制（以持久的方式存儲對等體之間交換的媒體）等。

媒體伺服器的好處有如下幾點：

1. 擴充了系統性能和功能，來支援更為複雜的應用場景；
2. 所有媒體流經由媒體伺服器的一個好處是可以進行記錄，這對于一些需要保留會議紀要的場景是非常有用的；
3. 可以友善的和第三方系統進行內建；
4. 可以對媒體流進行額外的加工處理，比如通過人工智能人臉識别來給播客添加虛拟的帽子。

2.4 WebRTC通信模式

當媒體伺服器充當媒體中繼時，它通常被稱為SFU（Selective Forwarding Unit選擇性轉發機關），這意味着其主要目的是在用戶端之間轉發媒體流。還有一個MCU（Multipoint Conferencing Unit多點會議單元）的概念，MCU伺服器不僅可以轉發，而且可以對媒體流進行混合和編碼壓縮（比如把各個用戶端的資料打包轉發，和SFU相比，這樣将大幅度降低轉發資料的帶寬需求，但對CPU有更高的要求）。

 2.4.1 Mesh架構

每個端都與其它端互連。以上圖最左側為例，5個浏覽器，二二建立p2p連接配接，每個浏覽器與其它4個建立連接配接，總共需要10個連接配接。如果每條連接配接占用1m帶寬，則每個端上行需要4m，下行帶寬也要4m，總共帶寬消耗20m。而且除了帶寬問題，每個浏覽器上還要有音視訊“編碼/解碼”，cpu使用率也是問題，一般這種架構隻能支援4-6人左右，不過優點也很明顯，沒有中心節點，實作很簡單。

優點：

• 邏輯簡單，容易實作
• 服務端比較 “輕量”，TURN 伺服器比較簡單，一定比例的 P2P 成功率可極大減輕服務端的壓力

缺點：

• 每新增一個用戶端，所有的用戶端都需要新增一路資料上行，用戶端上行帶寬占用太大。是以，通話人數越多，效果越差
• 無法在服務端對視訊進行額外處理，如：錄制存儲回放、實時轉碼、智能分析、多路合流、轉推直播等等

 2.4.2 MCU (MultiPoint Control Unit)

這是一種傳統的中心化架構(上圖中間部分)，每個浏覽器僅與中心的MCU伺服器連接配接，MCU伺服器負責所有的視訊編碼、轉碼、解碼、混合等複雜邏輯，每個浏覽器隻要1個連接配接，整個應用僅消耗5個連接配接，帶寬占用(包括上行、下行）共10m，浏覽器端的壓力要小很多，可以支援更多的人同時音視訊通訊，比較适合多人視訊會議。但是MCU伺服器的壓力較大，需要較高的配置。

以前在電信行業做視訊會議一般都使用MCU(Multipoint Control Unit)，也就是多方推流在MCU上進行合流，在拉流的時候隻有一路合流，這樣的好處是無論幾方推流，拉流隻有一路，下行帶寬比較小。但是問題也比較多，隻要推流方一多，MCU的壓力就比較大，而且分布式的部署也比較難，成本又很高。

 2.4.3 SFU(Selective Forwarding Unit)

上圖右側部分，咋一看，跟MCU好象沒什麼差別，但是思路不同，仍然有中心節點伺服器，但是中心節點隻負責轉發，不做太重的處理，是以伺服器的壓力會低很多，配置也不象MUC要求那麼高。但是每個端需要建立一個連接配接用于上傳自己的視訊，同時還要有N-1個連接配接用于下載下傳其它參與方的視訊資訊。是以總連接配接數為5*5，消耗的帶寬也是最大的，如果每個連接配接1M帶寬，總共需要25M帶寬，它的典型場景是1對N的視訊互動。

SFU 伺服器最核心的特點是把自己 “僞裝” 成了一個 WebRTC 的 Peer 用戶端，WebRTC 的其他用戶端其實并不知道自己通過 P2P 連接配接過去的是一台真實的用戶端還是一台伺服器，我們通常把這種連接配接稱之為 P2S，即：Peer to Server。除了 “僞裝” 成一個 WebRTC 的 Peer 用戶端外，SFU 伺服器還有一個最重要的能力就是具備 one-to-many 的能力，即可以将一個 Client 端的資料轉發到其他多個 Client 端。

這種網絡拓撲結構中，無論多少人同時進行視訊通話，每個 WebRTC 的用戶端隻需要連接配接一個 SFU 伺服器，上行一路資料即可，極大減少了多人視訊通話場景下 Mesh 模型給用戶端帶來的上行帶寬壓力。

SFU 伺服器跟 TURN 伺服器最大的不同是，TURN 伺服器僅僅是為 WebRTC 用戶端提供的一種輔助的資料轉發通道，在 P2P 不通的時候進行透明的資料轉發。而 SFU 是 “懂業務” 的， 它跟 WebRTC 用戶端是平等的關系，甚至 “接管了” WebRTC 用戶端的資料轉發的申請和控制。

現在網際網路行業比較流行的是SFU(Selective Forwarding Unit)，簡單說就是隻負責轉發流，不負責合流，壓力很小。這樣的模式可以依托CDN進行分布式的部署，不過拉流的方數限于用戶端的帶寬和處理能力。

 2.4.4 為啥推薦選擇 SFU ？

純 mesh 方案無法适應多人視訊通話，也無法實作服務端的各種視訊處理需求，最先排除在商業應用之外。

SFU 相比于 MCU，伺服器的壓力更小（純轉發，無轉碼合流），靈活性更好（可選擇性開關任意一路資料的上下行等），受到更廣泛的歡迎和應用，常見的開源 SFU 伺服器有：Licode，Kurento，Janus，Jitsi，Mediasoup等。

當然，也可以組合使用 SFU + MCU 的混合方案，以靈活應對不同場景的應用需要。

3 開源方案

3.1 流媒體選型要考慮的主要因素

1. 你是否深刻了解其代碼？
2. 代碼版本是否足夠新？
3. 有誰在使用它？
4. 它的文檔是否齊全？
5. 它可以debug嗎？
6. 它可以伸縮嗎？
7. 它使用哪種語言？

   對于媒體伺服器而言，這種語言的性能是否足夠？
   團隊是否足夠了解這門語言？           

8. 是否适應你現有的Signaling範式？

   你在看的Media Server是否容易與你決定使用的STUN/TURN伺服器內建           

9. 許可證是否适合你？

10. 誰在提供支援？

    很多成功的、被良好維護的開源項目背後都有一個商業模式，尤其是中小型的項目，這意味着有一個團隊以此為謀生手段。

具備可選的付費支援意味着：

* 有人願意全職來改善這東西，而不是作為愛好來維護。
* 如果你需要緊急幫助，隻要花錢就能得到。
           

3.2 Jitsi

https://github.com/jitsi/jitsi

Jitsi是一個免費的開源音頻/視訊和聊天通信器，它支援SIP、XMPP/Jabber、AIM/ICQ、IRC和許多其他有用的特性。

Jitsi不僅是WebRTC媒體伺服器，而且還有一個完整的平台。 Jitsi系列産品包括Jitsi Videobridge（媒體中繼，SFU），Jitsi Meet（會議網絡用戶端），Jicofo（Jitsi Conference Focus），Jigasi（Jitsi Gateway to SIP）和Jitsi SIP Phone。借助Jitsi我們能在幾個小時之内迅速搭建一個完整可用的通信平台。 它還使用Jingle（XMPP）和功能齊全的Web界面實作自己的信令控制。 然而，令人遺憾的是，它對于媒體錄制沒有提供穩定易用的解決方案。

3.3 Kurento

https://github.com/Kurento/kurento-media-server

Kurento是WebRTC媒體伺服器和一組用戶端API，可簡化針對WWW和智能手機平台的進階視訊應用程式的開發。Kurento Media Server的功能包括組通信，音視訊流的轉碼，記錄，混合，廣播和路由。

作為一項與衆不同的功能，Kurento Media Server還提供了進階媒體處理功能，包括計算機視覺，視訊索引，增強現實和語音分析。Kurento子產品化體系結構簡化了第三方媒體處理算法（即語音識别，情感分析，面部識别等）的內建，可以由應用程式開發人員透明地用作Kurento的其餘内置功能。

Kurento Media Server通過稱為Kurento API的RPC API公開其所有功能。可以通過任何與JSON相容的用戶端直接查詢該API，但是推薦的使用方法是通過

Kurento用戶端

庫。目前為Java，Browser Javascript和Node.js提供了這些工具。

如果您喜歡其他程式設計語言，則可以遵循基于WebSocket和JSON-RPC的

Kurento協定

的規範來編寫自定義用戶端庫。

Kurento被設計為可插入架構，Kurento中的每個插件都稱為一個子產品，可以使用新的自定義子產品擴充Kurento Media Server。更多資訊，請閱讀

Kurento子產品

部分。

Kurento子產品分為三類：

• 主要子產品

  與Kurento Media Server開箱即用合并：

  • kms-core：Kurento Media Server的主要元件。
  • kms-elements：Kurento Media Elements的實作（WebRtcEndpoint，PlayerEndpoint等）
  • kms-filters：Kurento過濾器的實作（FaceOverlayFilter，ZBarFilter等）

• 内置子產品

  Kurento團隊開發的額外子產品，用于增強Kurento Media Server的基本功能。到目前為止，有四個内置子產品，分别是：

  • kms-pointerdetector：基于顔色跟蹤檢測視訊流中指針的過濾器。
  • kms-chroma：過濾器，它在頂層使用顔色範圍并使之透明，進而在後面顯示另一個圖像。
  • kms-crowddetector：用于檢測視訊流中人聚集的過濾器。
    • kms-platedetector：用于檢測視訊流中的車牌的過濾器。

• 定制子產品

  Kurento Media Server的擴充，提供了新的媒體功能。

3.4 Licode

https://github.com/lynckia/licode

Licode基于WebRTC技術。它與Google Chrome的最新穩定版本100％相容。您的使用者将無需安裝任何内容即可通過其Web浏覽器進行交談。無需關心複雜的實時基礎架構。它提供了基于HTML5的視訊會議功能的快速開發，使它100％可擴充。Licode允許您在網絡上包括電視會議室。但是您也可以實作流媒體，錄制和您夢dream以求的任何其他實時多媒體功能！

主要子產品及實作語言：

• Erizo：這是WebRTC多點控制單元（MCU）。它是用C ++編寫的，并且與WebRTC标準及其協定100％相容。
• ErizoAPI：Erizo的Node.js插件包裝器。它可以從Node.js應用程式配置和管理Erizo的各個方面！
• Erizo控制器：這是服務的核心。它向使用者提供會議室以進行多方會議。它還提供了足夠的安全性機制和附加功能：資料，使用者清單，事件等。
• Nuve：該視訊會議管理API提供會議室管理，使用者對第三方應用程式的通路控制和服務注冊。它還為服務提供了雲可擴充性。

3.5 Janus

https://github.com/meetecho/janus-gateway

Janus是由

Meetecho

開發的WebRTC伺服器，被認為是通用伺服器。是以，除了實作與浏覽器建立WebRTC媒體通信，與之交換JSON消息以及在浏覽器與伺服器端應用程式邏輯之間中繼RTP / RTCP和消息的手段之外，它本身不提供任何功能。伺服器端插件提供了任何特定的功能/應用程式，然後浏覽器可以通過Janus與之聯系，以利用它們提供的功能。此類插件的示例可以是諸如回聲測試，會議橋，媒體記錄器，SIP網關等應用程式的實作。

這樣做的原因很簡單：我們想要的東西将具有 

small footprint

（是以是C實作），并且隻能配備以前的東西

really needed

（是以可插入子產品）。就是說，這使我們能夠在雲上部署成熟的WebRTC網關，或者使用小型的nettop / box來處理特定的用例。

其最顯着的特征之一是其插件架構，可以增強服務的核心功能。有一些有趣的Janus用例，例如SIP Gateway，螢幕共享等。

3.6 Mediasoup

https://github.com/versatica/mediasoup

由于其多功能性，性能和可伸縮性，mediasoup成為建構多方視訊會議和實時流應用程式的理想選擇。它具有聯播，SVC，傳輸BWE和其他更多先進功能。

除了建立另一個自帶伺服器之外，mediasoup是一個Node.js子產品，可以将其內建到更大的應用程式中。mediasoup提供了一個低級API，該API支援您的應用程式使用不同的用例。

mediasoup帶有mediasoup-client（JavaScript庫）和libmediasoupclient（C ++庫），用于建構使用統一API在任何浏覽器或裝置中運作的應用程式。或者隻使用知名軟體，例如FFmpeg或GStreamer。

設計目标

mediasoup及其用戶端庫旨在實作以下目标：

• 成為 SFU （選擇性轉發單元）。
• 支援WebRTC和普通RTP輸入和輸出。
• 在伺服器端成為Node.js子產品。
• 在用戶端成為小型JavaScript和C ++庫。
• 極簡主義：隻處理媒體層。
• 與信号無關：不要強制使用任何信号協定。
• 是超低級的API。
• 支援所有現有的WebRTC端點。
• 啟用與知名多媒體庫/工具的內建。

架構

特征

• ECMAScript 6低級API。
• 多流：通過單個ICE + DTLS傳輸的多個音頻/視訊流。
• IPv6就緒。
• UDP / TCP上的ICE / DTLS / RTP / RTCP。
• 同播和SVC支援。
• 擁塞控制。
• 使用空間/時間層分布算法的發送者和接收者帶寬估計。
• SCTP支援（基于純UDP的WebRTC資料通道和SCTP）。
• 極其強大（在 libuv 之上用C ++編碼的媒體工作程式子 程序 ）。

它與其他媒體伺服器的不同之處在于它被設計成一個用于Node的開發庫，這允許它可以被容易的內建到更大的應用程式中。

3.7 我們最後為啥選擇了Kurento？

• 開源
• 支援SFU和MCU
• 支援音視訊流的轉碼，記錄，混合，廣播和路由
• 内置子產品我們将來可以直接用
• API公開其所有功能，與語言無關，可以使用任何語言
• 可拔插架構，容易擴充
• 文檔豐富，demo多
• 社群活躍度高