1. 互動(dòng)直播背景

2. 連麥流程、功能與技術(shù)指標(biāo)

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

? ? 2.2. 互動(dòng)直播的功能

? ? 2.3. 技術(shù)指標(biāo)

? ? 2.4. 應(yīng)用領(lǐng)域

3. 主流的技術(shù)方案

? ? ?3.1. 互動(dòng)直播技術(shù)領(lǐng)域

? ? ?3.2. 主流的技術(shù)方案

? ? ? ? ? ? ?3.2.1. 基于RTMP技術(shù)的連麥

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

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

4. 百度云互動(dòng)直播解決方案

? ? ?4.1. 整體解決方案

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

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

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

?

互動(dòng)直播背景

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

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

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

連麥流程、功能與技術(shù)指標(biāo)

連麥的業(yè)務(wù)流程

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

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

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

3.主播從連麥申請(qǐng)列表中選擇一名或多名觀眾進(jìn)行連麥操作，主播與連麥觀眾進(jìn)行實(shí)時(shí)音視頻互動(dòng)，同時(shí)互動(dòng)直播后臺(tái)生成“合成畫面”（混流畫面）；

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

5.連麥結(jié)束，恢復(fù)主播單人直播模式。

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

互動(dòng)直播的功能

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

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

總結(jié)起來(lái)，互動(dòng)直播包含以下三個(gè)重要特征：

• 互動(dòng)房間里的每個(gè)人都有上麥和下麥的權(quán)利

• 端到端演示小于500ms

• 互動(dòng)房間的容量可以達(dá)到萬(wàn)人以上

技術(shù)指標(biāo)

?

參數(shù)類型百度互動(dòng)直播指標(biāo)描述

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

應(yīng)用領(lǐng)域

直播秀場(chǎng)、視頻社交、互動(dòng)課堂、遠(yuǎn)程醫(yī)療、 企業(yè)年會(huì)、股評(píng)分析、 電商宣傳等領(lǐng)域。

?

主流的技術(shù)方案

互動(dòng)直播技術(shù)領(lǐng)域

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

我們可以通過(guò)下面看一下兩個(gè)領(lǐng)域的區(qū)別：

項(xiàng)目單向直播LIVE互動(dòng)直播RTC

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

主流的技術(shù)方案

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

?基于RTMP技術(shù)的連麥

?

?

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

這個(gè)方案的優(yōu)點(diǎn)是實(shí)現(xiàn)簡(jiǎn)單，協(xié)議與CDN架構(gòu)兼容，對(duì)客戶來(lái)說(shuō)在現(xiàn)有單向直播架構(gòu)上，接入成本比較低，但是缺點(diǎn)也是很明顯的：

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

• 主播與連麥者交互時(shí)，聲音會(huì)產(chǎn)生干擾，形成回音

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

?基于WebRTC P2P方式的連麥

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

?

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

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

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

• 主播端要進(jìn)行多路視頻的編碼、解碼，要求主播端設(shè)備配置比較高，較差的設(shè)備也無(wú)法進(jìn)行主播。

• 只能支持一個(gè)連麥者，不能支持多個(gè)連麥者。

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

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

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

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

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

• 在全球節(jié)點(diǎn)的部署與智能調(diào)度

• 各種端的全面支持

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

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

百度云互動(dòng)直播解決方案

整體解決方案

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

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

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

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

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

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

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

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

?

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

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

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

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

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

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

?

與RTMP協(xié)議的連麥方案不同，主播和高級(jí)觀眾的連麥?zhǔn)窃诨赨DP協(xié)議的實(shí)時(shí)傳輸RTN上實(shí)現(xiàn)的。

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

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

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

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

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

主要的技術(shù)特點(diǎn)如下：

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

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

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

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

  ?

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

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

技術(shù)發(fā)展趨勢(shì)

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

總結(jié)

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

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