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