互動直播之WebRTC服務開源技術(shù)選型

【轉(zhuǎn)載請注明出處】：http://www.reibang.com/p/73f2615dc3ef

1 直播基礎知識

最原始的直播系統(tǒng)其實并沒有想象的那么復雜性置，無非就是主播端將音視頻數(shù)據(jù)推送到服務器之碗，觀眾端則從服務器拉取數(shù)據(jù)播放尾菇。

1.1 基本常識

1.1.1 基礎概念

推流
推流曲掰，是直播中的一個術(shù)語，意思是將流媒體數(shù)據(jù)推送到服務器了袁。如何推流执赡，關(guān)鍵就在于使用的推流協(xié)議脸狸。
拉流
拉流，指的是觀眾端流媒體數(shù)據(jù)的拉取称开，同樣也需要通過約定的拉流協(xié)議來拉取狞膘。
視頻幀
幀褒繁，是視頻的一個基本概念测暗，表示一張畫面褒傅，如上面的翻頁動畫書中的一頁馒吴，就是一幀秸歧。一個視頻就是由許許多多幀組成的。
幀率
幀率戒努，即單位時間內(nèi)幀的數(shù)量，單位為：幀/秒或fps（frames per second）唤崭。如動畫書中，一秒內(nèi)包含多少張圖片，圖片越多，畫面越順滑，過渡越自然。
幀率的一般以下幾個典型值：
- 24/25 fps：1秒 24/25 幀，一般的電影幀率。
- 30/60 fps：1秒 30/60 幀胸懈，游戲的幀率羔挡，30幀可以接受洁奈，60幀會感覺更加流暢逼真。
- 85 fps以上人眼基本無法察覺出來了绞灼，所以更高的幀率在視頻里沒有太大意義利术。
色彩空間
這里我們只講常用到的兩種色彩空間。
- RGB
  RGB的顏色模式應該是我們最熟悉的一種低矮，在現(xiàn)在的電子設備中應用廣泛印叁。通過R G B三種基礎色，可以混合出所有的顏色军掂。
- YUV
  YUV是一種亮度與色度分離的色彩格式轮蜕。早期的電視都是黑白的，即只有亮度值蝗锥，即Y跃洛。有了彩色電視以后，加入了UV兩種色度终议，形成現(xiàn)在的YUV汇竭，也叫YCbCr。
  Y：亮度穴张，就是灰度值细燎。除了表示亮度信號外，還含有較多的綠色通道量皂甘。
  U：藍色通道與亮度的差值玻驻。
  V：紅色通道與亮度的差值。

因為人眼對亮度敏感偿枕，對色度不敏感璧瞬，因此減少部分UV的數(shù)據(jù)量，人眼卻無法感知出來益老，這樣可以通過壓縮UV的分辨率彪蓬，在不影響觀感的前提下，減小視頻的體積捺萌。

采樣率
采樣率即采樣的頻率。采樣率要大于原聲波頻率的2倍膘茎，人耳能聽到的最高頻率為20kHz桃纯，所以為了滿足人耳的聽覺要求，采樣率至少為40kHz披坏，通常為44.1kHz态坦，更高的通常為48kHz。
采樣位數(shù)
采樣位數(shù)涉及到聲波的振幅量化棒拂。波形振幅在模擬信號上也是連續(xù)的樣本值伞梯，而在數(shù)字信號中玫氢，信號一般是不連續(xù)的，所以模擬信號量化以后谜诫，只能取一個近似的整數(shù)值漾峡，為了記錄這些振幅值，采樣器會采用一個固定的位數(shù)來記錄這些振幅值喻旷，通常有8位生逸、16位、32位且预。位數(shù)越多槽袄，記錄的值越準確，還原度越高锋谐。
由于數(shù)字信號是由0遍尺，1組成的，因此涮拗，需要將幅度值轉(zhuǎn)換為一系列0和1進行存儲乾戏，也就是編碼，最后得到的數(shù)據(jù)就是數(shù)字信號：一串0和1組成的數(shù)據(jù)多搀。
聲道數(shù)
聲道數(shù)歧蕉，是指支持能不同發(fā)聲（注意是不同聲音）的音響的個數(shù)。
單聲道：1個聲道
雙聲道：2個聲道
立體聲道：默認為2個聲道
立體聲道（4聲道）：4個聲道
碼率
碼率康铭，是指一個數(shù)據(jù)流中每秒鐘能通過的信息量惯退，單位bps（bit per second）
碼率 = 采樣率 * 采樣位數(shù) * 聲道數(shù)

1.1.2 視頻編碼

