1. 互動直播背景

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

? ? 2.1. 連麥的業(yè)務流程

? ? 2.2. 互動直播的功能

? ? 2.3. 技術指標

? ? 2.4. 應用領域

3. 主流的技術方案

? ? ?3.1. 互動直播技術領域

? ? ?3.2. 主流的技術方案

? ? ? ? ? ? ?3.2.1. 基于RTMP技術的連麥

? ? ? ? ? ? ?3.2.2. 基于WebRTC P2P方式的連麥

? ? ? ? ? ? ?3.2.3. 基于低延時網(wǎng)絡的連麥

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

? ? ?4.1. 整體解決方案

? ? ?4.2. 基于RTMP協(xié)議的連麥

? ? ?4.3. 基于UDP私有協(xié)議的解決方案

5. 技術發(fā)展趨勢

?

互動直播背景

2016年被稱為“直播元年”，目前早就進入了直播戰(zhàn)國時代，移動直播App多達數(shù)百家，龐大的移動用戶規(guī)模已經(jīng)形成。網(wǎng)絡直播作為新興的社交方式已引發(fā)新一輪媒介革命，迅速成為新媒體營銷的新陣地。

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

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

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

連麥的業(yè)務流程

連麥的業(yè)務流程描述如下：

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

2.需要連麥的觀眾發(fā)起連麥請求，進入連麥申請列表；

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

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

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

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

互動直播的功能

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

同時，系統(tǒng)支持更大規(guī)模觀眾數(shù)的直播服務，可以將主播和多個連麥用戶的畫面，經(jīng)過音視頻混流后，推送到CDN進行分發(fā)，稱之為“旁路直播”。我們將位于RTC低延時網(wǎng)絡里邊的用戶稱為“高級觀眾”，而將收看CDN混流畫面的觀眾稱之為“旁路觀眾”。通過旁路直播，可以支持數(shù)千萬的觀眾并發(fā)的場景。

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

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

• 端到端演示小于500ms

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

技術指標

?

參數(shù)類型百度互動直播指標描述

音頻采樣率	8K，16K，48K
進入房間速度	WIFI:960ms 4G:1504ms
視頻碼率范圍	30~1500kbps
視頻分辨率	CIF到720P
最多同時音視頻	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?7路
抗丟包率	35%
延遲范圍	150~400ms
同房間并發(fā)觀眾數(shù)目	10萬人以上

應用領域

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

?

主流的技術方案

互動直播技術領域

互動直播與單向直播雖然都是“直播”，都屬于音視頻技術領域，但在行業(yè)發(fā)展上卻有著很大的不同。互動是雙向的，在專業(yè)上屬于視頻通信技術領域，而目前傳統(tǒng)的直播屬于流媒體傳輸技術領域。是不是從現(xiàn)有的成熟的CDN技術，可以很快做出一套完整的互動直播方案呢？答案是否定的。

我們可以通過下面看一下兩個領域的區(qū)別：

項目單向直播LIVE互動直播RTC

方向	單向，一對多，廣播型	雙向，一對一或一對多互動
延時	3-5s或更多	＜ 300ms
編碼	標準CODEC，如H.264	標準CODEC或私有標準
協(xié)議	H.323、SIP、WebRTC，私有UDP	RTMP、HTTP、HLS、DASH
分發(fā)	成熟的CDN技術和服務商	RTC-CDN仍在構建中

主流的技術方案

在技術方案上，基本上有下面幾種可以實現(xiàn)的方案：基于RTMP和CDN技術的連麥、基于WebRTC（P2P）與旁路直播的連麥、基于低延時網(wǎng)絡的連麥。

?基于RTMP技術的連麥

?

?

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

這個方案的優(yōu)點是實現(xiàn)簡單，協(xié)議與CDN架構兼容，對客戶來說在現(xiàn)有單向直播架構上，接入成本比較低，但是缺點也是很明顯的：

• 主播與連麥者如果要進行交互，考慮到上面分析的延時問題，因為RTMP協(xié)議是基于TCP協(xié)議傳輸?shù)?#xff0c;在CDN中傳輸延時較大。

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

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

?基于WebRTC P2P方式的連麥

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

?

該套方案的優(yōu)缺點如下所述：

