互動直播的技術細節和解決方案實踐經驗談


目錄

 

1. 互動直播背景

2. 連麥流程、功能與技術指標

    2.1. 連麥的業務流程

    2.2. 互動直播的功能

    2.3. 技術指標

    2.4. 應用領域

3. 主流的技術方案

     3.1. 互動直播技術領域

     3.2. 主流的技術方案

             3.2.1. 基於RTMP技術的連麥

             3.2.2. 基於WebRTC P2P方式的連麥

             3.2.3. 基於低延時網絡的連麥

4. 百度雲互動直播解決方案

     4.1. 整體解決方案

     4.2. 基於RTMP協議的連麥

     4.3. 基於UDP私有協議的解決方案

5. 技術發展趨勢

 

互動直播背景

2016年被稱為“直播元年”,目前早就進入了直播戰國時代,移動直播App多達數百家,龐大的移動用戶規模已經形成。網絡直播作為新興的社交方式已引發新一輪媒介革命,迅速成為新媒體營銷的新陣地。

如何在直播競爭中取得領先優勢,成為各個平台尋求差異化的動力,“互動直播”成為了直播發展的趨勢。通過視頻連麥,用戶之間可以進行視頻互動,達到更深層次的超越語言文字的交流。

互動直播與單向直播不同,賦予了普通觀眾“露臉發聲”的權利,低延時的網絡,主播可以實現與連麥觀眾的雙向互動,在直播房間里的其他觀眾也可以觀看主播和連麥觀眾互動的過程。在互動的時候還可以加上道具、美顏等濾鏡,與陌生人進行視頻互動聊天,是社交的下一個場景。如果一個觀眾喜歡該直播,他可以通過發送公開問題、贈送一個或多個虛擬禮物來引起主播的注意,尋求與主播進行視頻連麥的機會。

連麥流程、功能與技術指標

連麥的業務流程

連麥的業務流程描述如下:

1.主播正常開始直播,普通觀眾看到主播的單人直播畫面;

2.需要連麥的觀眾發起連麥請求,進入連麥申請列表;

3.主播從連麥申請列表中選擇一名或多名觀眾進行連麥操作,主播與連麥觀眾進行實時音視頻互動,同時互動直播后台生成“合成畫面”(混流畫面);

4.普通觀眾看到直播畫面為包含主播與連麥觀眾的“合成畫面”;

5.連麥結束,恢復主播單人直播模式。

在業務模式上,主要有兩種連麥需求,一種是主播主動邀請觀眾上麥,另外一種是觀眾申請連麥,業務流程如下圖所示:

互動直播的功能

低延時音視頻通信是互動直播的核心技術能力,另外包括終端上面的視頻處理能力,如降噪、美白,聲音處理能力;音頻降噪、回聲消除等等的能力。

同時,系統支持更大規模觀眾數的直播服務,可以將主播和多個連麥用戶的畫面,經過音視頻混流后,推送到CDN進行分發,稱之為“旁路直播”。我們將位於RTC低延時網絡里邊的用戶稱為“高級觀眾”,而將收看CDN混流畫面的觀眾稱之為“旁路觀眾”。通過旁路直播,可以支持數千萬的觀眾並發的場景。

總結起來,互動直播包含以下三個重要特征:

  • 互動房間里的每個人都有上麥和下麥的權利

  • 端到端演示小於500ms

  • 互動房間的容量可以達到萬人以上

技術指標

 

參數類型 百度互動直播指標描述
音頻采樣率 8K,16K,48K
進入房間速度 WIFI:960ms 4G:1504ms
視頻碼率范圍 30~1500kbps
視頻分辨率 CIF到720P
最多同時音視頻                                                                                                                                                                                                                7路
抗丟包率 35%
延遲范圍 150~400ms
同房間並發觀眾數目 10萬人以上

應用領域

直播秀場、視頻社交、互動課堂、遠程醫療、 企業年會、股評分析、 電商宣傳等領域。

 

主流的技術方案

互動直播技術領域

