【原標題】探討直播低延遲低流量的粉絲連麥技術
【來 源】ArchSummit技術關注【作? 者】郝飛
【編者按】本文轉(zhuǎn)自ArchSummit技術關注遵岩，本站編輯進行了調(diào)整。
到目前為止寞冯，直播行業(yè)繼續(xù)如預期的那樣如火如荼的發(fā)展著赁咙，在先后競爭完延遲苹祟，高清杂瘸，美顏玄渗，秒開等功能后，最近各大直播平臺比拼的一個熱點就是連麥扮叨。什么是連麥？簡單描述就是當主播直播期間领迈，可以與其中某一個粉絲進行互動彻磁，并且其他粉絲能夠觀看到這個互動過程。
這個連麥的操作把主播和粉絲的交互從文字聊天一下升級為音視頻互動狸捅，這個功能瞬間就提升了粉絲們的參與感衷蜓；同時，這個互動過程其他粉絲都可以看到尘喝，極大滿足了連麥粉絲的幸福感磁浇，連麥的流程圖如下：
1.在主播直播過程中，主播提示進入互動環(huán)節(jié)朽褪，此時用戶可以參與互動
2.用戶請求參與互動置吓，主持人同意某一個用戶的請求；
3.用戶參與直播缔赠，用戶與主播的互動過程直播給其他所有粉絲衍锚；
那如何實現(xiàn)連麥這樣的功能呢？今天就向大家介紹幾種實現(xiàn)方法嗤堰；
第一種方式就是通過兩路RTMP流實現(xiàn)
目前直播的協(xié)議普遍采用的是RTMP協(xié)議戴质，RTMP是Adobe公司實現(xiàn)的一套為Flash播放器和服務端之間音視頻和數(shù)據(jù)傳輸?shù)乃接袇f(xié)議。此協(xié)議基于TCP實現(xiàn)梁棠，采用多路服用置森，信令和媒體都通過一個通道進行傳輸。
目前國內(nèi)的直播CDN基本上都使用此協(xié)議符糊，其延遲大概在3秒左右凫海；由于此協(xié)議的數(shù)據(jù)是單向流動的，因此如果連麥功能使用此協(xié)議實現(xiàn)的話男娄，就需要兩路視頻流的發(fā)布訂閱行贪；其原理圖如下：
1.主播首先發(fā)布視頻到流媒體服務器漾稀，用戶從流媒體服務器拉取視頻信息；
2.其中某個用戶希望與主播連麥建瘫，他通過信令服務器向主播請求連麥崭捍，主播同意連麥請求；
3.連麥者發(fā)布視頻到流媒體服務器啰脚；
4.主播端和其他用戶獲取連麥者發(fā)布的視頻殷蛇，在手機端采用畫中畫形式顯示；
在這個方案中橄浓，主播和參與連麥的粉絲分別發(fā)布了一路視頻流粒梦，觀看的粉絲同時拉取兩路視頻流。這種連麥方式從技術實現(xiàn)上非常簡單荸实，但其體驗上也存在很多問題：
首先匀们，主播和參與連麥的粉絲之間的交互延遲太大。大家了解准给，一路rtmp的延遲大概在3秒左右泄朴。如果主播與參與連麥的用戶需要進行對話，那么主播從提問到聽到對方的答復原則上差不多要6秒左右時間了露氮，這個對于實時交互來說完全沒有辦法接受祖灰。
其次，聲音效果不好沦辙，會產(chǎn)生回波夫植。一般的直播的音頻處理模塊都沒有進行回波抵消處理，因此主播端在觀看到連麥者視頻的同時油讯，不能打開連麥者的音頻聽详民，否則會通過音頻采集設備重新采集，形成回波陌兑。
最后沈跨，客戶端接收兩路視頻，流量消耗高兔综。一般的用戶端需要接收兩路視頻才能分別看到主播和連麥者饿凛，兩路視頻導致流量消耗比較高，同時兩路解碼也比較消耗CPU資源软驰。
從上面的分析大家可以看出涧窒，上述方案并不是一套可接受的連麥方案；連麥的場景對于延遲要求很高锭亏，RTMP協(xié)議明顯無法滿足要求纠吴。比較好的方案需要確保連麥者（2個或者多個）之間的交互滿足視頻會議的標準，也就是延遲在600ms以內(nèi)慧瘤，整體的交互過程再進行視頻混合戴已，以RTMP的方式進行輸出固该。也就是說，這個方案中其實涉及了兩套系統(tǒng)糖儡，一套是保證低延遲的多人音視頻交互系統(tǒng)伐坏，另外一套是標準的CDN直播系統(tǒng)；直播系統(tǒng)大家已經(jīng)很了解了握联，下面重點介紹下低延遲的交互系統(tǒng)的特點：
1.直播系統(tǒng)是一個單向的數(shù)據(jù)通道桦沉，而低延遲的視頻會議系統(tǒng)是一套雙向的通道。這使得這類系統(tǒng)在支持大并發(fā)方面沒有直播系統(tǒng)那么容易擴展金闽，其網(wǎng)絡拓撲結構更加復雜永部；
2.低延遲系統(tǒng)傳輸層一般都使用UDP，應用層使用RTP／RTCP協(xié)議呐矾，從而保證包的即時性；為了保證安全性懦砂，更多的系統(tǒng)在使用SRTP協(xié)議蜒犯，它是在RTP基礎上多了一層安全和認證措施；客戶端的連接建立常使用ICE協(xié)議荞膘，它結合私有網(wǎng)絡中主機所處的環(huán)境罚随，通信雙方首先從STUN，TURN收集盡可能多的連接地址羽资，然后對地址進行優(yōu)先級排序淘菩，選擇最優(yōu)的方式進行連接；這種方式對于不使用NAT穿透的場景也有好處屠升；它可以保證不同網(wǎng)絡客戶的聯(lián)通率潮改，例如有些境外的客戶直連境內(nèi)服務器效果不夠好，可以考慮通過TURN服務進行中轉(zhuǎn)腹暖，從而保證服務質(zhì)量汇在；
3.使用UDP就會涉及網(wǎng)絡延遲，丟包脏答，因此要考慮QoS糕殉，主要策略包括：
a.使用抖動緩存(jitterbuffer)來消除網(wǎng)絡包的抖動特性，以一個穩(wěn)定的速率將數(shù)據(jù)包交給后續(xù)模塊處理殖告；音頻和視頻需要有各自的抖動緩存阿蝶，然后再實現(xiàn)同步；
b.在音頻方面黄绩，需要實現(xiàn)丟包隱藏算法羡洁；GIPS公司的NETEQ算法應該是業(yè)界公認最好的VOIP防抖動算法，目前已經(jīng)在WebRTC項目中開源宝与；
c.視頻方面焚廊，需要實現(xiàn)一個自適應反饋模型冶匹，能夠根據(jù)網(wǎng)絡擁塞情況調(diào)整丟包保護策略；當RTT較大時咆瘟，可以使用FEC進行數(shù)據(jù)保護嚼隘；當RTT較小的時候，選擇采用NACK機制袒餐；
接下來將基于以上討論的這種模型飞蛹，介紹兩種連麥實現(xiàn)方式；這兩種方式都可以保證連麥效果灸眼，他們的主要區(qū)別是一種使用P2P技術進行連麥卧檐，另外一種使用多人視頻會議系統(tǒng)支持連麥，具體如下焰宣。
第二種方式是P2P＋直播的連麥方式霉囚，其原理圖如下
1.主播首先發(fā)布視頻到流媒體服務器，用戶從流媒體服務器拉取視頻信息匕积；
2.連麥者請求連麥盈罐，此時主播端會彈出連麥請求，主播選擇連麥用戶闪唆，連麥者和主播建立P2P連接盅粪；
3.主播端和連麥者之間建立了P2P通道，通過此通道進行音視頻數(shù)據(jù)的交互悄蕾；
4.主播端從攝像頭中采集主播視頻票顾，從P2P通道獲得連麥者的視頻，然后把兩張圖片進行混合帆调，再發(fā)布給主播模塊奠骄，直播出去；
這種實現(xiàn)方式的優(yōu)勢在于：
1.主播和連麥者之間的交互延遲小番刊，由于這兩者之間是P2P連接戚揭，因此網(wǎng)絡延遲非常小，一般都在幾百毫秒的量級撵枢。主播與連麥者之間的交互非常順暢民晒；
2.聲音效果好；主播端使用回波抵消模塊锄禽，連麥者的回聲會被消除潜必；同時，主播與連麥者的語音交流也會整體直播出去沃但；
這種方式存在的問題在于：
1.主播端相當于有兩路視頻上傳（直播視頻＋連麥者的視頻交互）磁滚，一路視頻下載（連麥者的視頻），對網(wǎng)絡要求會比較高。我們團隊在正常的電信垂攘，聯(lián)通等wifi及4G網(wǎng)絡下進行測試维雇，主播端帶寬完全能夠滿足要求；
2.不支持多路連麥者同時交流晒他；
第三種方式通過視頻會議＋直播的方式實現(xiàn)
為了能夠?qū)崿F(xiàn)多個粉絲同時連麥吱型，可以考慮主播與連麥者之間使用視頻會議系統(tǒng)，用一個MCU（MultiControlUnit）來實現(xiàn)媒體數(shù)據(jù)轉(zhuǎn)發(fā)陨仅。然后通過MCU對多路數(shù)據(jù)進行混合津滞，再把混合流發(fā)送給CDN，其原理圖如下：
1.主播端加入視頻會議系統(tǒng)灼伤；此處注意触徐，主播端不再直接推視頻給CDN；
2.視頻會議系統(tǒng)把主播的視頻流推向CDN狐赡，觀眾通過CDN觀看主播視頻撞鹉；
3.參與連麥的觀眾登錄到與主播端同一個視頻會議頻道中，此時主播端和連麥者通過實時的視頻會議進行交互颖侄；主播與連麥者的視頻孔祸，經(jīng)過服務端混合后輸出給CDN；
4.其他用戶通過CDN觀看主播與連麥者的交互发皿；
這種方式的優(yōu)勢在于：
1.主播和連麥者交互延遲很小拂蝎；由于使用視頻會議系統(tǒng)穴墅，通過服務端做了一次轉(zhuǎn)發(fā)，基本延遲都在一秒以下温自；
2.主播端只承擔視頻會議交互的流量玄货，而不需要再承擔直播的上傳流量，對網(wǎng)路要求比P2P方式要低悼泌；
3.支持多人交互松捉；
缺點在于：
1.服務端相比于一般的直播系統(tǒng)，還多增加了視頻會議系統(tǒng)馆里，開發(fā)復雜性高隘世；
2.音視頻混合在服務端完成，對服務器性能要求高鸠踪；
以上就是對連麥實現(xiàn)方式的簡單介紹丙者，這三種方式在實際項目中都有被使用到，原則上后兩種方法的體驗會更好些营密；特別是第三種方案械媒，他可以支持小范圍的多人實時交互，但這種方案的開發(fā)量大，同時熟悉視頻會議和直播的團隊比較缺少纷捞，對研發(fā)團隊要求高痢虹；第二種方案可以在webrtc和直播技術基礎上可以實現(xiàn)，對這方面比較熟悉的團隊可以嘗試整合一下主儡。
Q&A
問題1:連麥技術是在客戶端實現(xiàn)還是服務器端實現(xiàn)?兩種實現(xiàn)方式各有什么優(yōu)缺點?
剛才介紹的第二種方案就是在客戶端實現(xiàn)的奖唯，當然服務端也需要做一些工作；而第三種方案主要是在服務端的實現(xiàn)缀辩；相關的優(yōu)缺點上面也做過解答臭埋，大家可以參考下；
問題2:連麥技術有開源基礎版嗎臀玄？
P2P的方案可以考慮在webrtc基礎上實現(xiàn)瓢阴；而視頻會議＋直播的方案目前還沒有看到開源項目，可以考慮在視頻會議系統(tǒng)上進行改造健无，使其輸出RTMP直播荣恐；
問題3:直播和用戶寬帶至少需要多少才能流暢連麥？
如果是P2P方案累贤，對主播端帶寬要求會高一些叠穆；如果是第三種會議模式，要求就不高了臼膏，基本上就是一路上傳硼被，一路下載；第二種P2P方案渗磅，我們在4G嚷硫，10M的聯(lián)通，電信等網(wǎng)絡下實驗都是OK的始鱼；
問題4:你們P2P是自己研發(fā)的還是基于其他的仔掸？
我們是在webrtc基礎上改造的，webrtc的視頻圖像要和攝像頭的視頻圖像合成医清；并且在帶耳機的情況下起暮，音頻也需要程序合成；
問題5:你們對防火墻或NAT有沒有運用STUN或ICE之類的技術会烙？
ICE是一定要使用的负懦；對于P2P網(wǎng)絡，有很多網(wǎng)路不能直連柏腻，肯定要使用TURN服務做中轉(zhuǎn)密似；對于會議模式，也可以通過TURN做中轉(zhuǎn)葫盼，從而解決異地網(wǎng)絡連接不穩(wěn)定的情況残腌；
問題6:各方案中如果用戶端斷線，此時用戶重新連麥要重新走連麥流程嗎？還是說可以掛著視頻系統(tǒng)自動重連抛猫？
是可以重新連接的蟆盹，不需要再走連麥流程；
問題7:第二種方案為什么不支持多路連麥者同時交流闺金？
P2P其實也可以支持多人交互逾滥，但多個人同時交流，對于主播端來說CPU壓力和網(wǎng)絡壓力都很大败匹；
問題8:你們的視頻和音頻分別采用的是什么編碼寨昙？
通用的編碼方案是：視頻采用H264，音頻采用AAC掀亩；如果端到端都可控情況下舔哪，建議使用H265，壓縮率更高槽棍；
問題9:第三種方案中捉蚤，有什么推薦的視頻會議系統(tǒng)？
大家有興趣的話可以看看licode
問題10:第三種方案的開發(fā)團隊要多少人，開發(fā)周期一般多長
這個不在于人多，主要還是對視頻會議系統(tǒng)要比較了解宗弯；如果使用licode改造的話，需要服務端實現(xiàn)RTMP推流的改造弓叛，如果對ffmpeg等比較熟悉的話，一個月左右能夠出來一個基礎版本，但真正穩(wěn)定下來還有很多工作需要完善；
