連麥解決方案資料

1、連麥解決方案資料1.視頻直播連麥服務提供商：目前市場上做的比較好被多家直播平臺打包接入的有聲網（agora），即構科技，還有一些小一點公司如國士無雙。2.視頻直播連麥定義：簡單來說就是當主播直播期間，可以與其中某一個觀眾或者幾個粉絲進行互動，并且其他觀眾能夠觀看到這個互動過程。3.視頻直播連麥互動流程圖：a）主播正常開始直播，普通觀眾看到主播的單人直播畫面；b）需要連麥的觀眾發(fā)起連麥請求，進入連麥申請列表；c）主播從連麥申請列表中選擇一名或多名觀眾進行連麥操作，主播與連麥觀眾進行實時音視頻互動，同時互動直播系統(tǒng)生成“合成畫面”；d）普通觀眾看到直播畫面為包含主播與連麥觀眾的“合成畫面”；e）連

2、麥結束，恢復主播單人直播模式。4.常見的連麥技術方案：連麥方案之一 : 兩路RTMP1. 主播首先發(fā)布視頻到流媒體服務器,用戶從流媒體服務器拉取視頻信息;2. 其中某個用戶希望與主播連麥,他通過信令服務器向主播請求連麥,主播同意連麥請求;3. 連麥者發(fā)布視頻到流媒體服務器;4. 主播端和其他用戶獲取連麥者發(fā)布的視頻,在手機端采用畫中畫形式顯示。優(yōu)勢： 1. 完全基于現有RTMP技術，開發(fā)簡單，容易實現。劣勢：1. 主播和參與連麥的粉絲之間的交互延遲太大，基本無法正常交流。2. 聲音效果不好,主播和連麥粉絲之間會產生回波。3. 客戶端接收兩路視頻,流量消耗高，CPU消耗高。4. 主播和

3、連麥的時序沒有保證，普通粉絲的體驗感很差。結論： 基本不能使用，用戶體驗感極差，實際效果差。連麥方案之二 : P2P+RTMP 1. 主播首先發(fā)布視頻到流媒體服務器,用戶從流媒體服務器拉取視頻信息;2. 連麥者請求連麥,此時主播端會彈出連麥請求,主播選擇連麥用戶,連麥者和主播建立 P2P 連接;3. 主播端和連麥者之間建立了 P2P 通道,通過此通道進行音視頻數據的交互;4. 主播端本地進行混頻和混音，再發(fā)送給流媒體服務器;優(yōu)勢： 1. 主播和連麥者之間的交互延遲小，交互非常順暢;2. 可以采用回聲消除，聲音效果較好。3. 主播和連麥用了混音和混頻，可以同步，對于

4、普通用戶的體驗較好。劣勢：1. 主播端有兩路視頻上傳，一路下載，網絡要求高。加大了連麥端的延時。2. 主播端要進行混頻和混音，性能消耗高。3. 主播和連麥在復雜的網絡情況下，P2P有可能不能成功。4. 不能支持多路混頻，擴展性不好。結論：能達到一定的效果，但是有比較大的改進余地。連麥方案之三 : 視頻會議+RTMP 1. 主播端加入視頻會議系統(tǒng);2. 視頻會議系統(tǒng)把主播的視頻流推向 CDN,觀眾通過 CDN 觀看主播視頻;3. 參與連麥的觀眾登錄到與主播端同一個視頻會議頻道中,此時主播端和連麥者通過實時的 視頻會議進行交互;主播與連麥者的視頻,經過服務端混合后輸出給 CDN;4. 其

5、他用戶通過 CDN 觀看主播與連麥者的交互;優(yōu)勢：1. 通過視頻會議系統(tǒng)，主播和連麥者之間的交互延遲小，交互非常順暢;2. 采用回聲消除，聲音效果較好，采用混頻，同步效果好，對于普通用戶的體驗較好。3. 對于主播端的性能要求不高，對于網絡的適應性更好。4. 支持多人交互，可擴充性好。劣勢：1. 服務端相比于一般的直播系統(tǒng),還多增加了視頻會議系統(tǒng),開發(fā)復雜性高;2. 音視頻混合在服務端完成,對服務器性能要求高;結論：能達到最好的效果，對于服務要求比較高的廠商的推薦方案5.聲網連麥介紹：全球首個基于 UDP 的直播SDK，只有毫秒級的延遲，10000 人語音連麥，7 人視頻連麥

