一、前言
移動直播這把火從2015年一直燒到2016年，毫無疑問直播是當前移動互聯網最熱門的領域之一，在超大熱度的引導下直播領域也吸引了大量的商業資本。在這各大直播應用萬花齊放的時刻，也正是直播應用面臨的真正風口。站在這個風口上，直播應用只把握好風向標，推出具備高用戶粘性的差異化功能，才能在這個不斷推陳出新的時代站穩腳跟，獲得不可動搖的地位。
當前國內大多數的直播應用，使用的是單主播模式，主播與觀衆僅僅使用文字、點贊、禮物等方式進行互動。在主播直播時，觀衆如果能夠與其進行實時的視頻互動，給觀衆連麥露臉的機會，這將大大提高用戶的參與感與幸福感，增加用戶粘性。而且市面上能夠提供這種連麥互動直播功能的應用還非常少，這也將成爲2016下半年各直播應用的主要競爭領域。
二、連麥互動直播是什麼
爲了更直觀的闡述互動直播是什麼，舉個簡單的例子：傳統直播就像看“新聞聯播”，觀衆只能收看這個節目，偶爾能通過手機短信發信息與節目組進行互動。當然現在基於互連網的直播已經先進得多，可以使用互聯網發送文字、點贊、送禮物，消息的實時性也大大提高，但本質上與看“新聞聯播”的體驗類似。
而互動直播就像到達芒果臺快樂大本營的錄製現場，觀衆坐在錄製現場的觀衆席上，可以看節目，同時還有機會被邀請到臺上和主持人互動，當然主持人可以邀請多名觀衆上臺進行互動，而互動的內容其他觀衆也能看到。
連麥互動直播相比傳統單向直播，給了觀衆更直接的參與感以及與主播音視頻實時互動的滿足感，對提升直播應用的活躍度和粘性都有明顯作用。
三、連麥互動直播功能流程
（連麥互動直播功能流程圖）
① 主播正常開始直播，普通觀衆看到主播的單人直播畫面；
② 需要連麥的觀衆發起連麥請求，進入連麥申請列表；
③ 主播從連麥申請列表中選擇一名或多名觀衆進行連麥操作，主播與連麥觀衆進行實時音視頻互動，同時互動直播系統生成“合成畫面”；
④ 普通觀衆看到直播畫面爲包含主播與連麥觀衆的“合成畫面”；
⑤ 連麥結束，恢復主播單人直播模式。
四、連麥互動直播實現方案
接下來我們探討一下連麥互動直播的具體實現方案，這部分將主要闡述互動實時性高且具備真實可行性的兩種方案。這兩種方案網易雲信在項目中都有實踐，下面會詳細分析各自的優缺點。
爲了實現互動實時性高的連麥，首先需要有一套實現了類似微信、Skype及Facetime的多人音視頻實時通話系統。這套實時通話系統可以選擇自主研發或者基於開源軟件如：Google的WebRTC做二次開發，網易雲信自主研發了一套基於私有協議的多人實時通話系統，下面簡單介紹多人實時通話系統的一些重點技術細節。
① 多人音視頻實時通話系統爲了降低通話時延，我們使用UDP協議作爲傳輸層協議，衆所周知UDP協議是不可靠，爲了提高弱網下的實時音視頻的通話效果，需要使用相關方案來做QoS保障，主要包括：a)使用基於網絡狀態的音視頻碼率自適應算法，根據當前網絡的丟包、時延自適應降低或者升高音頻和視頻的碼率和幀率，通過這個方法來降低網絡的擁塞，提高通話質量；b)使用智能Jitterbuf算法來平滑網絡抖動，同時內部使用音頻編碼的丟包補償（PLC）算法進一步提升通話質量；c)使用基於多層參考的視頻編解碼器，降低視頻丟包後的卡頓；d)整個UDP傳輸層使用前向糾錯FEC算法進行智能保護，最大限度上保證實時音視頻通話的效果。根據我們的實際測試，在使用上訴QoS保障策略以後，音視頻通話可以抗20%丟包和600ms的網絡抖動。
② 多人音視頻實時通話系統爲了在保障質量的前提下儘量降低通話流量，音頻編解碼主要以Opus爲主，Opus融合吸收了CELT和SILK編碼的各種優點，具備高音質，高壓縮率，高抗丟包等特性，非常適合移動網絡。視頻編解碼我們使用OpenH264，OpenH264編解碼性能優秀，同時具備：動態碼率、動態幀率及時域分層等多項適合移動網絡實時通話的特性。同時我們使用了自主研發的降噪算法，配合回聲消除、自動增益和舒適噪音等音頻處理算法來進一步保證音頻的質量。
③ 現在用戶對於視頻的清晰度要求越來越高，我們的多人實時通話系統能夠支持720p，720p下純軟件編解碼對CPU開銷過大，因此在可以開啓硬件編解碼的機器上，對於需要720p清晰度的都儘量使用硬件編解碼。對於蘋果手機硬件編解碼基本上只與iOS的版本相關，而Android情況就會複雜得多，不僅與手機硬件相關，還和各個手機的ROM相關，爲了解決這個問題需要去做適配。我們在網易強大的移動應用測試部門的配合下，爲大多數的Android設備做了適配。
④ 沒有覆蓋全球的服務器部署與網絡拓撲搭建，是不可能構架出一套完善的多人音視頻實時通話系統的。依賴網易雲在全球範圍內的機房節點，我們搭建了多個多線接入網絡拓撲，部署了高可用的服務器集羣，並利用智能分配算法與路由策略，爲跨省、跨運營商、跨國的多人實時通話提供優質的傳輸通道。
要實現效果理想的連麥互動直播，一套強大完善的多人實時通話系統是前提。在簡單介紹完一套強大的多人實時通話系統的需要具備的特點後，接着我們就可以討論下連麥互動直播的具體實現方案了。
方案一：
傳統的直播流程是：主播客戶端採集並編碼音視頻數據以後，直接使用RTMP協議推流到CDN，其它觀衆使用對應的拉流地址向CDN拉取音視頻流。
該方案使用實時通話系統來進行主播和觀衆的實時互動連麥，通過實時通話通道主播端收到觀衆端發送的音頻和視頻數據，主播端將自己的聲音和觀衆的聲音做混音，並將自己的畫面與觀衆的畫面做視頻合成，最後將混合的聲音和畫面推流到CDN流媒體服務器。架構圖如下：
方案優點：
① 主播和連麥觀衆使用了實時音視頻來進行連麥互動，實時性高，觀衆看到的合成畫面裏主播和觀衆的互動也是同步實時的。
② 方案對原有直播推流客戶端改動不大，服務端都不需要修改。方案整體的實現簡單，利用現有的系統和SDK就可以快速搭建。
我們在網易BOBO Windows端實現的連麥互動直播就是採用這種方案，該方案在2015年下半年上線後運行穩定。這個方案雖然簡單可行但對於移動端來說就有兩個比較致命的問題：
① 主播端的帶寬壓力很大，從架構圖中可以看出，主播端必須通過實時通話系統發送一份音視頻數據給連麥觀衆，同時還需要推送一路流到CDN流媒體服務器。所以相比單人直播，連麥後主播端的上行流量將變爲原來的兩倍。這個兩倍的流量在Windows端穩定的有線網絡環境下影響不大，但在上行帶寬本來就有限移動網絡下，將會大大影響直播的效果。
② 主播端的視頻編解碼壓力很大，與造成帶寬壓力大的原因一樣，主播必須編碼一路視頻給連麥觀衆，同時需要合成並編碼一路推到CDN，兩次編碼對於移動端的性能壓力非常大，經過真機測試對於720p的分辨率的連麥互動直播僅在旗艦機型上可以勉強支撐，但發熱和耗電會大大增加。
由於上述兩個問題，我們認爲方案一在移動場景下是不太適用的。
方案二：
爲了解決方案一的問題，我們團隊用3個月時間來做技術攻關，設計並開發了一個替代方案。架構圖如下：
本方案作爲優化替代方案，方案的關鍵是：主播不再直接推流到CDN流媒體服務器，而是基於實時音視頻通話系統，由實時音視頻的中轉服務器轉發給互動直播服務器，再由互動直播服務器處理後推流到CDN流媒體服務器。
多人音視頻實時通話系統，可以實現多人的實時互動，而且多人模式下所有的數據包都是通過音視頻中轉服務器中轉。音視頻中轉服務器在轉發給參與客戶端的同時，轉發一份到互動直播服務器，互動直播服務器對收到的語音進行混音，同時對視頻畫面做混合處理，處理完畢以後再推流到CDN流媒體服務器。通過這種方案，將方案一中由主播端做的混音混合及推流操作，轉嫁由互動直播服務器來承擔。
方案優點：
① 主播和連麥觀衆使用了實時音視頻來進行連麥互動，實時性高，普通觀衆看到的合成畫面裏主播和觀衆的互動也是同步實時的；
② 可以實現多人連麥互動直播，功能差異化明顯；
③ 所有客戶端的上行推流不再依賴基於TCP的RTMP協議，而是使用網易自研的基於UDP的高性能私有協議，傳輸層的QoS保障更加智能高效；
④ 方案一中主播端的帶寬和性能壓力不復存在，本方案非常適合移動端的連麥互動直播。
當然本方案雖然有很多優點，但是實現起來也是最困難的。首先本架構涉及到實時通話系統與互動直播系統兩大系統的融合，架構和代碼複雜度高。特別是互動直播系統，由於要處理視頻的混合，對服務器端代碼的性能和硬件要求都很高。我們爲了解決這個問題，使用了網易機房裏多臺高性能物理機作爲連麥互動直播服務器，並且不斷優化服務器端代碼架構和處理流程，通過不斷的優化，最終滿足了業務需求。綜上，我們認爲本方案是當前最適合移動端的連麥互動直播方案。
五、展望未來
2016年作爲移動直播元年，全球範圍內的開發者和公司都在思考如何提供更加優質的服務。我們認爲內容永遠都是直播發展的王道，作爲研發工程師的職責就是爲內容的傳輸保駕護航，提供高清、流暢且延遲低的直播內容。而差異化的功能將成爲直播應用的亮點，其中擁有連麥互動的直播應用將會在增加用戶的參與度、幸福感的同時提高用戶粘性，連麥互動直播的重要性也就不言而喻了。
科技永遠都是第一生產力，當前VR虛擬現實技術與直播一樣火爆。而VR與直播結合的VR直播能夠讓觀衆身臨其境，它獨特的互動方式或許在不久的將來，就會在直播領域掀起新一輪的變革。而互動直播在未來將是一個以泛生活和場景化直播爲主題，充分結合VR技術，全面開啓新聞、旅遊、教育、醫療等全場景沉浸式“直播+”時代。