連麥互動直播方案全實踐2：網易雲信連麥互動直播方案的演變過程

毫無疑問直播是當前移動互聯網最熱門的領域之一，在超強熱度的引導下直播領域也吸引了大量的商業資本。在各大直播應用萬花齊放的時刻，也正是直播應用面臨的真正風口。站在這個風口上，直播應用只把握好風向標，推出具有高用戶粘性的差別化功能，才能在這個不斷推陳出新的時代站穩腳跟，得到不可動搖的地位。

《連麥互動直播方案全實踐》系列文章基於網易雲信的摸索和實踐，從場景、流程到方案、架構，對直播體驗深度優化方案——「連麥互動直播」進行了全面的講解和介紹。

 

相關閱讀推薦：

連麥互動直播方案全實踐1：什麼是連麥互動直播？

連麥互動直播方案全實踐3：網易雲信連麥互動的實現方案

 

 

《連麥互動直播方案全實踐》系列第一篇文章介紹了什麼是連麥互動直播，如今咱們來看一下網易雲信在連麥互動直播方案的演變過程。咱們從2015年年初就開始研究連麥互動直播技術，提出了一個在主播客戶端合流的方案。後來隨着移動端直播的快速興起，咱們在老方案的基礎上，迭代推出了一個新方案，也就是服務端合流方案。

接下來我會爲你們詳細闡述這兩個方案的具體實現方式，而且分析各自的優點、劣勢以及適用的場景。

 

主播端合流方案

首先咱們來看一下老方案，咱們稱之爲：主播端合流。

 

 

傳統的直播流程是：主播客戶端採集並編碼音視頻數據之後，直接使用RTMP協議推流到CDN，其它觀衆使用對應的拉流地址向CDN拉取音視頻流。

該方案咱們不改變由主播來推流這個架構，只是在主播須要與觀衆連麥互動時使用實時音視頻系統來進行主播和觀衆的實時互動連麥，經過實時通話通道主播端收到觀衆端發送的音頻和視頻數據，主播端將本身的聲音和觀衆的聲音作混音，並將本身的畫面與觀衆的畫面作視頻合成，最後主播將混合的聲音和畫面推流到CDN流媒體服務器。經過這種方式就實現了觀衆與主播的連麥互動直播。

那麼這個方案有什麼優缺點呢？

 

因爲上述兩個問題，該方案並非移動端上連麥互動的最佳方案。

爲了解決這兩個問題，咱們團隊用3個月時間來作技術攻關，設計並開發了一個替代方案。

 

服務端合流方案

這個全新的連麥互動直播方案，做爲優化替代方案，方案的關鍵是：主播再也不直接推流到CDN流媒體服務器，而是基於實時音視頻通話系統，由實時音視頻的中轉服務器轉發給互動直播服務器，再由互動直播服務器處理後推流到CDN流媒體服務器，互動直播服務器是咱們爲方案二全新研發的一個服務器。

音視頻實時通話系統，能夠實現多人的實時互動，並且多人模式下全部的數據包都是經過音視頻中轉服務器中轉。此時若是觀衆須要與主播連麥互動，只須要讓觀衆加入到實時音視頻的房間中，音視頻中轉服務器在轉發給房間中其餘客戶端的同時，轉發一份到互動直播服務器，互動直播服務器對收到的語音進行混音，同時對視頻畫面作混合處理，處理完畢之後再推流到CDN流媒體服務器。

經過這種方案，將方案一中由主播端作的混音混合及推流操做，轉嫁由互動直播服務器來承擔。對於普通觀衆不須要其它額外的處理邏輯就能在原來的拉流地址上拉取到連麥互動的直播畫面。

 

那新方案有哪些優勢？

 

 

簡單的提一下，有些APP使用不一樣與上述兩種方案的其它方案來實現連麥互動直播。也就是主播和連麥者分別發送一路RTMP流到CDN服務器，觀衆端經過分別拉取主播和連麥者的兩路流來實現連麥互動直播。

這個方案的問題是：RTMP協議延遲很高，通常至少在3秒，主播和連麥者之間使用RTMP協議來作連麥互動，互動的實時性是不可接受的。同時普通觀衆要拉取兩路流，功能流程會變得複雜，同時還增長了普通觀衆的下行壓力。

因爲這兩個問題，該方案不是一個合格可行的低延遲連麥互動方案。

 

那麼網易雲信全新的連麥互動直播方案具體是怎麼實現的呢？《連麥互動直播方案全實踐》第三篇文章將會向你們詳細介紹。