6、。官網：bbb:/aaaagora.io聲網連麥的基本架構圖：聲網連麥的主要特性：聲網連麥技術方案解析：聲網Agora.io，在開發(fā)互動直播解決方案時，拋棄傳統(tǒng)的基于TCP協(xié)議的CDN方案，從底層協(xié)議和布網上開始，創(chuàng)建了基于UDP協(xié)議的SD-RTN方案。（一）什么是SD-RTNSD-RTN（Software-Defined Real Time Net work），軟件定義實時傳輸網絡，是一種新型的專為內容實時傳輸而設計的網絡架構。通過在互聯網上不同地區(qū)的數據中心放置軟件組網單元，相互連接互相調度，在現有的公共互聯網基礎上構建一層新的虛擬網絡。SD-RTN系統(tǒng)能夠實時根據各節(jié)點的連接和傳輸狀況、

7、負載狀況以及到用戶的距離和響應時間，自動分配最優(yōu)、最通暢的傳輸路徑，達到實時傳輸需要的質量保障級別。（二）SD-RTN與CDN有何不同基本原理不同。CDN是存儲轉發(fā)結構，設計目的是在各個邊緣節(jié)點緩存待分發(fā)內容，結構上從源站到觀眾是傘狀多級緩存放大方式。SD-RTN本質上一個實時傳輸網絡，用戶的數據在網絡單元內部和傳輸線路上都以實時交換方式傳送，從而能夠保證最低延遲。底層協(xié)議不同。SD-RTN采用了專為實時傳輸設計的UDP協(xié)議，避免了采用TCP的延時不可控缺點。能夠大大縮短交互延時，延時可從CDN方案的數秒，降低到數百毫秒。內容分發(fā)機制不同。SD-RTN是基于自定義路由，選擇最優(yōu)傳輸路徑，直接將

8、內容端到端傳輸，數據在網絡單元中從不緩存，從而最大可能的降低延遲，同時內容安全性也更好。CDN是將內容緩存于緩存服務器中，再將內容就近下發(fā)。使用場景不同。SD-RTN適用于要求極低時延的實時互動場景，例如網絡電話、視頻會議、有主播與觀眾交互需求的互動直播等。CDN適用于對時延要求不高的場景，例如對延時要求不高、類似電視的單點直播、網站加速等。若硬要將CDN改造用于互動直播，那么其結構上對降低延遲的不適應性，始終會成為質量改進需求的瓶頸。（三）SD-RTN相較CDN，有何優(yōu)點1、時延大大縮短。直播延時可從CDN方案的數秒，降低到數百毫秒。這一延遲范圍，屬于實時通信或準實時通信延遲的范疇。在這一級

9、別上，主播和觀眾可以基本重現在現場活動中的交互體驗，從而大大釋放了內容整理者的潛力，也為業(yè)務運營者創(chuàng)造新業(yè)務形式打開了無限的空間和可能。比如，在這一延遲下，主播和觀眾可以不光通過文字交互，也可以通過音頻實時交互，而不會感到延遲過大而不自然。這種交互體驗，在手機上也更自然，比打字更符合人的自然習慣。業(yè)務運營方當然可以把這一功能當作比文字互動更高級別的特權能力，僅僅對于付費或是一定級別、身份的用戶才可以直接和主播語音互動。業(yè)務運營者也可以利用此類功能創(chuàng)造類似課堂，或小劇場的現場互動氛圍，讓主播可以聽得到觀眾的發(fā)問，或是掌聲、嘆息，甚至噓聲，實現自然的臺上臺下交互和有沉浸感的互動直播體驗。加上輔助功

10、能，體驗上可以任意規(guī)定誰可以發(fā)聲，誰不可以，這中間的可能性是無限的。更重要的是，即便在一般的連麥直播場景，這樣的體驗也可以幫助這類低延遲觀眾（我們稱為“近場觀眾”）在上麥互動的時候實現平滑體驗，不用每次切換就黑屏一次，好像節(jié)目中斷一樣。對于近場觀眾，即便是在網絡較差的時候，基本上能夠保證延遲不超過1秒，極少數觀眾延遲不超過2秒。相對于CDN，即便在網絡質量無問題時，也有3秒以上延遲。實測網絡丟包僅僅10%，就可以讓延遲拉大到10秒。這樣的丟包率，在手機的無線信號下可是經常出現的。所有這些，都要歸公于聲網SD-RTN的實時傳輸保障能力。UDP實現的傳輸協(xié)議，不會因為前一個包的丟失或延遲導致下后續(xù)

11、包的延遲送達，而丟包可以用對延遲更友好的方式修復或補償出來。不采用這個機制是無法達到這樣的延遲保障效果的。2、抗丟包能力強。使用聲網的技術，30%丟包時，依然能夠進行正常直播。而基于TCP的CDN直播方案在丟包2%時就明顯卡頓，達到30%經常已斷開連接。（四）基于SD-RTN的直播架構與特性下圖是聲網Agora.io互動直播的架構圖 客戶端均通過UDP連接SD-RTN（Agora Global Network），通過SD-RTN的就近接入策略，讓使用者就近接入質量最好的數據節(jié)點，通過Agora Global Network的軟件定義優(yōu)化路由，經過傳輸延遲和質量優(yōu)化的最優(yōu)路徑，自動避免

