摘要：互動是視頻直播中用戶體驗最好的體驗。目前上市場視頻直播互動依靠打賞和文字互動，而對于粉絲來說，連麥上鏡才是最好的用戶體驗。本次親加通訊云郝飛受邀參加ArchSummit微課堂，探討直播低延遲低流量的粉絲連麥技術。

互動是視頻直播中用戶體驗最好的體驗。目前上市場視頻直播互動依靠打賞和文字互動，而對于粉絲來說，連麥上鏡才是最好的用戶體驗。本次親加通訊云郝飛受邀參加ArchSummit微課堂，探討直播低延遲低流量的粉絲連麥技術。

到目前為止，直播行業繼續如預期的那樣如火如荼的發展著，在先后競爭完延遲，高清，美顏，秒開等功能后，最近各大直播平臺比拼的一個熱點就是連麥。什么是連麥? 簡單描述就是當主播直播期間，可以與其中某一個粉絲進行互動，并且其他粉絲能夠觀看到這個互動過程。

這個連麥的操作把主播和粉絲的交互從文字聊天一下升級為音視頻互動，這個功能瞬間就提升了粉絲們的參與感;同時，這個互動過程其他粉絲都可以看到，極大滿足了連麥粉絲的幸福感，連麥的流程圖如下：

1、在主播直播過程中，主播提示進入互動環節，此時用戶可以參與互動

2、用戶請求參與互動，主持人同意某一個用戶的請求;

3、用戶參與直播，用戶與主播的互動過程直播給其他所有粉絲;

那如何實現連麥這樣的功能呢? 今天就向大家介紹幾種實現方法;

第一種方式就是通過兩路RTMP 流實現

目前直播的協議普遍采用的是RTMP協議，RTMP 是Adobe 公司實現的一套為Flash播放器和服務端之間音視頻和數據傳輸的私有協議。 此協議基于TCP實現，采用多路服用，信令和媒體都通過一個通道進行傳輸。

目前國內的直播CDN 基本上都使用此協議，其延遲大概在3秒左右; 由于此協議的數據是單向流動的，因此如果連麥功能使用此協議實現的話，就需要兩路視頻流的發布訂閱;其原理圖如下：

1、主播首先發布視頻到流媒體服務器，用戶從流媒體服務器拉取視頻信息 ;

2、其中某個用戶希望與主播連麥，他通過信令服務器向主播請求連麥，主播同意連麥請求;

3、連麥者發布視頻到流媒體服務器;

4、主播端和其他用戶獲取連麥者發布的視頻，在手機端采用畫中畫形式顯示;

在這個方案中，主播和參與連麥的粉絲分別發布了一路視頻流，觀看的粉絲同時拉取兩路視頻流。這種連麥方式從技術實現上非常簡單，但其體驗上也存在很多問題：

首先，主播和參與連麥的粉絲之間的交互延遲太大。大家了解，一路rtmp 的延遲大概在3秒左右。如果主播與參與連麥的用戶需要進行對話，那么主播從提問到聽到對方的答復原則上差不多要6秒左右時間了，這個對于實時交互來說完全沒有辦法接受。

其次，聲音效果不好，會產生回波。 一般的直播的音頻處理模塊都沒有進行回波抵消處理，因此主播端在觀看到連麥者視頻的同時，不能打開連麥者的音頻聽，否則會通過音頻采集設備重新采集，形成回波。

最后，客戶端接收兩路視頻，流量消耗高。一般的用戶端需要接收兩路視頻才能分別看到主播和連麥者，兩路視頻導致流量消耗比較高，同時兩路解碼也比較消耗CPU 資源。

從上面的分析大家可以看出，上述方案并不是一套可接受的連麥方案; 連麥的場景對于延遲要求很高，RTMP協議明顯無法滿足要求。比較好的方案需要確保連麥者(2個或者多個) 之間的交互滿足視頻會議的標準，也就是延遲在600ms 以內，整體的交互過程再進行視頻混合，以RTMP 的方式進行輸出。也就是說，這個方案中其實涉及了兩套系統，一套是保證低延遲的多人音視頻交互系統，另外一套是標準的CDN 直播系統; 直播系統大家已經很了解了，下面重點介紹下低延遲的交互系統的特點：

1、直播系統是一個單向的數據通道，而低延遲的視頻會議系統是一套雙向的通道。這使得這類系統在支持大并發方面沒有直播系統那么容易擴展，其網絡拓撲結構更加復雜;