• P2P在某些網(wǎng)絡下無法穿透，有些觀眾根本無法與主播端進行交互。

• 主播端需要上傳兩路視頻：一路P2P與連麥者進行交互，一路使用RTMP推到CDN。還要下載一路視頻：連麥者P2P發(fā)送過來的交互數(shù)據(jù)。所以主播端要求帶寬需要較高，網(wǎng)絡較差時無法進行主播。

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

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

• 由于主播端和連麥者經(jīng)過CDN合并成一路，因此，不能實現(xiàn)主播端和連麥者視頻大小窗口切換。

?基于低延時網(wǎng)絡的連麥

基于私有UDP協(xié)議的傳輸與RTMP相比具有先天的優(yōu)勢，但如果采用該方案也需要解決一系列的技術問題如：

• UDP的可靠性傳輸如丟包重傳、網(wǎng)絡抖動的處理

• 網(wǎng)路擁塞的控制算法

• 在全球節(jié)點的部署與智能調度

• 各種端的全面支持

以上都是在短期內很難實現(xiàn)的。

而百度云在多年CDN技術的基礎上，通過對私有UDP協(xié)議，實現(xiàn)了用戶視頻通信的實時傳輸網(wǎng)絡RTN。

百度云互動直播解決方案

整體解決方案

基于客戶和市場的需求，百度云推出兩套不同的互動直播解決方案：

• 基于RTMP協(xié)議與CDN的連麥技術方案

• 基于UDP私有協(xié)議和實時分發(fā)網(wǎng)絡RTN的連麥解決方案

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

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

在并發(fā)規(guī)模不是巨大，或者對延時有著超低需求的場合，如視頻會議、視頻社交等場合，我們推薦使用基于RTN網(wǎng)絡的全低延時解決方案。

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

基于RTMP協(xié)議的連麥

?

RTMP協(xié)議是基于TCP傳輸?shù)膮f(xié)議，為了達到低延時的傳輸，我們采用多方面的技術手段進行優(yōu)化。

網(wǎng)絡延時是指從主播端采集，到觀眾端播放之間的時間差。引入延時的環(huán)節(jié)包括:編碼延時、傳輸延時、解碼延時等。傳統(tǒng)CDN的分發(fā)都是為了一般采用RTMP協(xié)議，如果一旦出現(xiàn)網(wǎng)絡的抖動、丟包，因為可靠性傳輸?shù)脑?#xff0c;就會引入較大的傳輸延時。

基于百度云覆蓋全國的IDC核心網(wǎng)絡，部署基于RTMP協(xié)議加速分發(fā)節(jié)點，專門用作連麥用戶和主播的媒體傳輸通道，而不連麥的觀眾，仍然走傳統(tǒng)的分發(fā)路徑，來應對RTMP高并發(fā)用戶的觀看。

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

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

基于UDP私有協(xié)議的解決方案

?

與RTMP協(xié)議的連麥方案不同，主播和高級觀眾的連麥是在基于UDP協(xié)議的實時傳輸RTN上實現(xiàn)的。

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

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

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

在網(wǎng)絡傳輸性能指標方面，可以達到30%的抗丟包的傳輸。

客戶端通過RTN的就近接入策略，讓使用者就近接入質量最好的數(shù)據(jù)節(jié)點，通過百度云的智能調度策略優(yōu)化路由，經(jīng)過傳輸延遲和質量優(yōu)化的最優(yōu)路徑，自動避免網(wǎng)絡擁塞，并規(guī)避骨干網(wǎng)絡故障的影響。

主要的技術特點如下：

• 可以支持更多的主播交互，目前支持7人視頻交互，萬人并發(fā)語音交互

• 當有觀眾連麥時，其他觀眾端收到的多路視頻，觀眾端可以動態(tài)選擇布局

• 服務端混流服務器推送到CDN，其他觀眾（網(wǎng)頁端等）可以直接觀看

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

  ?

通過RTN實時網(wǎng)絡與基于百度CDN技術相結合，百度云推出了互動的直播的完全解決方案，其技術架構如上圖所示。

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

技術發(fā)展趨勢

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

總結

以上是生活随笔為你收集整理的互动直播的技术细节和解决方案实践经验谈的全部內容，希望文章能夠幫你解決所遇到的問題。

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