12、網絡擁塞，并規(guī)避骨干網絡故障的影響。若有常規(guī)的長延遲旁路直播需求，則可以將主播與連麥者合成一路直播流，通過RTMP推到CDN，進行下發(fā)。連接這一路的觀眾，不能參與連麥互動（稱為“遠場觀眾”）。主要特點如下：1、可以支持更多的主播交互，目前支持7人視頻交互，100人語音交互。 2、當有觀眾連麥時，其他觀眾端收到的多路視頻，觀眾端可以動態(tài)選擇布局。 3、聲網Agora.io會將直播視頻推送到CDN，其他觀眾（網頁端等）可以直接觀看。4、當有觀眾連麥時，聲網Agora.io會將視頻合圖后推送到CDN，其他觀眾（網頁端等）可以觀看到連麥者與主播的互動。5、在經過RTMP推流前的觀眾

13、端，可以進行大小流切換，自主選擇視頻大小窗口的切換。聲網報價：音頻通信視頻通信32KHz360P以下720P以下720P以上0.99美金起/1000分鐘0.99美金起/1000分鐘3.99美金起/1000分鐘14.99美金起/1000分鐘6.即構科技連麥介紹：官網：bbbs:/aaazego.im/連麥特性：即構科技連麥流程圖：即構科技連麥混流：混流有兩種選擇方式第一：從頭開始混，即第一主播選擇連麥方式開播，就開始混流，不論是否有第二主播來進行連麥。第二：只有當第二主播請求要連麥的時候，才開始混流。1.從頭開始混的混流實現圖1.1 若觀眾播放多流，請參考這個實現圖。1.2 若觀眾直接播放混流，

14、請參考這個實現圖。剛開始播放混流的StreamID，在publish成功后，要stopPlay混流的StreamID，再次play第一主播的非混流streamID A2.開始連麥時才混流的混流實現圖7.AnyRTC連麥方案：了解到AnyRTC連麥方案是基于谷歌開源項目WebRTC改進和設計來的，目前支持最大4人同時連麥，據了解該項目已經代碼開源，官網網站和開源位置如下：官網：bbbs:/aaaanyrtc.io/開源位置：bbbs:/githubaaa/AnyRTC/AnyRTC-RTMPAnyRTC云通訊RTMPC Hybird Engine SDK（簡稱RTMPC）是一套基于RTMP協(xié)議可

15、以進行視頻連線的混合引擎，由兩部分構成：主播端+訪客端。首先該SDK遵循標準RTMP視頻推流拉流協(xié)議，完全兼容市場上主流的標準RTMP視頻直播服務器及云平臺。與此同時，AnyRTC云通訊創(chuàng)新性實現了RTMP+RTC的技術融合，使用RTC技術實現基于標準的RTMP協(xié)議的互動連線視頻直播，當然SDK內部囊括了AnyRTC音視頻團隊多年的技術積累，在視頻處理、硬件加速、美顏濾鏡、音頻降噪、碼率控制、實時通訊、移動端性能等方面都做了很多的優(yōu)化處理。如果是一位需要在產品中需要加入互動連線直播的合作伙伴，只需要幾行代碼即可完成對對接流程，無論您是新開發(fā)的或者已經有產品上線的需求，RTMPC都能為您定制出最

16、符合需求的方案，簡單的說RTMPC不會對您的產品系統(tǒng)架構進行大刀闊斧的修改，完全基于RTMP的方案實現互動連線，絕非市面上的什么基于私有協(xié)議、UDP等互動直播方案。如圖所示：主播端和訪客端通過RTMP協(xié)議繼續(xù)推流拉流，如果需要進行互動連線直接使用SDK中的RTC功能即可。AnyRTC主要特性：RTMPC主要的功能包括如下幾個主要部分：1）RTMP推流拉流RTMPC本身是RTMP+RTC的混合引擎，支持RTMP推流和拉流功能；2）RTC視頻連線視頻連線功能分為主播端和訪客端，連線的控制權限在主播端即接受、拒絕等權限由主播進行控制，訪客可以申請與主播進行連線；3）消息彈幕功能支持主播/訪客發(fā)送文本和彈幕消息，支持自定義消息內容；4）人員狀態(tài)動態(tài)更新支持當前直播的人員上下線實時動態(tài)更新，支持用戶自定義人員信息；5）LOGO水印在主播端的直播視頻上添加自定義水印LOGO。RTMPC最多支持4人互動，但是不會額外增加帶寬消耗及其他的開銷；RTMPC之所以稱之為混合引擎，因為S