本文章來源與網絡（視頻直播中用戶連麥技術模型與特點分析 - 老頭慢慢飛 - 博客園）

? ? 隨著Web與移動視頻直播應用的深度發展，有用戶參與互動的視頻直播技術被越來越多平臺所支持，原來的RTMP流媒體方案由于延時較多，無法滿足即時互動需求，本文提出幾種互動視頻直播模型（只是想法不代表實際應用中是這樣做的）分享給大家，供進一步討論。

1?P2P

1.1?模型圖

1.2 說明

? ? ?連麥用戶向信令服務器發送連麥請求，信令服務器通知連麥主用戶，若接受，雙方向TURN請求各自本端IP或TURN端分配好的公網IP，通過信令服務器交換又方的網絡信息，雙方優先以P2P方式嘗試聯接對方的公網IP地扯，若超時失敗，嘗試聯接對方在TURN服務器分配的IP與端口號，這時通過TURN服務器中轉雙方媒體流，保證無論如何P2P都是可成功的，然后連麥主用戶混音、混屏后將多媒體流以RTMP方式發送給弱實時流媒體服務器集群，同時發送本端非混音、混屏碼流給連麥用戶A，連麥用戶A切斷從弱實時流媒體系統獲取音視頻流，開始接受連麥主用戶的媒體流解碼渲染并且同時將本端采集到的媒體流編碼后發送給連麥主用戶，供連麥主用戶端播放輸出與混音、混屏。

1.3 特點

? ? 適合單個主播同時與少數（2個左右）用戶同時連麥

? ? 增加主播端終端性能壓力

? ? 主要實現集中于客戶端，可參考WEBRTC實現

? ? 連麥碼流采用高實性協議傳輸

? ? 少了服務器中轉環節，更低的時延

? ? 弱侵入性，對現有弱實時流系統無需大規模改造

? ? 不增加服務器帶寬流量

2

2.1?模型圖

2.2 說明

? ? 連麥用戶A通過信令控制服務器向連麥主用戶請求連麥，連麥主同意后，連麥用戶A向高實時流媒體服務器發送媒體流，同時信令控制服務器向所有觀眾廣播準備好獲取連麥用戶的媒體流，連麥主播與所有觀眾端接受到連麥用戶A的媒體流后分別解碼，轉出時若為連麥主用戶直接語音直接輸出到音頻設備并且視頻要混屏渲染，若為觀眾要混音、混屏后輸出給音頻設備與渲染到屏幕；連麥用戶A不需要斷開接受連麥主用戶的媒體流，跟據需要只混屏或不混屏顯示視頻即可。

2.3 特點

? ? 適合多個主播與多用戶互動場景

? ? 高實時流媒體系統復雜度與耦合性較低，便于擴展

? ? 服務器端由于不需要混音、混屏CPU壓力低

? ? 主要實現集中于服務器端，便于服務升級

? ? 帶寬過大

? ? 對于觀眾端來說，連麥主用戶與連麥用戶A的媒體流間時序差

? ? 高侵入性，要對現在弱實時流媒體系統進行大規模改造

3

3.1?模型圖

3.2 說明

? ? 連麥用戶A通過信令控制服務器發連麥主用戶發起連麥請求，連麥主用戶同意后，連麥用戶A斷開弱媒體流，同時向高實時流媒體服務器獲取連麥主用戶媒體并且發布自身媒體流，連麥主用戶通過也通過高實時流媒體服務器獲取連麥用戶的媒體后，在高實時流媒體服務器收到連麥用戶的媒體流后，開始解碼、混音、混屏、重編碼按原來的通道發送媒體流至弱實時流媒體服務器，觀眾端即可感知到混合后的媒體。

3.3 特點

? ? 適合多個主播與多用戶互動場景

? ? 流量較低，連麥用戶上下麥，觀眾端幾呼無感知

? ? 由于服務器端混音、混屏，加大服務器端壓力

? ? 侵入性適中，弱實時流媒體系統可維持不變

? ?實時性較P2P模式稍差

? ? 與前兩個模型比較，實現復雜度最高

作者：鉑淵信息技術
鏈接：https://www.jianshu.com/p/d525a4ca1d17
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯系作者獲得授權并注明出處。

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的视频直播中用户连麦技术模型与特点分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。