轉載地址：http://www.cnblogs.com/lingyunhu/p/rtc76.html
本文主要探討基於WebRTC的P2P直播粉絲連麥技術 （作者：郝飛，親加雲CTO，編輯：dora），最早發表在【這裏】
支持原創，轉載必須註明出處，歡迎關注微信公衆號blacker（微信ID：blackerteam 或 webrtcorgcn）
到目前爲止,直播行業繼續如預期的那樣如火如荼的發展着,在先後競爭完延遲,高清,美 顏,秒開等功能後,最近各大直播平臺比拼的一個熱點就是連麥。什麼是連麥? 簡單 就是當主播直播期間,可以與其中某一個粉絲進行互動,並且其他粉絲能夠觀看到這個互動 過程。
這個連麥的操作把主播和粉絲的交互從文字聊天一下升級爲音視頻互動,這個功能瞬間就提升了粉絲們的參與感;同時,這個互動過程其他粉絲都可以看到,極大滿足了連麥粉絲的幸 福感,連麥的流程圖如下:
1 在主播直播過程中,主播進入互動環節,此時用戶可以參與互動 2 用戶請求參與互動,主持人同意某一個用戶的請求;
3 用戶參與直播,用戶與主播的互動過程直播給其他所有粉絲;
那如何實現連麥這樣的功能呢? 今天就向大家介紹幾種實現方法;
第一種方式就是通過兩路 RTMP 流實現
目前直播的協議普遍採用的是RTMP協議,RTMP 是Adobe 公司實現的一套爲Flash播放器 和服務端之間音視頻和數據傳輸的私有協議。此協議基於 TCP 實現,採用多路服用,信令 和媒體都通過一個通道進行傳輸。
目前國內的直播 CDN 基本上都使用此協議,其延遲大概在 3 秒左右;由於此協議的數據是 單向流動的,因此如果連麥功能使用此協議實現的話,就需要兩路視頻流的發佈訂閱;其原 理圖如下:
1 主播首先發布視頻到流媒體服務器,用戶從流媒體服務器拉取視頻信息;
2 其中某個用戶希望與主播連麥,他通過信令服務器向主播請求連麥,主播同意連麥請求; 3 連麥者發佈視頻到流媒體服務器;
4 主播端和其他用戶獲取連麥者發佈的視頻,在手機端採用畫中畫形式顯示;
在這個方案中,主播和參與連麥的粉絲分別發佈了一路視頻流,觀看的粉絲同時拉取兩路視 頻流。這種連麥方式從技術實現上非常簡單,但其體驗上也存在很多問題:
首先,主播和參與連麥的粉絲之間的交互延遲太大。大家瞭解,一路 rtmp 的延遲大概在 3 秒左右。如果主播與參與連麥的用戶需要進行對話,那麼主播從問到聽到對方的答覆原則 上差不多要 6 秒左右時間了,這個對於實時交互來說完全沒有辦法接受;
其次,聲音效果不好,會產生回波;一般的直播的音頻處理模塊都沒有進行回波抵消處理, 因此主播端在觀看到連麥者視頻的同時,不能打開連麥者的音頻聽,否則會通過音頻採集設 備重新採集,形成回波;
最後,客戶端接收兩路視頻,流量消耗高; 一般的用戶端需要接收兩路視頻才能分別看到 主播和連麥者,兩路視頻導致流量消耗比較高,同時兩路解碼也比較消耗 CPU 資源。
從上面的分析大家可以看出,上述方案並不是一套可接受的連麥方案; 連麥的場景對於延 遲 要 求 很 高 ,R T M P 協 議 明 顯 無 法 滿 足 要 求 。比 較 好 的 方 案 需 要 確 保 連 麥 者( 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 參與連麥的觀衆登錄到與主播端同一個視頻會議頻道中,此時主播端和連麥者通過實時的 視頻會議進行交互;主播與連麥者的視頻,經過服務端混合後輸出給 CDN;
4 其他用戶通過 CDN 觀看主播與連麥者的交互;
這種方式的優勢在於:
1 主播和連麥者交互延遲很小;由於使用視頻會議系統,通過服務端做了一次轉發,基本 延遲都在一秒以下;
2 主播端只承擔視頻會議交互的流量,而不需要再承擔直播的上傳流量,對網路要求比 P2P 方式要低;
3 支持多人交互;
缺點在於:
1 服務端相比於一般的直播系統,還多增加了視頻會議系統,開發複雜性高; 2 音視頻混合在服務端完成,對服務器性能要求高;
以上就是對連麥實現方式的簡單介紹,這三種方式在實際項目中都有被使用到,原則上後兩 種方法的體驗會更好些;特別是第三種方案,他可以支持小範圍的多人實時交互,但這種方 案的開發量大,同時熟悉視頻會議和直播的團隊比較缺少,對研發團隊要求高; 第二種方 案可以在webrtc 和直播技術基礎上可以實現,對這方面比較熟悉的團隊可以嘗試整合一下。
Q&A
問題 1:連麥技術是在客戶端實現還是服務器端實現? 兩種實現方式各有什麼優缺點?
解答 1: 剛纔介紹的第二種方案就是在客戶端實現的,當然服務端也需要做一些工作; 而
第三種方案主要是在服務端的實現; 相關的優缺點上面也做過解答,大家可以參考下;
問題 2:連麥技術有開源基礎版嗎?
解答 2: P2P 的方案可以考慮在 webrtc 基礎上實現;而視頻會議+直播的方案目前還沒有
看到開源項目,可以考慮在視頻會議系統上進行改造,使其輸出 RTMP 直播;
問題 3: 直播和用戶寬帶至少需要多少才能流暢連麥
解答 3: 如果是 P2P 方案,對主播端帶寬要求會高一些; 如果是第三種會議模式,要求
就不高了,基本上就是一路上傳,一路下載; 第二種 P2P 方案,我們在 4G,10M 的聯通, 電信等網絡下實驗都是 OK 的;
問題 4:你們 P2P 是自己研發的還是基於其他的?
解答 4: 我們是在 webrtc 基礎上改造的,webrtc 的視頻圖像要和攝像頭的視頻圖像合成;
並且在帶耳機的情況下,音頻也需要程序合成;
問題 5:你們對防火牆或 NAT 有沒有運用 STUN 或 ICE 之類的技術?
解答 5: ICE 是一定要使用的; 對於 P2P 網絡,有很多網路不能直連,肯定要使用 TURN
服務做中轉; 對於會議模式,也可以通過 TURN 做中轉,從而解決異地網絡連接不穩定的
情況;
問題 6: 各方案中如果用戶端斷線,此時用戶重新連麥要重新走連麥流程嗎?還是說可以掛 着視頻系統自動重連?
解答 6: 是可以重新連接的,不需要再走連麥流程;
問題 7:第二種方案爲什麼不支持多路連麥者同時交流?
解答 7: P2P 其實也可以支持多人交互,但多個人同時交流,對於主播端來說 CPU 壓力和
網絡壓力都很大;
問題 8:你們的視頻和音頻分別採用的是什麼編碼?
解答 8: 通用的編碼方案是:視頻採用 H264,音頻採用 AAC; 如果端到端都可控情況下,
建議使用 H265,壓縮率更高;
問題 9: 第三種方案中,有什麼推薦的視頻會議系統 ?
解答 9: 大家有興趣的話可以看看 licode
問題 10: 第三種方案的開發團隊要多少人,開發週期一般多長
解答 10: 這個不在於人多,主要還是對視頻會議系統要比較瞭解; 如果使用 licode 改造
的話,需要服務端實現 RTMP 推流的改造,如果對 ffmpeg 等比較熟悉的話,一個月左右能 夠出來一個基礎版本,但真正穩定下來還有很多工作需要完善;