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

語言: CN / TW / HK

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 基礎直播流程

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

image.png 可以看到,主播客戶端 處理的事情,其實就是短視訊開發中最重要的內容:

image.png 唯一不一樣的地方,短視訊會將封裝好的資料儲存到本地,直播則是通過 推流協議 將資料推送到伺服器。

1.3 直播中的重難點

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

1.3.1 首屏時間

首屏時間,即從觀眾開啟直播,到看到畫面呈現出來的時間。影響這個時間的是 H264 編碼中的一個概念: GOPGOP:Group of Picture,即一組幀組成的一個序列。在 H264 中,分別有 I幀、P幀、B幀 三種幀型別。GOP 就是由一個 I幀 和多個 P幀B幀 組成的一組相近的畫面 。

在H264中,三種類型的幀資料分別為 I幀:幀內編碼幀。就是一個完整幀。 P幀:前向預測編碼幀。是一個非完整幀,通過參考前面的I幀或P幀生成。 B幀:雙向預測內插編碼幀。參考前後影象幀編碼生成。B幀依賴其前最近的一個I幀或P幀及其後最近的一個P幀。

image.png 解碼器可以直接解碼I幀 ,但是P幀B幀必須依賴I幀,或者前後的P或B才能解碼。首次連上直播間時,需要拋棄掉PB幀,等待I幀。所以,影響首屏時間最重要的因素就是I幀,也就是兩個GOP之間的間隔時間。\ GOP 間隔的設定並非越小越好,太小則兩個I幀之間的P/B幀越少,壓縮率越低,畫面質量越差,需要做好權衡。

1.3.2 穩定性問題

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

  • 位元速率控制 同樣解析度下,位元速率越高,視訊越清晰,同時需要的頻寬也越大。相反,位元速率越低,視訊越模糊,資料越小。
  • 弱網優化 根據不同的網速切換不同的位元速率進行播放等。
  • 斷線重連 網路斷開時的重聯機制。

1.3.3 全域性負載均衡

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

CDN內容分發 解決因分佈、頻寬、伺服器效能帶來的訪問延遲問題,適用於站點加速、點播、直播。

加入 CDN 後,整個直播系統架構如下:

image.png

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) image.png 上圖中的Relay server即為TURN中繼伺服器,而STUN server的作用是通過收集NAT背後peer端(即:躲在路由器或交換機後的電腦)對外暴露出來的ip和埠,找到一條可穿透路由器的鏈路,俗稱“打洞”。STUN/TURN伺服器通常要部署在公網上,能被所有peer端訪問到。

2.3 什麼是WebRTC伺服器

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

image.png 從概念上講,WebRTC媒體伺服器只是一種“多媒體中介軟體”,從源到目的地時,媒體流量會通過該中介軟體。媒體伺服器能夠處理媒體流並提供不同的型別,包括組通訊(將一個對等方生成的媒體流分配給多個接收方,即充當多會議單元,MCU),混合(將多個傳入流轉換為一個單一的複合流) ,轉碼(在不相容的客戶端之間適應編解碼器和格式),錄製(以持久的方式儲存對等體之間交換的媒體)等。 媒體伺服器的好處有如下幾點:

  1. 擴充套件了系統性能和功能,來支援更為複雜的應用場景;
  2. 所有媒體流經由媒體伺服器的一個好處是可以進行記錄,這對於一些需要保留會議紀要的場景是非常有用的;
  3. 可以方便的和第三方系統進行整合;
  4. 可以對媒體流進行額外的加工處理,比如通過人工智慧人臉識別來給播客新增虛擬的帽子。

2.4 WebRTC通訊模式

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

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

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

github.com/Kurento/kur… Kurento是WebRTC媒體伺服器和一組客戶端API,可簡化針對WWW和智慧手機平臺的高階視訊應用程式的開發。Kurento Media Server的功能包括組通訊,音視訊流的轉碼,記錄,混合,廣播和路由。

作為一項與眾不同的功能,Kurento Media Server還提供了高階媒體處理功能,包括計算機視覺,視訊索引,增強現實和語音分析。Kurento模組化體系結構簡化了第三方媒體處理演算法(即語音識別,情感分析,面部識別等)的整合,可以由應用程式開發人員透明地用作Kurento的其餘內建功能。

Kurento Media Server通過稱為Kurento API的RPC API公開其所有功能。可以通過任何與JSON相容的客戶端直接查詢該API,但是推薦的使用方法是通過Kurento客戶端庫。目前為JavaBrowser JavascriptNode.js提供了這些工具。

如果您喜歡其他程式語言,則可以遵循基於WebSocketJSON-RPCKurento協議的規範來編寫自定義客戶端庫。

Kurento被設計為可插入框架,Kurento中的每個外掛都稱為一個模組,可以使用新的自定義模組擴充套件Kurento Media Server。更多資訊,請閱讀Kurento模組部分。

image.png

image.png 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

github.com/lynckia/lic… 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

github.com/meetecho/ja…

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

這樣做的原因很簡單:我們想要的東西將具有 small footprint(因此是C實現),並且只能配備以前的東西really needed(因此可插入模組)。就是說,這使我們能夠在雲上部署成熟的WebRTC閘道器,或者使用小型的nettop / box來處理特定的用例。

其最顯著的特徵之一是其外掛架構,可以增強服務的核心功能。有一些有趣的Janus用例,例如SIP Gateway,螢幕共享等。

3.6 Mediasoup

github.com/versatica/m… 由於其多功能性,效能和可伸縮性,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端點。
  • 啟用與知名多媒體庫/工具的整合。

架構

image.png 特徵

  • 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多
  • 社群活躍度高