視頻直播中用戶連麥技術模型與特色分析

0 隨着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模式稍差
• 與前兩個模型比較，實現複雜度最高