編碼可以大大減小音視頻數(shù)據(jù)的大小，讓音視頻更容易存儲和傳送从藤。視頻編碼格式有很多催跪，比如H26x系列和MPEG系列的編碼，這些編碼格式都是為了適應時代發(fā)展而出現(xiàn)的夷野。
其中懊蒸，H26x（1/2/3/4/5）系列由ITU（International Telecommunication Union）國際電傳視訊聯(lián)盟主導。MPEG（1/2/3/4）系列由MPEG（Moving Picture Experts Group, ISO旗下的組織）主導悯搔。

1.1.3 音頻編碼

原始的PCM音頻數(shù)據(jù)也是非常大的數(shù)據(jù)量骑丸，因此也需要對其進行壓縮編碼。
和視頻編碼一樣妒貌，音頻也有許多的編碼格式通危，如：WAV、MP3灌曙、WMA菊碟、APE、FLAC等等在刺。
在MP4視頻中的音頻數(shù)據(jù)逆害，大多數(shù)時候都是采用AAC壓縮格式头镊。AAC是新一代的音頻有損壓縮技術(shù)，一種高壓縮比的音頻壓縮算法魄幕。

1.1.4 音視頻容器

我們熟悉的視頻格式相艇，如mp4、rmvb梅垄、avi厂捞、mkv、mov...队丝，其實是包裹了音視頻編碼數(shù)據(jù)的容器靡馁，用來把以特定編碼標準編碼的視頻流和音頻流混在一起，成為一個文件机久。
例如：mp4支持H264臭墨、H265等視頻編碼和AAC、MP3等音頻編碼膘盖。

1.1.5 硬解碼和軟解碼

在手機或者PC上胧弛，都會有CPU、GPU或者解碼器等硬件侠畔。通常结缚，我們的計算都是在CPU上進行的，也就是我們軟件的執(zhí)行芯片软棺，而GPU主要負責畫面的顯示（是一種硬件加速）红竭。

所謂軟解碼，就是指利用CPU的計算能力來解碼喘落，通常如果CPU的能力不是很強的時候茵宪，一則解碼速度會比較慢，二則手機可能出現(xiàn)發(fā)熱現(xiàn)象瘦棋。但是稀火，由于使用統(tǒng)一的算法，兼容性會很好赌朋。

硬解碼凰狞，指的是利用手機上專門的解碼芯片來加速解碼。通常硬解碼的解碼速度會快很多沛慢，但是由于硬解碼由各個廠家實現(xiàn)服球，質(zhì)量參差不齊，非常容易出現(xiàn)兼容性問題颠焦。

1.2 基礎直播流程

通過下面這個數(shù)據(jù)流程圖，能清晰地看到整個直播的過程往枣。

image.png

可以看到伐庭，主播客戶端 處理的事情粉渠，其實就是短視頻開發(fā)中最重要的內(nèi)容：

流程	詳細操作
音視頻數(shù)據(jù)采集	通過攝像頭和麥克風采集
音視頻濾鏡	通過 OpenGL 和 SoundTouch 等工具實現(xiàn)音視頻編輯
音視頻編碼	通過系統(tǒng)硬編碼或 FFmpeg 軟編碼，將數(shù)據(jù)編碼為 H264 和 AAC
數(shù)據(jù)封裝打包	將編碼好的數(shù)據(jù)封裝成指定的格式

唯一不一樣的地方圾另，短視頻會將封裝好的數(shù)據(jù)保存到本地霸株，直播則是通過 推流協(xié)議 將數(shù)據(jù)推送到服務器。

1.3 直播中的重難點

在直播中集乔，有幾個非常重要的地方去件，會直接影響直播效果，導致用戶流失扰路。

1.3.1 首屏時間

首屏時間尤溜，即從觀眾打開直播，到看到畫面呈現(xiàn)出來的時間汗唱。影響這個時間的是 H264 編碼中的一個概念： GOP 宫莱。
GOP：Group of Picture，即一組幀組成的一個序列哩罪。在 H264 中授霸，分別有 I幀、P幀际插、B幀三種幀類型碘耳。GOP 就是由一個 I幀 和多個 P幀 或 B幀 組成的一組相近的畫面。

在H264中框弛，三種類型的幀數(shù)據(jù)分別為
I幀：幀內(nèi)編碼幀辛辨。就是一個完整幀。
P幀：前向預測編碼幀功咒。是一個非完整幀愉阎，通過參考前面的I幀或P幀生成。
B幀：雙向預測內(nèi)插編碼幀力奋。參考前后圖像幀編碼生成榜旦。B幀依賴其前最近的一個I幀或P幀及其后最近的一個P幀。

image.png

解碼器可以直接解碼I幀 景殷，但是P幀和B幀必須依賴I幀溅呢，或者前后的P或B才能解碼。首次連上直播間時猿挚，需要拋棄掉P和B幀咐旧，等待I幀。所以绩蜻，影響首屏時間最重要的因素就是I幀铣墨，也就是兩個GOP之間的間隔時間。

GOP 間隔的設置并非越小越好办绝，太小則兩個I幀之間的P/B幀越少伊约，壓縮率越低姚淆，畫面質(zhì)量越差，需要做好權(quán)衡屡律。