2、低延遲系統傳輸層一般都使用UDP，應用層使用RTP/RTCP協議，從而保證包的即時性;為了保證安全性，更多的系統在使用SRTP協議，它是在RTP基礎上多了一層安全和認證措施;客戶端的連接建立常使用ICE協議，它結合私有網絡中主機所處的環境，通信雙方首先從STUN，TURN收集盡可能多的連接地址，然后對地址進行優先級排序，選擇最優的方式進行連接;這種方式對于不使用NAT穿透的場景也有好處; 它可以保證不同網絡客戶的聯通率，例如有些境外的客戶直連境內服務器效果不夠好，可以考慮通過TURN服務進行中轉，從而保證服務質量;

3、使用UDP就會涉及網絡延遲，丟包，因此要考慮QoS，主要策略包括：

a、使用抖動緩存(jitter buffer)來消除網絡包的抖動特性，以一個穩定的速率將數據包交給后續模塊處理;音頻和視頻需要有各自的抖動緩存，然后再實現同步;

b、在音頻方面，需要實現丟包隱藏算法; GIPS公司的NETEQ 算法應該是業界公認最好的VOIP防抖動算法，目前已經在WebRTC項目中開源;

c、視頻方面，需要實現一個自適應反饋模型，能夠根據網絡擁塞情況調整丟包保護策略; 當RTT較大時，可以使用FEC進行數據保護;當RTT較小的時候，選擇采用NACK機制;

接下來將基于以上討論的這種模型，介紹兩種連麥實現方式;這兩種方式都可以保證連麥效果，他們的主要區別是一種使用P2P技術進行連麥，另外一種使用多人視頻會議系統支持連麥，具體如下。

第二種方式是P2P + 直播的連麥方式，其原理圖如下

1、主播首先發布視頻到流媒體服務器，用戶從流媒體服務器拉取視頻信息;

2、連麥者請求連麥，此時主播端會彈出連麥請求，主播選擇連麥用戶，連麥者和主播建立P2P 連接;

3、主播端和連麥者之間建立了P2P 通道，通過此通道進行音視頻數據的交互;

4、主播端從攝像頭中采集主播視頻，從P2P 通道獲得連麥者的視頻，然后把兩張圖片進行混合，再發布給主播模塊，直播出去;

這種實現方式的優勢在于：

1、主播和連麥者之間的交互延遲小，由于這兩者之間是P2P 連接，因此網絡延遲非常小，一般都在幾百毫秒的量級。主播與連麥者之間的交互非常順暢;

2、聲音效果好; 主播端使用回波抵消模塊，連麥者的回聲會被消除;同時，主播與連麥者的語音交流也會整體直播出去;

這種方式存在的問題在于：

1、主播端相當于有兩路視頻上傳(直播視頻+連麥者的視頻交互)，一路視頻下載(連麥者的視頻)，對網絡要求會比較高。 我們團隊在正常的電信，聯通等wifi 及4G 網絡下進行測試，主播端帶寬完全能夠滿足要求;

2、不支持多路連麥者同時交流;

第三種方式通過視頻會議+直播的方式實現

為了能夠實現多個粉絲同時連麥，可以考慮主播與連麥者之間使用視頻會議系統，用一個MCU(Multi Control Unit)來實現媒體數據轉發。然后通過MCU對多路數據進行混合，再把混合流發送給CDN，其原理圖如下：

1、主播端加入視頻會議系統;此處注意，主播端不再直接推視頻給CDN;

2、視頻會議系統把主播的視頻流推向CDN，觀眾通過CDN 觀看主播視頻;

3、參與連麥的觀眾登錄到與主播端同一個視頻會議頻道中，此時主播端和連麥者通過實時的4,視頻會議進行交互;主播與連麥者的視頻，經過服務端混合后輸出給CDN;

其他用戶通過CDN 觀看主播與連麥者的交互;

這種方式的優勢在于：

1、主播和連麥者交互延遲很小; 由于使用視頻會議系統，通過服務端做了一次轉發，基本延遲都在一秒以下;

2、主播端只承擔視頻會議交互的流量，而不需要再承擔直播的上傳流量，對網路要求比P2P 方式要低;

3、支持多人交互;

缺點在于：

1、服務端相比于一般的直播系統，還多增加了視頻會議系統，開發復雜性高;

2、音視頻混合在服務端完成，對服務器性能要求高;

