直播多人連麥技術簡介

前言

隨着直播行業的發展，平臺玩法愈來愈多。其中秀場連麥直播玩法人氣較高，一方面改變了主播與觀衆對立的體驗，另外一方面拉近了主播與觀衆的距離，對於拉動主播收入平臺營收起到了十分重要的做用。在此衍生出來的如PK，付費問答，語音連麥等玩法成爲各大直播平臺的標配。

本篇文章將分享直播移動端直播連麥的技術實現架構，僅爲拋磚引玉，爲各位在技術選型時提供必定的思路。歡迎交流。

技術架構

首先從技術架構的角度來講，直播連麥的實現方案大致能夠分爲三種。這三種方案都是前輩大佬們實踐總結出來的經驗。在此感謝。

傳統直播形式如圖所示，是一個主播推流，廣播給直播間全部的觀衆。而全部的觀衆進入直播間時，去拉去當前直播間主播的流。這裏的特徵是，一個直播間對應一個主播，而且僅有一路推拉流。

連麥的直播形式如圖所示，是兩個主播（另外一個主播多是觀衆）推流，廣播給直播間全部觀衆。而全部的觀衆進入直播間，並不必定是拉取一個流，一個直播間也並不必定對應的是一個主播，這些區別會在下文展開。這裏的特徵是兩個或以上主播。

1. 基於RTMP協議優化方案

此方案是在原有直播基礎上衍生出來的實現方案。主播A和主播B之間經過原有的推拉流路徑去拉取對方的流內容。也就是說，主播A在推流同時，拉取主播B的流，主播B推流的同時拉取主播A的流。對於兩個主播來講互爲對方的觀衆。此時對於直播間內的其餘觀衆而言，是分別拉取主播A和主播B的流，並展現出來。

能夠看出，主播A和主播B之間並沒有直接鏈接，而是經過拉取對方流來實現連麥。此方案優勢是技術實現相對簡單，服務端和客戶端可在原有的直播基礎上開發，兼容性好。可是缺點也是明顯的：理想狀況RTMP下的直播延遲大概須要3秒，主播AB之間的互動可能超過6秒，這在實際連麥體驗中是至關差的，另外觀衆須要同時拉取兩路流，對於網絡要求，流量消耗，性能消耗，時間對齊都是不小的問題。有人提出優化CDN鏈接方式，優化主播間的節點，增長BGP，在必定程度上能夠下降延遲。

在方案1的基礎上，咱們能夠總結出連麥的技術關鍵點：連麥的主播之間如何保證較低的延遲，提升實時性；主播之間的畫面如何進行對齊，合成再統一廣播給觀衆。 在此之上咱們須要準備的是兩套系統：多人視頻交互系統和標準CDN直播系統。

2. 基於P2P協議方案

此方案的實現方式是，主播A和主播B之間經過P2P協議進行音視頻鏈接，正常狀況下可以保證較低的延遲，保證主播A和主播B之間的互動。主播A在本身的流內容基礎上加入主播B的流內容，統一推向服務端。此時直播間內僅有一路流，而且其餘觀衆也只須要拉取這一路流內容。

此方案的優勢是顯而易見的，主播AB之間的延遲下降，交互體驗好，觀衆保持原有邏輯不變，拉取直播間固定流地址。 可是缺點是：主播A在連麥過程當中須要承擔兩路推流一路拉流的壓力，即拉取主播B的流內容，將本身的流內容推給主播B，將主播A和主播B的流內容推給服務端；主播A的網速壓力和性能壓力將會巨大，同時主播AB之間一對一的鏈接也致使擴展性較差，沒法知足2人以上的業務場景需求。

3. 基於多人視頻通話系統方案

此方案的實現方式是將主播A和主播B的視頻交互交由第三方處理，目前比較成熟的技術有視頻會議系統和Google開源的WebRTC系統。在此架構下，主播A與主播B的流合成處理上傳都是由這個交互系統完成。此方案對於方案2來講減輕了主播端的壓力，而且採用UDP協議傳輸方式下降延遲。同時也兼容多人鏈接交互。 此方案缺點是對服務端開發量大，要求高。

總結

目前主流實現方案可能是基於方案3實現。同時有人提出SD-RTN的實現方案，在我看來此方案是方案3的優化升級版本，採用此方案確實可以下降開發量，但同時也須要付出運營成本，收費與開源選擇哪個仍是要看具體的業務場景具體例子具體分析。

多人連麥技術還有許多須要改善的地方。隨着技術的發展，將來會出現更優的實現方式，咱們拭目以待。