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協議有許多變種：
- 默認使用TCP端口1935的純粹（plain）協議。
- RTMPS，通過一個TLS/SSL連接傳輸RTMP。
- RTMPE，使用Adobe自有安全機制加密的RTMP。雖然實現的細節為專有，但該機制使用行業標准的密碼學原函數。
- RTMPT，用HTTP封裝以穿透防火牆。RTMPT通常在TCP通信端口80和443上使用明文請求來繞過大多數的公司流量過濾。封裝的會話中可能攜帶純粹的RTMP、RTMPS或RTMPE數據包。
- 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 的好處主要有以下幾個方面：
- 免費的使用 GIPS 先進的音視頻引擎；
- 由於音視頻傳輸是基於點對點傳輸的，所以實現簡單的 1 對 1 通話場景，需要較少的服務器資源，借助免費的 STUN/TURN 服務器可以大大節約成本開銷；
- 開發 Web 版本的應用非常方便，使用簡單的 JS 接口，無需安裝任何插件，即可實現音視頻互通；
- WebRTC 適用的場景非常廣泛，如當下比較火的社交、游戲、體育、電視、相親類的直播，以及互動連麥、在線教育、在線醫療、金融證券在線開戶、智能硬件（如無人機）、智能家居設備如攝像頭監控以及智能語音設備；
- WebRTC還可以錄制音視頻到本地文件；
- WebRTC提供音視頻加密功能；
- WebRTC最大的優勢就是“標准化”，它解決的問題就是給所有需要進行實時通信的終端提供一套統一的、開放的實時通信能力描述和連接建立標准；
2.2 什么是打洞服務器
P2P(peer to peer)對等通信。 即在p2p的網絡中，所有網絡節點都是同等地位，沒有服務端和客戶端之分，一個節點即是服務端也是客戶端。客戶端之間可以進行直接的通信，不需要在經過服務端的中轉，從而提高網絡傳輸速度和減小服務器壓力，這是非常有用的。P2P雖然通信模式非常理想，但是有一些問題需要解決：
- 客戶端通信之前，必須知曉接受端的公網IP和端口
- 客戶端的p2p通信數據包必須能夠穿透NAT(network address translate) 網絡地址翻譯
解決方案：
- 第一個問題比較簡單，可以通過一台擁有公網IP的節點來記錄在線客戶端的公網IP和端口，所有客戶端可以通過該節點讀取接受客戶端的IP和port
- 第二個問題比較復雜，主要針對私有網絡之間的通信，由於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），混合（將多個傳入流轉換為一個單一的復合流） ，轉碼（在不兼容的客戶端之間適應編解碼器和格式），錄制（以持久的方式存儲對等體之間交換的媒體）等。
媒體服務器的好處有如下幾點：
- 擴展了系統性能和功能，來支持更為復雜的應用場景；
- 所有媒體流經由媒體服務器的一個好處是可以進行記錄，這對於一些需要保留會議紀要的場景是非常有用的；
- 可以方便的和第三方系統進行集成；
- 可以對媒體流進行額外的加工處理，比如通過人工智能人臉識別來給播客添加虛擬的帽子。
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 流媒體選型要考慮的主要因素
- 你是否深刻理解其代碼？
- 代碼版本是否足夠新？
- 有誰在使用它？
- 它的文檔是否齊全？
- 它可以debug嗎？
- 它可以伸縮嗎？
- 它使用哪種語言？
對於媒體服務器而言，這種語言的性能是否足夠？
團隊是否足夠了解這門語言？ - 是否適應你現有的Signaling范式？
你在看的Media Server是否容易與你決定使用的STUN/TURN服務器集成 - 許可證是否適合你？
- 誰在提供支持？
很多成功的、被良好維護的開源項目背后都有一個商業模式，尤其是中小型的項目，這意味着有一個團隊以此為謀生手段。
具備可選的付費支持意味着：- 有人願意全職來改善這東西，而不是作為愛好來維護。
- 如果你需要緊急幫助，只要花錢就能得到。
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多
- 社區活躍度高
from： https://blog.csdn.net/huahao1989/article/details/106318054