1.3.2 穩(wěn)定性問題

我們知道網(wǎng)絡是不穩(wěn)定的腌逢，經(jīng)常會出現(xiàn)網(wǎng)速慢，甚至斷網(wǎng)的問題超埋，所以穩(wěn)定性優(yōu)化也是非常重要的搏讶。比如以下幾個方面：

碼率控制
同樣分辨率下，碼率越高霍殴，視頻越清晰媒惕，同時需要的帶寬也越大。相反繁成，碼率越低吓笙，視頻越模糊，數(shù)據(jù)越小巾腕。
弱網(wǎng)優(yōu)化
根據(jù)不同的網(wǎng)速切換不同的碼率進行播放等面睛。
斷線重連
網(wǎng)絡斷開時的重聯(lián)機制。

1.3.3 全局負載均衡

隨著業(yè)務的發(fā)展尊搬，如果主播和觀眾的數(shù)量越來越多以后叁鉴，系統(tǒng)可能會面臨高并發(fā)情景，直播卡頓佛寿，甚至系統(tǒng)奔潰幌墓，解決這種情況的一個好辦法就是使用 CDN 。

CDN內(nèi)容分發(fā) 解決因分布冀泻、帶寬常侣、服務器性能帶來的訪問延遲問題，適用于站點加速弹渔、點播胳施、直播。

加入 CDN 后肢专，整個直播系統(tǒng)架構(gòu)如下：

image.png

1.3.4 其他

除了以上提到的內(nèi)容舞肆，當今的直播系統(tǒng)還要包括以下內(nèi)容：錄制、轉(zhuǎn)碼博杖、鑒黃椿胯、截屏、權(quán)鑒防盜剃根、回聲消除哩盲、連麥等等，整套下來，需要非常多的知識儲備种冬，以及大量的時間精力镣丑，才能完成。

1.4 幾種常見的流媒體網(wǎng)絡傳輸協(xié)議

直播協(xié)議包含了上面提到的 推流 和 拉流 協(xié)議娱两。

1.4.1 RTP

實時傳輸協(xié)議（Real-time Transport Protocol，縮寫RTP）是一個網(wǎng)絡傳輸協(xié)議金吗，它是由IETF的多媒體傳輸工作小組1996年在RFC 1889中公布的十兢。

RTP協(xié)議詳細說明了在互聯(lián)網(wǎng)上傳遞音頻和視頻的標準數(shù)據(jù)包格式。它一開始被設計為一個多播協(xié)議摇庙，但后來被用在很多單播應用中旱物。RTP協(xié)議常用于流媒體系統(tǒng)（配合RTSP協(xié)議），視頻會議和一鍵通（Push to Talk）系統(tǒng)（配合H.323或SIP）卫袒，使它成為IP電話產(chǎn)業(yè)的技術(shù)基礎宵呛。RTP協(xié)議和RTP控制協(xié)議RTCP一起使用，而且它是創(chuàng)建在UDP協(xié)議上的夕凝。

1.4.2 RTMP

實時消息協(xié)議（Real-Time Messaging Protocol宝穗，縮寫RTMP）也稱實時消息傳輸協(xié)議，是最初由Macromedia為通過互聯(lián)網(wǎng)在Flash播放器與一個服務器之間傳輸流媒體音頻码秉、視頻和數(shù)據(jù)而開發(fā)的一個專有協(xié)議逮矛。Macromedia后被Adobe Systems收購，該協(xié)議也已發(fā)布了不完整的規(guī)范供公眾使用转砖。

RTMP協(xié)議有許多變種：

默認使用TCP端口1935的純粹（plain）協(xié)議须鼎。
RTMPS，通過一個TLS/SSL連接傳輸RTMP府蔗。
RTMPE晋控，使用Adobe自有安全機制加密的RTMP。雖然實現(xiàn)的細節(jié)為專有姓赤，但該機制使用行業(yè)標準的密碼學原函數(shù)赡译。
RTMPT，用HTTP封裝以穿透防火墻模捂。RTMPT通常在TCP通信端口80和443上使用明文請求來繞過大多數(shù)的公司流量過濾捶朵。封裝的會話中可能攜帶純粹的RTMP、RTMPS或RTMPE數(shù)據(jù)包狂男。
RTMFP, 使用UDP而非TCP的RTMP综看，取代RTMP Chunk Stream。Adobe Systems開發(fā)了安全的實時媒體流協(xié)議包岖食，可以讓最終用戶直接地相互連接（P2P）红碑。

1.4.3 WebRTC標準

WebRTC是一個由谷歌、Mozilla和Opera等支持的開源技術(shù)。它通過簡單的api為瀏覽器和移動應用程序提供實時通信(RTC)功能析珊。為瀏覽器羡鸥、移動平臺和物聯(lián)網(wǎng)設備開發(fā)豐富、高質(zhì)量的RTC應用程序忠寻，并允許它們通過一組通用協(xié)議進行通信惧浴。
支持的瀏覽器和平臺：

