【原標(biāo)題】探討直播低延遲低流量的粉絲連麥技術(shù)
【來(lái) 源】ArchSummit技術(shù)關(guān)注【作? 者】郝飛
【編者按】本文轉(zhuǎn)自ArchSummit技術(shù)關(guān)注，本站編輯進(jìn)行了調(diào)整。
到目前為止，直播行業(yè)繼續(xù)如預(yù)期的那樣如火如荼的發(fā)展著，在先后競(jìng)爭(zhēng)完延遲，高清，美顏，秒開(kāi)等功能后，最近各大直播平臺(tái)比拼的一個(gè)熱點(diǎn)就是連麥。什么是連麥？簡(jiǎn)單描述就是當(dāng)主播直播期間，可以與其中某一個(gè)粉絲進(jìn)行互動(dòng)，并且其他粉絲能夠觀看到這個(gè)互動(dòng)過(guò)程。
這個(gè)連麥的操作把主播和粉絲的交互從文字聊天一下升級(jí)為音視頻互動(dòng)，這個(gè)功能瞬間就提升了粉絲們的參與感；同時(shí)，這個(gè)互動(dòng)過(guò)程其他粉絲都可以看到，極大滿足了連麥粉絲的幸福感，連麥的流程圖如下：
1.在主播直播過(guò)程中，主播提示進(jìn)入互動(dòng)環(huán)節(jié)，此時(shí)用戶可以參與互動(dòng)
2.用戶請(qǐng)求參與互動(dòng)，主持人同意某一個(gè)用戶的請(qǐng)求；
3.用戶參與直播，用戶與主播的互動(dòng)過(guò)程直播給其他所有粉絲；
那如何實(shí)現(xiàn)連麥這樣的功能呢？今天就向大家介紹幾種實(shí)現(xiàn)方法；
第一種方式就是通過(guò)兩路RTMP流實(shí)現(xiàn)
目前直播的協(xié)議普遍采用的是RTMP協(xié)議，RTMP是Adobe公司實(shí)現(xiàn)的一套為Flash播放器和服務(wù)端之間音視頻和數(shù)據(jù)傳輸?shù)乃接袇f(xié)議。此協(xié)議基于TCP實(shí)現(xiàn)，采用多路服用，信令和媒體都通過(guò)一個(gè)通道進(jìn)行傳輸。
目前國(guó)內(nèi)的直播CDN基本上都使用此協(xié)議，其延遲大概在3秒左右；由于此協(xié)議的數(shù)據(jù)是單向流動(dòng)的，因此如果連麥功能使用此協(xié)議實(shí)現(xiàn)的話，就需要兩路視頻流的發(fā)布訂閱；其原理圖如下：
1.主播首先發(fā)布視頻到流媒體服務(wù)器，用戶從流媒體服務(wù)器拉取視頻信息；
2.其中某個(gè)用戶希望與主播連麥，他通過(guò)信令服務(wù)器向主播請(qǐng)求連麥，主播同意連麥請(qǐng)求；
3.連麥者發(fā)布視頻到流媒體服務(wù)器；
4.主播端和其他用戶獲取連麥者發(fā)布的視頻，在手機(jī)端采用畫(huà)中畫(huà)形式顯示；
在這個(gè)方案中，主播和參與連麥的粉絲分別發(fā)布了一路視頻流，觀看的粉絲同時(shí)拉取兩路視頻流。這種連麥方式從技術(shù)實(shí)現(xiàn)上非常簡(jiǎn)單，但其體驗(yàn)上也存在很多問(wèn)題：
首先，主播和參與連麥的粉絲之間的交互延遲太大。大家了解，一路rtmp的延遲大概在3秒左右。如果主播與參與連麥的用戶需要進(jìn)行對(duì)話，那么主播從提問(wèn)到聽(tīng)到對(duì)方的答復(fù)原則上差不多要6秒左右時(shí)間了，這個(gè)對(duì)于實(shí)時(shí)交互來(lái)說(shuō)完全沒(méi)有辦法接受。
其次，聲音效果不好，會(huì)產(chǎn)生回波。一般的直播的音頻處理模塊都沒(méi)有進(jìn)行回波抵消處理，因此主播端在觀看到連麥者視頻的同時(shí)，不能打開(kāi)連麥者的音頻聽(tīng)，否則會(huì)通過(guò)音頻采集設(shè)備重新采集，形成回波。
最后，客戶端接收兩路視頻，流量消耗高。一般的用戶端需要接收兩路視頻才能分別看到主播和連麥者，兩路視頻導(dǎo)致流量消耗比較高，同時(shí)兩路解碼也比較消耗CPU資源。
從上面的分析大家可以看出，上述方案并不是一套可接受的連麥方案；連麥的場(chǎng)景對(duì)于延遲要求很高，RTMP協(xié)議明顯無(wú)法滿足要求。比較好的方案需要確保連麥者（2個(gè)或者多個(gè)）之間的交互滿足視頻會(huì)議的標(biāo)準(zhǔn)，也就是延遲在600ms以?xún)?nèi)，整體的交互過(guò)程再進(jìn)行視頻混合，以RTMP的方式進(jìn)行輸出。也就是說(shuō)，這個(gè)方案中其實(shí)涉及了兩套系統(tǒng)，一套是保證低延遲的多人音視頻交互系統(tǒng)，另外一套是標(biāo)準(zhǔn)的CDN直播系統(tǒng)；直播系統(tǒng)大家已經(jīng)很了解了，下面重點(diǎn)介紹下低延遲的交互系統(tǒng)的特點(diǎn)：
1.直播系統(tǒng)是一個(gè)單向的數(shù)據(jù)通道，而低延遲的視頻會(huì)議系統(tǒng)是一套雙向的通道。這使得這類(lèi)系統(tǒng)在支持大并發(fā)方面沒(méi)有直播系統(tǒng)那么容易擴(kuò)展，其網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)更加復(fù)雜；
2.低延遲系統(tǒng)傳輸層一般都使用UDP，應(yīng)用層使用RTP／RTCP協(xié)議，從而保證包的即時(shí)性；為了保證安全性，更多的系統(tǒng)在使用SRTP協(xié)議，它是在RTP基礎(chǔ)上多了一層安全和認(rèn)證措施；客戶端的連接建立常使用ICE協(xié)議，它結(jié)合私有網(wǎng)絡(luò)中主機(jī)所處的環(huán)境，通信雙方首先從STUN，TURN收集盡可能多的連接地址，然后對(duì)地址進(jìn)行優(yōu)先級(jí)排序，選擇最優(yōu)的方式進(jìn)行連接；這種方式對(duì)于不使用NAT穿透的場(chǎng)景也有好處；它可以保證不同網(wǎng)絡(luò)客戶的聯(lián)通率，例如有些境外的客戶直連境內(nèi)服務(wù)器效果不夠好，可以考慮通過(guò)TURN服務(wù)進(jìn)行中轉(zhuǎn)，從而保證服務(wù)質(zhì)量；
3.使用UDP就會(huì)涉及網(wǎng)絡(luò)延遲，丟包，因此要考慮QoS，主要策略包括：
a.使用抖動(dòng)緩存(jitterbuffer)來(lái)消除網(wǎng)絡(luò)包的抖動(dòng)特性，以一個(gè)穩(wěn)定的速率將數(shù)據(jù)包交給后續(xù)模塊處理；音頻和視頻需要有各自的抖動(dòng)緩存，然后再實(shí)現(xiàn)同步；
b.在音頻方面，需要實(shí)現(xiàn)丟包隱藏算法；GIPS公司的NETEQ算法應(yīng)該是業(yè)界公認(rèn)最好的VOIP防抖動(dòng)算法，目前已經(jīng)在WebRTC項(xiàng)目中開(kāi)源；
c.視頻方面，需要實(shí)現(xiàn)一個(gè)自適應(yīng)反饋模型，能夠根據(jù)網(wǎng)絡(luò)擁塞情況調(diào)整丟包保護(hù)策略；當(dāng)RTT較大時(shí)，可以使用FEC進(jìn)行數(shù)據(jù)保護(hù)；當(dāng)RTT較小的時(shí)候，選擇采用NACK機(jī)制；
接下來(lái)將基于以上討論的這種模型，介紹兩種連麥實(shí)現(xiàn)方式；這兩種方式都可以保證連麥效果，他們的主要區(qū)別是一種使用P2P技術(shù)進(jìn)行連麥，另外一種使用多人視頻會(huì)議系統(tǒng)支持連麥，具體如下。
第二種方式是P2P＋直播的連麥方式，其原理圖如下
1.主播首先發(fā)布視頻到流媒體服務(wù)器，用戶從流媒體服務(wù)器拉取視頻信息；
2.連麥者請(qǐng)求連麥，此時(shí)主播端會(huì)彈出連麥請(qǐng)求，主播選擇連麥用戶，連麥者和主播建立P2P連接；
3.主播端和連麥者之間建立了P2P通道，通過(guò)此通道進(jìn)行音視頻數(shù)據(jù)的交互；
4.主播端從攝像頭中采集主播視頻，從P2P通道獲得連麥者的視頻，然后把兩張圖片進(jìn)行混合，再發(fā)布給主播模塊，直播出去；
這種實(shí)現(xiàn)方式的優(yōu)勢(shì)在于：
1.主播和連麥者之間的交互延遲小，由于這兩者之間是P2P連接，因此網(wǎng)絡(luò)延遲非常小，一般都在幾百毫秒的量級(jí)。主播與連麥者之間的交互非常順暢；
2.聲音效果好；主播端使用回波抵消模塊，連麥者的回聲會(huì)被消除；同時(shí)，主播與連麥者的語(yǔ)音交流也會(huì)整體直播出去；
這種方式存在的問(wèn)題在于：
1.主播端相當(dāng)于有兩路視頻上傳（直播視頻＋連麥者的視頻交互），一路視頻下載（連麥者的視頻），對(duì)網(wǎng)絡(luò)要求會(huì)比較高。我們團(tuán)隊(duì)在正常的電信，聯(lián)通等wifi及4G網(wǎng)絡(luò)下進(jìn)行測(cè)試，主播端帶寬完全能夠滿足要求；
2.不支持多路連麥者同時(shí)交流；
第三種方式通過(guò)視頻會(huì)議＋直播的方式實(shí)現(xiàn)
為了能夠?qū)崿F(xiàn)多個(gè)粉絲同時(shí)連麥，可以考慮主播與連麥者之間使用視頻會(huì)議系統(tǒng)，用一個(gè)MCU（MultiControlUnit）來(lái)實(shí)現(xiàn)媒體數(shù)據(jù)轉(zhuǎn)發(fā)。然后通過(guò)MCU對(duì)多路數(shù)據(jù)進(jìn)行混合，再把混合流發(fā)送給CDN，其原理圖如下：
1.主播端加入視頻會(huì)議系統(tǒng)；此處注意，主播端不再直接推視頻給CDN；
2.視頻會(huì)議系統(tǒng)把主播的視頻流推向CDN，觀眾通過(guò)CDN觀看主播視頻；
3.參與連麥的觀眾登錄到與主播端同一個(gè)視頻會(huì)議頻道中，此時(shí)主播端和連麥者通過(guò)實(shí)時(shí)的視頻會(huì)議進(jìn)行交互；主播與連麥者的視頻，經(jīng)過(guò)服務(wù)端混合后輸出給CDN；
4.其他用戶通過(guò)CDN觀看主播與連麥者的交互；
這種方式的優(yōu)勢(shì)在于：
1.主播和連麥者交互延遲很?。挥捎谑褂靡曨l會(huì)議系統(tǒng)，通過(guò)服務(wù)端做了一次轉(zhuǎn)發(fā)，基本延遲都在一秒以下；
2.主播端只承擔(dān)視頻會(huì)議交互的流量，而不需要再承擔(dān)直播的上傳流量，對(duì)網(wǎng)路要求比P2P方式要低；
3.支持多人交互；
缺點(diǎn)在于：
1.服務(wù)端相比于一般的直播系統(tǒng)，還多增加了視頻會(huì)議系統(tǒng)，開(kāi)發(fā)復(fù)雜性高；
2.音視頻混合在服務(wù)端完成，對(duì)服務(wù)器性能要求高；
以上就是對(duì)連麥實(shí)現(xiàn)方式的簡(jiǎn)單介紹，這三種方式在實(shí)際項(xiàng)目中都有被使用到，原則上后兩種方法的體驗(yàn)會(huì)更好些；特別是第三種方案，他可以支持小范圍的多人實(shí)時(shí)交互，但這種方案的開(kāi)發(fā)量大，同時(shí)熟悉視頻會(huì)議和直播的團(tuán)隊(duì)比較缺少，對(duì)研發(fā)團(tuán)隊(duì)要求高；第二種方案可以在webrtc和直播技術(shù)基礎(chǔ)上可以實(shí)現(xiàn)，對(duì)這方面比較熟悉的團(tuán)隊(duì)可以嘗試整合一下。
Q&A
問(wèn)題1:連麥技術(shù)是在客戶端實(shí)現(xiàn)還是服務(wù)器端實(shí)現(xiàn)?兩種實(shí)現(xiàn)方式各有什么優(yōu)缺點(diǎn)?
剛才介紹的第二種方案就是在客戶端實(shí)現(xiàn)的，當(dāng)然服務(wù)端也需要做一些工作；而第三種方案主要是在服務(wù)端的實(shí)現(xiàn)；相關(guān)的優(yōu)缺點(diǎn)上面也做過(guò)解答，大家可以參考下；
問(wèn)題2:連麥技術(shù)有開(kāi)源基礎(chǔ)版嗎？
P2P的方案可以考慮在webrtc基礎(chǔ)上實(shí)現(xiàn)；而視頻會(huì)議＋直播的方案目前還沒(méi)有看到開(kāi)源項(xiàng)目，可以考慮在視頻會(huì)議系統(tǒng)上進(jìn)行改造，使其輸出RTMP直播；
問(wèn)題3:直播和用戶寬帶至少需要多少才能流暢連麥？
如果是P2P方案，對(duì)主播端帶寬要求會(huì)高一些；如果是第三種會(huì)議模式，要求就不高了，基本上就是一路上傳，一路下載；第二種P2P方案，我們?cè)?G，10M的聯(lián)通，電信等網(wǎng)絡(luò)下實(shí)驗(yàn)都是OK的；
問(wèn)題4:你們P2P是自己研發(fā)的還是基于其他的？
我們是在webrtc基礎(chǔ)上改造的，webrtc的視頻圖像要和攝像頭的視頻圖像合成；并且在帶耳機(jī)的情況下，音頻也需要程序合成；
問(wèn)題5:你們對(duì)防火墻或NAT有沒(méi)有運(yùn)用STUN或ICE之類(lèi)的技術(shù)？
ICE是一定要使用的；對(duì)于P2P網(wǎng)絡(luò)，有很多網(wǎng)路不能直連，肯定要使用TURN服務(wù)做中轉(zhuǎn)；對(duì)于會(huì)議模式，也可以通過(guò)TURN做中轉(zhuǎn)，從而解決異地網(wǎng)絡(luò)連接不穩(wěn)定的情況；
問(wèn)題6:各方案中如果用戶端斷線，此時(shí)用戶重新連麥要重新走連麥流程嗎？還是說(shuō)可以掛著視頻系統(tǒng)自動(dòng)重連？
是可以重新連接的，不需要再走連麥流程；
問(wèn)題7:第二種方案為什么不支持多路連麥者同時(shí)交流？
P2P其實(shí)也可以支持多人交互，但多個(gè)人同時(shí)交流，對(duì)于主播端來(lái)說(shuō)CPU壓力和網(wǎng)絡(luò)壓力都很大；
問(wèn)題8:你們的視頻和音頻分別采用的是什么編碼？
通用的編碼方案是：視頻采用H264，音頻采用AAC；如果端到端都可控情況下，建議使用H265，壓縮率更高；
問(wèn)題9:第三種方案中，有什么推薦的視頻會(huì)議系統(tǒng)？
大家有興趣的話可以看看licode
問(wèn)題10:第三種方案的開(kāi)發(fā)團(tuán)隊(duì)要多少人，開(kāi)發(fā)周期一般多長(zhǎng)
這個(gè)不在于人多，主要還是對(duì)視頻會(huì)議系統(tǒng)要比較了解；如果使用licode改造的話，需要服務(wù)端實(shí)現(xiàn)RTMP推流的改造，如果對(duì)ffmpeg等比較熟悉的話，一個(gè)月左右能夠出來(lái)一個(gè)基礎(chǔ)版本，但真正穩(wěn)定下來(lái)還有很多工作需要完善；