互動直播與單向直播雖然都是“直播”,都屬於音視頻技術領域,但在行業發展上卻有着很大的不同。互動是雙向的,在專業上屬於視頻通信技術領域,而目前傳統的直播屬於流媒體傳輸技術領域。是不是從現有的成熟的CDN技術,可以很快做出一套完整的互動直播方案呢?答案是否定的。

我們可以通過下面看一下兩個領域的區別:

項目 單向直播LIVE 互動直播RTC
方向 單向,一對多,廣播型 雙向,一對一或一對多互動
延時 3-5s或更多 < 300ms
編碼 標准CODEC,如H.264 標准CODEC或私有標准
協議 H.323、SIP、WebRTC,私有UDP RTMP、HTTP、HLS、DASH
分發 成熟的CDN技術和服務商 RTC-CDN仍在構建中

主流的技術方案

在技術方案上,基本上有下面幾種可以實現的方案:基於RTMP和CDN技術的連麥、基於WebRTC(P2P)與旁路直播的連麥、基於低延時網絡的連麥。

 基於RTMP技術的連麥

 

 

當有連麥者時,則主播端和連麥端,都分別推一路RTMP流到CDN,CDN再將這兩路RTMP流發送給觀眾端,觀眾端將兩路RTMP流合成為一個畫面。

這個方案的優點是實現簡單,協議與CDN架構兼容,對客戶來說在現有單向直播架構上,接入成本比較低,但是缺點也是很明顯的:

  • 主播與連麥者如果要進行交互,考慮到上面分析的延時問題,因為RTMP協議是基於TCP協議傳輸的,在CDN中傳輸延時較大。

  • 主播與連麥者交互時,聲音會產生干擾,形成回音

  • 觀眾端要接收兩條視頻流,帶寬、流量消耗過大,並且兩路視頻流解碼播放,耗費CPU等資源也非常多。

 基於WebRTC P2P方式的連麥

WebRTC是Google公司的開源技術,降低了音視頻通信的接入門檻,也有公司采用該項技術實現連麥。主播與連麥用戶采用P2P方式進行交互,然后在主播端進行混流,然后在CDN上進行混流,發送到觀眾端。

 

該套方案的優缺點如下所述:

  • P2P在某些網絡下無法穿透,有些觀眾根本無法與主播端進行交互。

  • 主播端需要上傳兩路視頻:一路P2P與連麥者進行交互,一路使用RTMP推到CDN。還要下載一路視頻:連麥者P2P發送過來的交互數據。所以主播端要求帶寬需要較高,網絡較差時無法進行主播。

  • 主播端要進行多路視頻的編碼、解碼,要求主播端設備配置比較高,較差的設備也無法進行主播。

  • 只能支持一個連麥者,不能支持多個連麥者。

  • 由於主播端和連麥者經過CDN合並成一路,因此,不能實現主播端和連麥者視頻大小窗口切換。

 基於低延時網絡的連麥

基於私有UDP協議的傳輸與RTMP相比具有先天的優勢,但如果采用該方案也需要解決一系列的技術問題如:

  • UDP的可靠性傳輸如丟包重傳、網絡抖動的處理

  • 網路擁塞的控制算法

  • 在全球節點的部署與智能調度

  • 各種端的全面支持

以上都是在短期內很難實現的。

而百度雲在多年CDN技術的基礎上,通過對私有UDP協議,實現了用戶視頻通信的實時傳輸網絡RTN。

百度雲互動直播解決方案

整體解決方案

基於客戶和市場的需求,百度雲推出兩套不同的互動直播解決方案:

  • 基於RTMP協議與CDN的連麥技術方案

  • 基於UDP私有協議和實時分發網絡RTN的連麥解決方案

兩套方案互為補充,以滿足不同客戶的需求。

如前所述,如果用戶在單向直播方面已經有了大量的用戶,且技術架構確定,可以采用RTMP協議的解決方案,減低接入成本。采用RTMP方案的傳輸。

在並發規模不是巨大,或者對延時有着超低需求的場合,如視頻會議、視頻社交等場合,我們推薦使用基於RTN網絡的全低延時解決方案。

下面就這兩套解決方案做一個介紹。