Chrome
Firefox
Opera
Android
iOS

特點：

基于瀏覽器，且主流瀏覽器都支持奕剃，跨平臺能力強
默認P2P衷旅，但是需要TURN服務器作為fallback
自適應碼率

1.4.4 HLS

HTTP Live Streaming（縮寫是HLS）是一個由蘋果公司提出的基于HTTP的流媒體網(wǎng)絡傳輸協(xié)議。它的工作原理是把整個流分成一個個小的基于HTTP的文件來下載纵朋，每次只下載一些柿顶。當媒體流正在播放時，客戶端可以選擇從許多不同的備用源中以不同的速率下載同樣的資源操软，允許流媒體會話適應不同的數(shù)據(jù)速率嘁锯。在開始一個流媒體會話時，客戶端會下載一個包含元數(shù)據(jù)的extended M3U (m3u8) playlist文件聂薪，用于尋找可用的媒體流家乘。
HLS只請求基本的HTTP報文，與實時傳輸協(xié)議（RTP）不同胆建，HLS可以穿過任何允許HTTP數(shù)據(jù)通過的防火墻或者代理服務器烤低。它也很容易使用內(nèi)容分發(fā)網(wǎng)絡（CDN）來傳輸媒體流。

2 WebRTC技術(shù)

2.1 為什么選擇WebRTC

目前 WebRTC 提供了在 Web笆载、iOS扑馁、Android、Mac凉驻、Windows腻要、Linux 在內(nèi)的所有平臺的 API，保證了 API 在所有平臺的一致性涝登。使用 WebRTC 的好處主要有以下幾個方面：

免費的使用 GIPS 先進的音視頻引擎雄家；
由于音視頻傳輸是基于點對點傳輸?shù)模詫崿F(xiàn)簡單的 1 對 1 通話場景胀滚，需要較少的服務器資源趟济，借助免費的 STUN/TURN 服務器可以大大節(jié)約成本開銷；
開發(fā) Web 版本的應用非常方便咽笼，使用簡單的 JS 接口顷编，無需安裝任何插件，即可實現(xiàn)音視頻互通剑刑；
WebRTC 適用的場景非常廣泛媳纬，如當下比較火的社交双肤、游戲、體育钮惠、電視茅糜、相親類的直播，以及互動連麥素挽、在線教育蔑赘、在線醫(yī)療、金融證券在線開戶毁菱、智能硬件（如無人機）米死、智能家居設備如攝像頭監(jiān)控以及智能語音設備；
WebRTC還可以錄制音視頻到本地文件贮庞；
WebRTC提供音視頻加密功能；
WebRTC最大的優(yōu)勢就是“標準化”究西，它解決的問題就是給所有需要進行實時通信的終端提供一套統(tǒng)一的窗慎、開放的實時通信能力描述和連接建立標準；

2.2 什么是打洞服務器

P2P(peer to peer)對等通信卤材。即在p2p的網(wǎng)絡中遮斥，所有網(wǎng)絡節(jié)點都是同等地位，沒有服務端和客戶端之分扇丛，一個節(jié)點即是服務端也是客戶端术吗。客戶端之間可以進行直接的通信帆精，不需要在經(jīng)過服務端的中轉(zhuǎn)较屿，從而提高網(wǎng)絡傳輸速度和減小服務器壓力，這是非常有用的卓练。P2P雖然通信模式非常理想隘蝎，但是有一些問題需要解決：

客戶端通信之前，必須知曉接受端的公網(wǎng)IP和端口
客戶端的p2p通信數(shù)據(jù)包必須能夠穿透NAT(network address translate) 網(wǎng)絡地址翻譯

解決方案：

第一個問題比較簡單襟企，可以通過一臺擁有公網(wǎng)IP的節(jié)點來記錄在線客戶端的公網(wǎng)IP和端口嘱么，所有客戶端可以通過該節(jié)點讀取接受客戶端的IP和port
第二個問題比較復雜，主要針對私有網(wǎng)絡之間的通信顽悼，由于ip的匱乏曼振，所以網(wǎng)絡上不可能所有節(jié)點都位于同一個網(wǎng)段（即擁有公網(wǎng)IP）

事實上，大部分的節(jié)點都處于常規(guī)網(wǎng)絡的邊緣蔚龙，甚至在DNS所能查詢的范圍之外冰评，所以在處于網(wǎng)絡的邊緣的節(jié)點不能直接通信的。

為了能讓客戶端在不同的網(wǎng)絡之間通信府蛇，我們就需要穿過防火墻集索，而且我們還要面對ISP所設置的種種限制。所以為了繞開這些限制，以及在接收端的防火墻上打開一個口讓媒體通過务荆，我們就需要依賴STUN/TURN服務器妆距，目的是找到一條正確的路徑（STUN），或者是作為一個中繼服務器用來傳輸媒體（TURN）

image.png

上圖中的Relay server即為TURN中繼服務器函匕，而STUN server的作用是通過收集NAT背后peer端(即：躲在路由器或交換機后的電腦）對外暴露出來的ip和端口娱据，找到一條可穿透路由器的鏈路，俗稱“打洞”盅惜。STUN/TURN服務器通常要部署在公網(wǎng)上中剩，能被所有peer端訪問到。

2.3 什么是WebRTC服務器

WebRTC被認為是一種點對點技術(shù)抒寂，瀏覽器可以直接通信而無需任何類型的基礎設施结啼。此模型足以創(chuàng)建基本應用程序，但難以在其之上實現(xiàn)諸如組通信屈芜，媒體流記錄郊愧，媒體廣播或媒體轉(zhuǎn)碼之類的功能。因此井佑，許多應用程序都需要使用媒體服務器属铁。

image.png

從概念上講，WebRTC媒體服務器只是一種“多媒體中間件”躬翁，從源到目的地時焦蘑，媒體流量會通過該中間件。媒體服務器能夠處理媒體流并提供不同的類型盒发，包括組通信（將一個對等方生成的媒體流分配給多個接收方例嘱，即充當多會議單元，MCU）迹辐，混合（將多個傳入流轉(zhuǎn)換為一個單一的復合流）蝶防，轉(zhuǎn)碼（在不兼容的客戶端之間適應編解碼器和格式），錄制（以持久的方式存儲對等體之間交換的媒體）等明吩。
媒體服務器的好處有如下幾點：

擴展了系統(tǒng)性能和功能间学，來支持更為復雜的應用場景；
所有媒體流經(jīng)由媒體服務器的一個好處是可以進行記錄印荔，這對于一些需要保留會議紀要的場景是非常有用的低葫；
可以方便的和第三方系統(tǒng)進行集成；
可以對媒體流進行額外的加工處理仍律，比如通過人工智能人臉識別來給播客添加虛擬的帽子嘿悬。

2.4 WebRTC通信模式

當媒體服務器充當媒體中繼時，它通常被稱為SFU（Selective Forwarding Unit選擇性轉(zhuǎn)發(fā)單位）水泉，這意味著其主要目的是在客戶端之間轉(zhuǎn)發(fā)媒體流善涨。還有一個MCU（Multipoint Conferencing Unit多點會議單元）的概念窒盐，MCU服務器不僅可以轉(zhuǎn)發(fā)，而且可以對媒體流進行混合和編碼壓縮（比如把各個客戶端的數(shù)據(jù)打包轉(zhuǎn)發(fā)钢拧，和SFU相比，這樣將大幅度降低轉(zhuǎn)發(fā)數(shù)據(jù)的帶寬需求葡粒，但對CPU有更高的要求）膜钓。

image.png

2.4.1 Mesh架構(gòu)

每個端都與其它端互連嗽交。以上圖最左側(cè)為例颂斜，5個瀏覽器，二二建立p2p連接，每個瀏覽器與其它4個建立連接，總共需要10個連接比肄。如果每條連接占用1m帶寬痊焊，則每個端上行需要4m凭语，下行帶寬也要4m似扔，總共帶寬消耗20m。而且除了帶寬問題豪墅，每個瀏覽器上還要有音視頻“編碼/解碼”黔寇，cpu使用率也是問題，一般這種架構(gòu)只能支持4-6人左右屏轰，不過優(yōu)點也很明顯憋飞，沒有中心節(jié)點榛做，實現(xiàn)很簡單内狸。

優(yōu)點：

邏輯簡單昆淡，容易實現(xiàn)
服務端比較 “輕量”驴党，TURN 服務器比較簡單，一定比例的 P2P 成功率可極大減輕服務端的壓力

缺點：

每新增一個客戶端倔既，所有的客戶端都需要新增一路數(shù)據(jù)上行鹏氧，客戶端上行帶寬占用太大把还。因此实蓬，通話人數(shù)越多吊履，效果越差
無法在服務端對視頻進行額外處理艇炎，如：錄制存儲回放、實時轉(zhuǎn)碼居砖、智能分析驴娃、多路合流唇敞、轉(zhuǎn)推直播等等

2.4.2 MCU (MultiPoint Control Unit)

這是一種傳統(tǒng)的中心化架構(gòu)(上圖中間部分)，每個瀏覽器僅與中心的MCU服務器連接蕉世，MCU服務器負責所有的視頻編碼狠轻、轉(zhuǎn)碼彬犯、解碼、混合等復雜邏輯湖蜕，每個瀏覽器只要1個連接昭抒，整個應用僅消耗5個連接，帶寬占用(包括上行盗迟、下行）共10m罚缕，瀏覽器端的壓力要小很多怎静，可以支持更多的人同時音視頻通訊蚓聘，比較適合多人視頻會議。但是MCU服務器的壓力較大导饲，需要較高的配置。

以前在電信行業(yè)做視頻會議一般都使用MCU(Multipoint Control Unit)硝岗，也就是多方推流在MCU上進行合流型檀，在拉流的時候只有一路合流，這樣的好處是無論幾方推流裂七，拉流只有一路背零，下行帶寬比較小无埃。但是問題也比較多，只要推流方一多灵疮，MCU的壓力就比較大壳繁，而且分布式的部署也比較難闹炉，成本又很高。

2.4.3 SFU(Selective Forwarding Unit)

上圖右側(cè)部分诉植，咋一看昵观，跟MCU好象沒什么區(qū)別啊犬，但是思路不同觉至，仍然有中心節(jié)點服務器，但是中心節(jié)點只負責轉(zhuǎn)發(fā)峻贮，不做太重的處理纤控，所以服務器的壓力會低很多碉纺，配置也不象MUC要求那么高骨田。但是每個端需要建立一個連接用于上傳自己的視頻，同時還要有N-1個連接用于下載其它參與方的視頻信息舱呻。所以總連接數(shù)為5*5狮荔，消耗的帶寬也是最大的，如果每個連接1M帶寬晚树，總共需要25M帶寬雅采，它的典型場景是1對N的視頻互動婚瓜。
SFU 服務器最核心的特點是把自己 “偽裝” 成了一個 WebRTC 的 Peer 客戶端巴刻，WebRTC 的其他客戶端其實并不知道自己通過 P2P 連接過去的是一臺真實的客戶端還是一臺服務器，我們通常把這種連接稱之為 P2S沥寥，即：Peer to Server邑雅。除了 “偽裝” 成一個 WebRTC 的 Peer 客戶端外妈经，SFU 服務器還有一個最重要的能力就是具備 one-to-many 的能力吹泡，即可以將一個 Client 端的數(shù)據(jù)轉(zhuǎn)發(fā)到其他多個 Client 端爆哑。

這種網(wǎng)絡拓撲結(jié)構(gòu)中妈踊，無論多少人同時進行視頻通話，每個 WebRTC 的客戶端只需要連接一個 SFU 服務器萝勤，上行一路數(shù)據(jù)即可呐伞，極大減少了多人視頻通話場景下 Mesh 模型給客戶端帶來的上行帶寬壓力伶氢。

SFU 服務器跟 TURN 服務器最大的不同是，TURN 服務器僅僅是為 WebRTC 客戶端提供的一種輔助的數(shù)據(jù)轉(zhuǎn)發(fā)通道掌眠，在 P2P 不通的時候進行透明的數(shù)據(jù)轉(zhuǎn)發(fā)幕屹。而 SFU 是 “懂業(yè)務” 的望拖，它跟 WebRTC 客戶端是平等的關(guān)系说敏，甚至 “接管了” WebRTC 客戶端的數(shù)據(jù)轉(zhuǎn)發(fā)的申請和控制。

現(xiàn)在互聯(lián)網(wǎng)行業(yè)比較流行的是SFU(Selective Forwarding Unit)医咨，簡單說就是只負責轉(zhuǎn)發(fā)流腋逆，不負責合流侈贷，壓力很小俏蛮。這樣的模式可以依托CDN進行分布式的部署搏屑，不過拉流的方數(shù)限于客戶端的帶寬和處理能力。

2.4.4 為啥推薦選擇 SFU 亮垫？

純 mesh 方案無法適應多人視頻通話饮潦，也無法實現(xiàn)服務端的各種視頻處理需求携狭，最先排除在商業(yè)應用之外。

SFU 相比于 MCU仅颇，服務器的壓力更械饩佟（純轉(zhuǎn)發(fā)殴俱，無轉(zhuǎn)碼合流）线欲，靈活性更好（可選擇性開關(guān)任意一路數(shù)據(jù)的上下行等），受到更廣泛的歡迎和應用苦锨，常見的開源 SFU 服務器有：Licode舟舒，Kurento秃励，Janus吉捶，Jitsi呐舔，Mediasoup等珊拼。

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

3 開源方案

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

你是否深刻理解其代碼？
代碼版本是否足夠新？
有誰在使用它盅视？
它的文檔是否齊全闹击？
它可以debug嗎赏半？
它可以伸縮嗎淆两？
它使用哪種語言秋冰？
對于媒體服務器而言剑勾，這種語言的性能是否足夠虽另？
團隊是否足夠了解這門語言？
是否適應你現(xiàn)有的Signaling范式谣拣？
你在看的Media Server是否容易與你決定使用的STUN/TURN服務器集成
許可證是否適合你芝发？
誰在提供支持辅鲸？
很多成功的独悴、被良好維護的開源項目背后都有一個商業(yè)模式锣尉，尤其是中小型的項目自沧，這意味著有一個團隊以此為謀生手段。
具備可選的付費支持意味著：
- 有人愿意全職來改善這東西晒喷，而不是作為愛好來維護访敌。
- 如果你需要緊急幫助寺旺，只要花錢就能得到阻塑。

3.2 Jitsi

https://github.com/jitsi/jitsi
Jitsi是一個免費的開源音頻/視頻和聊天通信器叮姑，它支持SIP、XMPP/Jabber耘沼、AIM/ICQ群嗤、IRC和許多其他有用的特性狂秘。

Jitsi不僅是WebRTC媒體服務器者春，而且還有一個完整的平臺钱烟。 Jitsi系列產(chǎn)品包括Jitsi Videobridge（媒體中繼嫡丙，SFU）曙博，Jitsi Meet（會議網(wǎng)絡客戶端）父泳，Jicofo（Jitsi Conference Focus），Jigasi（Jitsi Gateway to SIP）和Jitsi SIP Phone浇坐。借助Jitsi我們能在幾個小時之內(nèi)迅速搭建一個完整可用的通信平臺。它還使用Jingle（XMPP）和功能齊全的Web界面實現(xiàn)自己的信令控制臀晃。然而徽惋，令人遺憾的是座韵，它對于媒體錄制沒有提供穩(wěn)定易用的解決方案誉碴。

3.3 Kurento

https://github.com/Kurento/kurento-media-server
Kurento是WebRTC媒體服務器和一組客戶端API黔帕，可簡化針對WWW和智能手機平臺的高級視頻應用程序的開發(fā)成黄。Kurento Media Server的功能包括組通信奋岁，音視頻流的轉(zhuǎn)碼闻伶，記錄虾攻，混合霎箍，廣播和路由漂坏。

作為一項與眾不同的功能媒至，Kurento Media Server還提供了高級媒體處理功能拒啰，包括計算機視覺谋旦，視頻索引册着，增強現(xiàn)實和語音分析甲捏。Kurento模塊化體系結(jié)構(gòu)簡化了第三方媒體處理算法（即語音識別司顿，情感分析大溜，面部識別等）的集成估脆，可以由應用程序開發(fā)人員透明地用作Kurento的其余內(nèi)置功能猎提。

Kurento Media Server通過稱為Kurento API的RPC API公開其所有功能∨园可以通過任何與JSON兼容的客戶端直接查詢該API锨苏，但是推薦的使用方法是通過Kurento客戶端庫。目前為Java棺聊，Browser Javascript和Node.js提供了這些工具伞租。

如果您喜歡其他編程語言，則可以遵循基于WebSocket和JSON-RPC的Kurento協(xié)議的規(guī)范來編寫自定義客戶端庫葵诈。

Kurento被設計為可插入框架，Kurento中的每個插件都稱為一個模塊祟同，可以使用新的自定義模塊擴展Kurento Media Server作喘。更多信息，請閱讀Kurento模塊部分晕城。

Kurento模塊體系結(jié)構(gòu)

擴展的Kurento工具箱

Kurento模塊分為三類：

主要模塊
與Kurento Media Server開箱即用合并：
- kms-core：Kurento Media Server的主要組件泞坦。
- kms-elements：Kurento Media Elements的實現(xiàn)（WebRtcEndpoint，PlayerEndpoint等）
- kms-filters：Kurento過濾器的實現(xiàn)（FaceOverlayFilter砖顷，ZBarFilter等）
內(nèi)置模塊
Kurento團隊開發(fā)的額外模塊贰锁，用于增強Kurento Media Server的基本功能赃梧。到目前為止，有四個內(nèi)置模塊豌熄，分別是：
- kms-pointerdetector：基于顏色跟蹤檢測視頻流中指針的過濾器授嘀。
- kms-chroma：過濾器，它在頂層使用顏色范圍并使之透明锣险，從而在后面顯示另一個圖像蹄皱。
- kms-crowddetector：用于檢測視頻流中人聚集的過濾器。
- kms-platedetector：用于檢測視頻流中的車牌的過濾器芯肤。
定制模塊
Kurento Media Server的擴展夯接，提供了新的媒體功能。

3.4 Licode

https://github.com/lynckia/licode
Licode基于WebRTC技術(shù)纷妆。它與Google Chrome的最新穩(wěn)定版本100％兼容。您的用戶將無需安裝任何內(nèi)容即可通過其Web瀏覽器進行交談晴弃。無需關(guān)心復雜的實時基礎架構(gòu)掩幢。它提供了基于HTML5的視頻會議功能的快速開發(fā)，使它100％可擴展上鞠。Licode允許您在網(wǎng)絡上包括電視會議室际邻。但是您也可以實現(xiàn)流媒體，錄制和您夢dream以求的任何其他實時多媒體功能芍阎！

主要模塊及實現(xiàn)語言：

Erizo：這是WebRTC多點控制單元（MCU）世曾。它是用C ++編寫的，并且與WebRTC標準及其協(xié)議100％兼容谴咸。
ErizoAPI：Erizo的Node.js插件包裝器轮听。它可以從Node.js應用程序配置和管理Erizo的各個方面！
Erizo控制器：這是服務的核心岭佳。它向用戶提供會議室以進行多方會議血巍。它還提供了足夠的安全性機制和附加功能：數(shù)據(jù)，用戶列表珊随，事件等述寡。
Nuve：該視頻會議管理API提供會議室管理，用戶對第三方應用程序的訪問控制和服務注冊叶洞。它還為服務提供了云可擴展性鲫凶。

3.5 Janus

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

Janus是由Meetecho開發(fā)的WebRTC服務器，被認為是通用服務器衩辟。因此螟炫，除了實現(xiàn)與瀏覽器建立WebRTC媒體通信，與之交換JSON消息以及在瀏覽器與服務器端應用程序邏輯之間中繼RTP / RTCP和消息的手段之外艺晴，它本身不提供任何功能不恭。服務器端插件提供了任何特定的功能/應用程序叶雹，然后瀏覽器可以通過Janus與之聯(lián)系，以利用它們提供的功能换吧。此類插件的示例可以是諸如回聲測試折晦，會議橋，媒體記錄器沾瓦，SIP網(wǎng)關(guān)等應用程序的實現(xiàn)满着。

這樣做的原因很簡單：我們想要的東西將具有 small footprint（因此是C實現(xiàn)），并且只能配備以前的東西really needed（因此可插入模塊）贯莺。就是說风喇，這使我們能夠在云上部署成熟的WebRTC網(wǎng)關(guān)，或者使用小型的nettop / box來處理特定的用例缕探。

其最顯著的特征之一是其插件架構(gòu)魂莫，可以增強服務的核心功能。有一些有趣的Janus用例爹耗，例如SIP Gateway耙考，屏幕共享等。

3.6 Mediasoup

https://github.com/versatica/mediasoup
由于其多功能性潭兽，性能和可伸縮性倦始，mediasoup成為構(gòu)建多方視頻會議和實時流應用程序的理想選擇。它具有聯(lián)播山卦，SVC鞋邑，傳輸BWE和其他更多先進功能。

除了創(chuàng)建另一個自帶服務器之外账蓉，mediasoup是一個Node.js模塊枚碗，可以將其集成到更大的應用程序中。mediasoup提供了一個低級API铸本，該API支持您的應用程序使用不同的用例视译。

mediasoup帶有mediasoup-client（JavaScript庫）和libmediasoupclient（C ++庫），用于構(gòu)建使用統(tǒng)一API在任何瀏覽器或設備中運行的應用程序归敬】岷或者只使用知名軟件，例如FFmpeg或GStreamer汪茧。

設計目標
mediasoup及其客戶端庫旨在實現(xiàn)以下目標：

成為SFU（選擇性轉(zhuǎn)發(fā)單元）椅亚。
支持WebRTC和普通RTP輸入和輸出。
在服務器端成為Node.js模塊舱污。
在客戶端成為小型JavaScript和C ++庫呀舔。
極簡主義：只處理媒體層。
與信號無關(guān)：不要強制使用任何信號協(xié)議。
是超低級的API媚赖。
支持所有現(xiàn)有的WebRTC端點霜瘪。
啟用與知名多媒體庫/工具的集成。

架構(gòu)

image.png

特征

ECMAScript 6低級API惧磺。
多流：通過單個ICE + DTLS傳輸?shù)亩鄠€音頻/視頻流颖对。
IPv6就緒。
UDP / TCP上的ICE / DTLS / RTP / RTCP磨隘。
同播和SVC支持缤底。
擁塞控制。
使用空間/時間層分布算法的發(fā)送者和接收者帶寬估計番捂。
SCTP支持（基于純UDP的WebRTC數(shù)據(jù)通道和SCTP）个唧。
極其強大（在libuv之上用C ++編碼的媒體工作程序子進程）。

它與其他媒體服務器的不同之處在于它被設計成一個用于Node的開發(fā)庫设预，這允許它可以被容易的集成到更大的應用程序中徙歼。

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

開源
支持SFU和MCU
支持音視頻流的轉(zhuǎn)碼鳖枕，記錄魄梯，混合，廣播和路由
內(nèi)置模塊我們將來可以直接用
API公開其所有功能耕魄，與語言無關(guān)，可以使用任何語言
可拔插框架彭谁，容易擴展
文檔豐富吸奴，demo多
社區(qū)活躍度高

【轉(zhuǎn)載請注明出處】： http://www.reibang.com/p/73f2615dc3ef