以上就是對連麥實現方式的簡單介紹，這三種方式在實際項目中都有被使用到，原則上后兩種方法的體驗會更好些;特別是第三種方案，他可以支持小范圍的多人實時交互，但這種方案的開發量大，同時熟悉視頻會議和直播的團隊比較缺少，對研發團隊要求高; 第二種方案可以在webrtc 和直播技術基礎上可以實現，對這方面比較熟悉的團隊可以嘗試整合一下。

以下是7月5日現場問答：

問題1:連麥技術是在客戶端實現還是服務器端實現? 兩種實現方式各有什么優缺點?

郝飛：剛才介紹的第二種方案就是在客戶端實現的，當然服務端也需要做一些工作;而第三種方案主要是在服務端的實現; 相關的優缺點上面也做過解答，大家可以參考下;

問題2:連麥技術有開源基礎版嗎?

郝飛：P2P 的方案可以考慮在webrtc 基礎上實現;而視頻會議+直播的方案目前還沒有看到開源項目，可以考慮在視頻會議系統上進行改造，使其輸出RTMP 直播;

問題3: 直播和用戶寬帶至少需要多少才能流暢連麥?

郝飛：如果是P2P 方案，對主播端帶寬要求會高一些; 如果是第三種會議模式，要求就不高了，基本上就是一路上傳，一路下載; 第二種P2P 方案，我們在4G，10M 的聯通，電信等網絡下實驗都是OK的;

問題4:你們P2P 是自己研發的還是基于其他的?

郝飛：我們是在webrtc 基礎上改造的，webrtc 的視頻圖像要和攝像頭的視頻圖像合成;并且在帶耳機的情況下，音頻也需要程序合成;

問題5:你們對防火墻或NAT有沒有運用STUN 或ICE 之類的技術?

郝飛：ICE 是一定要使用的; 對于P2P 網絡，有很多網路不能直連，肯定要使用TURN服務做中轉; 對于會議模式，也可以通過TURN做中轉，從而解決異地網絡連接不穩定的情況;

問題6: 各方案中如果用戶端斷線，此時用戶重新連麥要重新走連麥流程嗎?還是說可以掛著視頻系統自動重連?

郝飛：是可以重新連接的，不需要再走連麥流程;

問題7:第二種方案為什么不支持多路連麥者同時交流?

郝飛：P2P 其實也可以支持多人交互，但多個人同時交流，對于主播端來說CPU 壓力和網絡壓力都很大;

問題8:你們的視頻和音頻分別采用的是什么編碼?

郝飛：通用的編碼方案是：視頻采用H264，音頻采用AAC; 如果端到端都可控情況下，建議使用H265，壓縮率更高;

問題9: 第三種方案中，有什么推薦的視頻會議系統 ?

郝飛：大家有興趣的話可以看看 licode

問題10: 第三種方案的開發團隊要多少人，開發周期一般多長

郝飛：這個不在于人多，主要還是對視頻會議系統要比較了解;如果使用licode 改造的話，需要服務端實現RTMP推流的改造，如果對ffmpeg 等比較熟悉的話，一個月左右能夠出來一個基礎版本，但真正穩定下來還有很多工作需要完善;

講師介紹

郝飛，親加通訊云CTO，2011年加入親加團隊，帶領技術團隊創建了國內首個通訊云服務平臺，并以此為基礎，以技術驅動業務，不斷提高服務質量和功能，現已把此平臺升級為包括實時語音，視頻的移動端完整溝通解決方案;并在研發部實行有效的人才引入管理制度，兩年內組建了一支40多人規模的具備快速迭代，交付高質量技術產品能力的團隊，從而支持公司業務的快速發展。在音視頻編解碼、VOIP、流媒體等方面有豐富的研發和管理經驗。

親加通訊云介紹

上海愛聊信息科技有限公司(簡稱：親加通訊云)成立于2011年，是國內專業的移動通訊云服務商，嵌入式互動視頻直播領導者。

親加以獨有的SaaS/PaaS一體化服務模式，專注為企業級客戶和移動應用開發者提供全面的通訊云基礎能力和云端服務：包括視頻直播、H5微直播、全民直播、即時通訊(IM)、實時語音等。

親加在游戲市場覆蓋率第一，并已在金融、教育、電商、醫療等領域積累了大量的成功案例，并根據各行業特點提供視頻直播多場景解決方案。

總結

以上是生活随笔為你收集整理的亲加通讯云郝飞：探讨直播低延迟低流量的粉丝连麦技术的全部內容，希望文章能夠幫你解決所遇到的問題。

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