基於RTMP協議的連麥

 

RTMP協議是基於TCP傳輸的協議,為了達到低延時的傳輸,我們采用多方面的技術手段進行優化。

網絡延時是指從主播端采集,到觀眾端播放之間的時間差。引入延時的環節包括:編碼延時、傳輸延時、解碼延時等。傳統CDN的分發都是為了一般采用RTMP協議,如果一旦出現網絡的抖動、丟包,因為可靠性傳輸的原因,就會引入較大的傳輸延時。

基於百度雲覆蓋全國的IDC核心網絡,部署基於RTMP協議加速分發節點,專門用作連麥用戶和主播的媒體傳輸通道,而不連麥的觀眾,仍然走傳統的分發路徑,來應對RTMP高並發用戶的觀看。

在終端支持方面,將傳統直播的推流SDK和播放SDK進行合並,並且加入獨有的回聲消除(AEC)引擎,來解決連麥雙反可能出現的回聲問題。針對連麥場合,減少RTMP播放器的緩沖器,保證播放器引入較低的延時。

在混流方面,采用服務端混流的解決方案,與端上混流的方案相比,計算能力和分發能力較強,同時降低了主播端的帶寬壓力,提高流程性。

基於UDP私有協議的解決方案

 

與RTMP協議的連麥方案不同,主播和高級觀眾的連麥是在基於UDP協議的實時傳輸RTN上實現的。

首先說一下低延時RTN網絡與CDN網絡的不同。CDN是存儲轉發結構,設計目的是在各個邊緣節點緩存待分發內容,結構上從源站到觀眾是傘狀多級緩存放大方式。RTN網絡本質上是一個實時傳輸網絡,用戶的數據在網絡單元內部和傳輸線路上都以實時交換方式傳送,從而能夠保證最低延遲。底層協議不同。

RTN采用了專為實時傳輸設計的UDP協議,避免了采用TCP的延時不可控缺點。能夠大大縮短交互延時,延時可從CDN方案的數秒,降低到數百毫秒。基於自定義路由,選擇最優傳輸路徑,直接將內容端到端傳輸,數據在網絡單元中從不緩存,從而最大可能地降低延遲,同時內容安全性也更好。CDN是將內容緩存於緩存服務器中,再將內容就近下發。

在使用場景方面,SD-RTN適用於要求極低時延的實時互動場景,例如網絡電話、視頻會議、有主播與觀眾交互需求的互動直播等。CDN適用於對時延要求不高的場景,例如對延時要求不高、類似電視的單點直播、網站加速等。若硬要將CDN改造用於互動直播,那么其結構上對降低延遲的不適應性,始終會成為質量改進需求的瓶頸。

在網絡傳輸性能指標方面,可以達到30%的抗丟包的傳輸。

客戶端通過RTN的就近接入策略,讓使用者就近接入質量最好的數據節點,通過百度雲的智能調度策略優化路由,經過傳輸延遲和質量優化的最優路徑,自動避免網絡擁塞,並規避骨干網絡故障的影響。

主要的技術特點如下:

  • 可以支持更多的主播交互,目前支持7人視頻交互,萬人並發語音交互

  • 當有觀眾連麥時,其他觀眾端收到的多路視頻,觀眾端可以動態選擇布局

  • 服務端混流服務器推送到CDN,其他觀眾(網頁端等)可以直接觀看

  • 在經過RTMP推流前的觀眾端,可以進行大小流切換,自主選擇視頻大小窗口的切換

     

通過RTN實時網絡與基於百度CDN技術相結合,百度雲推出了互動的直播的完全解決方案,其技術架構如上圖所示。

通過百度雲的信令系統,用戶無論選擇哪種技術方案,都可以快速的接入一整套的互動直播解決方案。

技術發展趨勢

隨着移動互聯網技術的進步,直播技術正在朝着移動化、互動化和智能化的方向發展。實時通信能力,也將成為一種移動互聯應用的基礎能力,從而嵌入到幾乎所有的APP里邊。同時,在網絡視頻的監管方面,對智能化的鑒黃等也提出了新的需求。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM