移动直播连麦实现思路：整体篇
導(dǎo)語：本文專為介紹移動直播連麥實(shí)現(xiàn)架構(gòu)和思路而寫，介紹了移動直播連麥的整體情況、各種實(shí)現(xiàn)架構(gòu)和優(yōu)劣比較等，包括連麥介紹、角色定義、連麥特點(diǎn)要求，合成思路介紹、各種合成方式比較等幾個小節(jié)。
移動直播連麥?zhǔn)侵鞑ピ谥辈テ陂g，與一位或多位粉絲進(jìn)行實(shí)時音視頻互動，同時其他觀眾能觀看到該互動過程。移動直播連麥功能的推出讓直播的傳播方式由文字互動轉(zhuǎn)變成媒體互動模式，主播和觀眾的身份也轉(zhuǎn)換為發(fā)起者和參與者，相比傳統(tǒng)的單向直播，觀眾能更直接地參與，滿足與主播音視頻實(shí)時互動，對提升移動直播應(yīng)用的活躍度和粘性都有明顯作用，故連麥已成為移動直播的必備功能。
連麥簡述
了解移動直播連麥實(shí)現(xiàn)架構(gòu)，需要定義以下參與角色，首先介紹客戶端（如圖1），按用戶在連麥直播中的角色差異分別定義為A端（A主播）、B端（B主播）、C端（用戶）。
?
?
圖1 移動直播連麥客戶端角色定義
?
A端，指當(dāng)前正在直播的主播，相當(dāng)于主持人，可以主動邀請用戶連麥或批準(zhǔn)當(dāng)前觀眾的連麥請求，也可以關(guān)閉某個B主播的連麥；A端視頻一般都是全屏顯示，A端直播主播（以下簡稱A主播）一般都要經(jīng)過平臺授權(quán)，具有直播權(quán)限。
B端，指參與當(dāng)前連麥的觀眾，可以向A主播申請連麥，或接受A主播的連麥邀請，進(jìn)行音視頻連麥，當(dāng)不想連麥后，B端可以主動斷開；B端的視頻一般只在右側(cè)的某個區(qū)域顯示，視頻尺寸較小，以不影響A主播視頻顯示為好。B端用戶在經(jīng)過平臺授權(quán)方面一般不做要求，其合規(guī)性要求由A主播代管，由于其也參與了直播，我們稱其為B主播。同時，受移動直播視頻顯示區(qū)域的限制，最多可以支持3個B主播同時連麥。
C端，是移動直播的觀眾，從用戶操作角度說，并沒有太大差異；數(shù)量上C端用戶沒有數(shù)量限制，故使用從1到n標(biāo)示。
總結(jié)，A主播在直播時僅有1個，而B主播則可以有多個；A主播一旦停止直播，則整個直播也就隨之結(jié)束了；而B主播可以隨時斷開或切換，即行為具有非常大的隨意性，這也是A主播和B主播在移動直播連麥中最顯見的差異。
下面介紹下移動直播視頻云平臺的結(jié)構(gòu)，為簡化模型不考慮數(shù)據(jù)存儲及各類型服務(wù)器集群的情況，僅描述移動直播連麥所需要的最簡單服務(wù)器類型，如圖2所示。
?
?
圖2 移動直播連麥服務(wù)器角色定義
?
ControlServer，控制服務(wù)器，用于控制和授權(quán)，如判斷A主播是否有直播權(quán)限，保存各項(xiàng)音視頻參數(shù)配置，提供服務(wù)器接入查詢等，還可以實(shí)現(xiàn)UpServer服務(wù)器的負(fù)載均衡和故障轉(zhuǎn)移等管理功能。
UpServer，直播主播上傳媒體數(shù)據(jù)服務(wù)器，主要包括兩個功能，一是負(fù)責(zé)A主播、B主播之間媒體數(shù)據(jù)的交互，二是按指定協(xié)議把媒體數(shù)據(jù)轉(zhuǎn)發(fā)給DeliveryServer。至于音視頻合成等擴(kuò)展功能，取決于實(shí)現(xiàn)合成的模式選擇，將在后續(xù)小節(jié)中進(jìn)行說明。
DeliveryServer，媒體數(shù)據(jù)分發(fā)服務(wù)器，接收UpServer服務(wù)器發(fā)送過來的媒體數(shù)據(jù)，并分發(fā)給直播觀眾；由于觀眾數(shù)量龐大，一般都需要使用集群實(shí)現(xiàn)，通用方式是使用各大CDN的視頻云平臺分發(fā)媒體數(shù)據(jù)，需要考慮跨網(wǎng)、就近、網(wǎng)絡(luò)速度、帶寬等指標(biāo)。
下面介紹其特點(diǎn)，與主播的直播相比，連麥實(shí)現(xiàn)的技術(shù)難點(diǎn)增大很多，具體如下：
低延遲互動，要保證A主播和B主播之間能夠?qū)崟r音視頻互動，兩者之間好比電話溝通，能在秒級以內(nèi)聽到對方的聲音、看到對方的視頻；否則連麥后延遲過大，將導(dǎo)致互動體驗(yàn)很差。
音視頻實(shí)時合成，其他觀眾需要實(shí)時收聽連麥聲音和觀看視頻，對音視頻的實(shí)時合成要求也很高，不能讓合成的算法復(fù)雜增加耗時，從而影響觀眾聽、看的體驗(yàn)。
音畫同步，移動直播連麥后對音畫同步的要求與單向直播中差異較大，不僅要求A主播自身的音畫同步，也要求A主播和每個B主播都要音畫同步，對音視頻的合成要求是高效和及時，對網(wǎng)絡(luò)延遲的精度控制也有比較高的要求。
合成思路
參與移動直播連麥的架構(gòu)中共涉及4個角色，分別是A主播、B主播、C用戶和服務(wù)器，理論上來說，這4個角色都可以負(fù)責(zé)音頻視頻的合成，即實(shí)現(xiàn)連麥的合成功能，從而確保每個C用戶看到連麥后的視頻和聽到音頻（注：負(fù)責(zé)合成的服務(wù)器類型僅限UpServer，而不包括其他類型的服務(wù)器）。
下面分別對這4個角色實(shí)現(xiàn)的思路進(jìn)行初步介紹和比較。本節(jié)將介紹B主播合成和C用戶合成兩種思路。后續(xù)兩節(jié)分別描述使用服務(wù)器（UpServer）合成和A主播合成，個人認(rèn)為這兩種實(shí)現(xiàn)思路更具有優(yōu)勢。
B主播合成
從參與角色上來說，使用B主播合成音頻視頻是可行的，可是為什么說該思路不靠譜呢，具體有以下3點(diǎn)。
-
不唯一，從角色介紹中可知最多有3個B主播參與到連麥中，故選擇一個最佳的B主播存在一定困難。如果選擇了B1主播，之后發(fā)現(xiàn)B3主播合成更有優(yōu)勢，是否切換呢？不切換則用戶的連麥體驗(yàn)效果會差一點(diǎn)，而切換則導(dǎo)致連麥的過程中出現(xiàn)卡頓。相比之下，由A主播負(fù)責(zé)合成不存在不唯一的問題。
-
參與隨機(jī)性，任意B主播可以隨時開始或停止連麥。當(dāng)多個B主播參與連麥時，根據(jù)性能最優(yōu)選中B2負(fù)責(zé)合成，但B2掉線或主動停止連麥了，則是切換到A主播或是其他B主播，還是等待B2主播再開始連麥呢？無論如何處理，都會造成一些卡頓。而使用A主播負(fù)責(zé)合成，則不存在該問題，能夠完全實(shí)現(xiàn)B主播連麥和斷開的自由切換；更近一步，如果A主播掉線則整個直播都將停止。
-
手機(jī)性能和網(wǎng)絡(luò)性能無法保證，B主播一般都是由粉絲轉(zhuǎn)化而來，其直播手機(jī)和網(wǎng)絡(luò)性能，是否符合直播要求無法在短時間內(nèi)驗(yàn)證。從使用資源說，參與直播且進(jìn)行音視頻的合成將比個人直播消耗更多，故使用B主播合成性能方面存在較大風(fēng)險(xiǎn)。相應(yīng)的使用A主播合成則性能風(fēng)險(xiǎn)較小，原因是A主播都是經(jīng)過平臺授權(quán)和驗(yàn)證，且通過了較長直播時間考驗(yàn)，對于直播手機(jī)和網(wǎng)絡(luò)的掌控可靠得多。
基于以上三方面的分析，排除了使用B主播負(fù)責(zé)整體直播連麥音視頻合成的工作。但B主播仍然要負(fù)責(zé)其本地的音視頻合成，目的是供B主播自己觀看視頻和收聽其他主播的聲音。
C用戶合成
由C端用戶負(fù)責(zé)合成音視頻，需要A主播、B主播把所有媒體數(shù)據(jù)，通過服務(wù)器發(fā)送給C端的用戶，具體結(jié)構(gòu)圖如圖3所示，圖中為區(qū)分A主播、B主播的媒體數(shù)據(jù)流，在服務(wù)器之間傳遞時使用獨(dú)立的兩條線進(jìn)行標(biāo)示。
?
?
圖3 移動直播連麥C端合成結(jié)構(gòu)圖
?
該實(shí)現(xiàn)思路有兩個特點(diǎn)：一是C端用戶需要兼容能力好的播放器，要支持A主播、多個B主播的音視頻解碼，時間戳同步，視頻同步繪制和聲音播放等。二是A主播、B主播之間的媒體數(shù)據(jù)也要通過UpServer服務(wù)器進(jìn)行分發(fā)，為了各自的音視頻呈現(xiàn)，A主播、B主播也要執(zhí)行相應(yīng)的合成工作。為簡化結(jié)構(gòu)圖，A、B主播之間的媒體數(shù)據(jù)分發(fā)未在圖3中繪制。
由C端用戶側(cè)負(fù)責(zé)合成，比使用B主播合成還更靠譜一點(diǎn)，但也存在一些顯而易見的問題。
-
成本高，該模式需要的成本高主要體現(xiàn)在服務(wù)器帶寬消耗上，A主播、B主播（多個）音視頻數(shù)據(jù)流都要推送到每個用戶手機(jī)上，比僅推送合成后的數(shù)據(jù)流，為每個用戶要增加約40%以上網(wǎng)絡(luò)帶寬。如用戶量較少則成本增加不明顯，若觀看用戶非常多，相對于僅推送一路數(shù)據(jù)流，成本大幅度攀升了，畢竟服務(wù)器帶寬是公司需要掏真金白銀的。
-
播放器實(shí)現(xiàn)復(fù)雜度高，C端需要接收多路音視頻數(shù)據(jù)流，并在多路數(shù)據(jù)流播放時做到音視頻同步，且網(wǎng)絡(luò)抖動的控制、播放的時間戳同步、音頻視頻合成的復(fù)雜度都會明顯提高。在控制層面，B主播的任意切換也將需要C端播放器實(shí)時調(diào)整，故對播放器的開發(fā)維護(hù)要求很高。
-
互動效果差，當(dāng)使用多路數(shù)據(jù)流推送給C端用戶時，由于網(wǎng)絡(luò)延遲、丟包等不穩(wěn)定因素，可能造成A、B主播媒體數(shù)據(jù)到達(dá)時間差異大，此時合成很可能導(dǎo)致用戶觀看A、B主播視頻之間有較大延遲，即A、B主播之間沒有構(gòu)成同一個舞臺的效果，失去了互動性。若采用A端合成或UpServer合成，A、B主播的媒體數(shù)據(jù)是同時到達(dá)C用戶端的，具有比較好的互動性。
-
主播端實(shí)現(xiàn)不簡單，當(dāng)C用戶負(fù)責(zé)合成時，A主播和B主播不再負(fù)責(zé)整體的音頻、視頻合成，但仍然要負(fù)責(zé)本地的音視頻合成，供自己使用，否則自己無法觀看視頻和收聽聲音。本地的合成任務(wù)大部分可以和整體合成任務(wù)重復(fù)，此時就不能復(fù)用了。
總結(jié)，基于以上原因分析故也不建議選擇C端合成媒體的思路實(shí)現(xiàn)移動直播連麥。
UpServer合成
Server端合成與C端合成的結(jié)構(gòu)略有不同，結(jié)構(gòu)如圖4所示，其媒體流的合成功能由UpServer服務(wù)器實(shí)現(xiàn)，具體的工作流程介紹如下。
?
?
圖4 移動直播連麥Server端合成結(jié)構(gòu)圖
?
-
A主播和B主播都要把自己采集到的音頻、視頻數(shù)據(jù)，在編碼打包后發(fā)給UpServer服務(wù)器。
-
UpServer執(zhí)行合成功能，把合成好的音視頻數(shù)據(jù)流推送給DeliveryServer，并由該服務(wù)器分發(fā) 給眾多的移動直播觀眾。
-
為滿足A主播收看其他主播視頻、收聽其他主播音頻的需要，UpServer還需要進(jìn)行特殊處理，把未合成的視頻，合成好的音頻發(fā)送給A主播。
-
類似的，為滿足B主播收看其他主播視頻、收聽其他主播音頻的需要，UpServer也需要進(jìn)行相應(yīng)的特殊處理。
-
為簡化該實(shí)現(xiàn)思路結(jié)構(gòu)圖，針對第3步、第4步的特殊處理數(shù)據(jù)流并未在圖4中畫出。
-
UpServer給A主播或是B主播特殊處理的方式差異，造成推送的數(shù)據(jù)流是不同的；此時A主播或是B主播需要完成的功能也是不盡相同的，關(guān)于該部分的處理細(xì)節(jié)，將在后續(xù)的文章中詳盡描述。
說完由UpServer端合成的基本工作流程，下面介紹下該思路的優(yōu)缺點(diǎn)。
-
及時性最高，由UpServer負(fù)責(zé)合成A主播和B主播的媒體數(shù)據(jù)，音視頻數(shù)據(jù)經(jīng)歷的網(wǎng)絡(luò)延遲最小，UpServer合成后直接發(fā)送給移動視頻直播云平臺，網(wǎng)絡(luò)帶寬和丟包方面也不必?fù)?dān)心，畢竟服務(wù)器的網(wǎng)絡(luò)質(zhì)量還是放心的。
-
音畫同步好，在主播接入的第一級服務(wù)器UpServer上進(jìn)行媒體數(shù)據(jù)合成，由于媒體數(shù)據(jù)接收不完整或網(wǎng)絡(luò)抖動延遲增大，造成音畫不同步的可能性大幅降低了；相比其他模式，多個主播的音畫同步得到良好的保證。
-
服務(wù)器資源消耗高，與其他思路相比，服務(wù)器除了必須的媒體數(shù)據(jù)傳輸和緩存功能外，還增加了音視頻的合成工作，順序上首先要把主播編碼后的媒體數(shù)據(jù)解碼，接著再根據(jù)配置方案進(jìn)行合成，最后再次進(jìn)行編碼和打包。眾所周知，視頻編碼消耗CPU資源還是很厲害的，即使是高性能服務(wù)器硬件，與不執(zhí)行合成任務(wù)相比，其處理的移動直播上傳數(shù)量會明顯下降。
-
服務(wù)器復(fù)雜度高，服務(wù)器實(shí)現(xiàn)復(fù)雜度高包括兩個方面：一是解碼、合成、編碼需要大幅增加服務(wù)器的復(fù)雜度，如果使用很好的模塊化設(shè)計(jì)，且每個模塊都非常穩(wěn)定，則這塊影響不大。二是A、B主播，與普通觀眾所需要的數(shù)據(jù)流是不盡相同的，為滿足每個終端都可以正常觀看視頻和收聽音頻都需要特殊處理，且音頻和視頻的處理邏輯可能完全不同，需要梳理流程和詳盡設(shè)計(jì)。
-
質(zhì)量下降，視頻、音頻的編碼算法為了保證高壓縮率，它們都采用了有損壓縮的編碼方式。由UpServer負(fù)責(zé)音視頻合成任務(wù)，合成后需要再次編碼，如果選擇視頻質(zhì)量非常高的視碼參數(shù)，雖說質(zhì)量降低很小，但碼率升高以致得不償失，如果與主播端使用的相同的編碼參數(shù)，則會造成音視頻質(zhì)量下降。
總結(jié)，該思路完成連麥功能是完全可以實(shí)現(xiàn)的，但也存在一些爭議，如服務(wù)器硬件資源和服務(wù)器程序編碼質(zhì)量要求高，故需要具有相當(dāng)開發(fā)經(jīng)驗(yàn)的服務(wù)器工程師進(jìn)行開發(fā)。后期UpServer服務(wù)器的維護(hù)也同樣重要，務(wù)必實(shí)時監(jiān)控服務(wù)器資源占用情況，如消耗資源達(dá)到瓶頸，用戶端觀看時會卡得很厲害，體驗(yàn)差，需高度重視。
A主播合成
該實(shí)現(xiàn)思路要求A主播分別把自己的音頻、視頻數(shù)據(jù)與B主播的數(shù)據(jù)合成，然后把合成好的媒體流發(fā)給服務(wù)器，并由服務(wù)器集群廣播給所有用戶。故A主播手機(jī)負(fù)擔(dān)的任務(wù)更重，對手機(jī)性能和網(wǎng)絡(luò)性能要求也比普通直播時更高一些。A主播合成實(shí)現(xiàn)結(jié)構(gòu)如圖5所示，下面描述下該實(shí)現(xiàn)方式的一些基本流程。
- A、B主播通過UpServer服務(wù)器建立媒體數(shù)據(jù)傳輸通道，使每個主播都可以獲得其他主播的媒體數(shù)據(jù)。
- B1主播拿到A主播和其他B主播的視頻、音頻，也要做相應(yīng)的合成工作，用于自己的視頻顯示和聲音播放。
- A主播拿到所有B主播的媒體數(shù)據(jù)后，也進(jìn)行合成，一方面用于自己的顯示和播放，另一方面要發(fā)給UpServer服務(wù)器，用于C端用戶觀看。
- UpServer服務(wù)器要負(fù)責(zé)兩方面內(nèi)容，一是A、B主播之間的媒體數(shù)據(jù)分發(fā)，二是把A主播合成好的數(shù)據(jù)發(fā)送給DeliveryServer服務(wù)器。
?
?
圖5 移動直播連麥A端合成結(jié)構(gòu)圖
?
為簡化圖5的結(jié)構(gòu)圖，A、B主播之間的媒體數(shù)據(jù)傳輸，僅繪制了B主播到A主播的一條線路，以表示數(shù)據(jù)是由A主播負(fù)責(zé)合成的；實(shí)際上它們之間的數(shù)據(jù)傳遞如上面的流程描述所說，仍然是通過UpServer服務(wù)器雙向傳輸?shù)摹?/p>
基于上面的流程，總結(jié)下該實(shí)現(xiàn)方式的優(yōu)劣。
低成本，與使用Server端合成相比，由于UpServer端不用視頻、音頻的重新解碼、編碼工作，也不需要執(zhí)行合成任務(wù)，可以極大降低該服務(wù)器的CPU消耗；即把媒體合成資源從占用服務(wù)器轉(zhuǎn)換為占用主播手機(jī)了，該方式也符合互聯(lián)網(wǎng)分布式計(jì)算的特點(diǎn)。由服務(wù)器負(fù)責(zé)合成音視頻，使用高性能服務(wù)器硬件若可以支持50個移動直播連麥，則在相同硬件條件下，不使用服務(wù)器端合成至少可以支持200個以上。
與使用C端用戶側(cè)合成相比，媒體數(shù)據(jù)的視頻云分發(fā)網(wǎng)絡(luò)僅需要推送一路數(shù)據(jù)流，當(dāng)用戶量很大時可以顯著降低帶寬成本。互動效果不錯，A主播和B主播之間的溝通僅需要跨越UpServer服務(wù)器，類似電話的直接溝通，網(wǎng)絡(luò)延遲和視頻質(zhì)量可以控制的很好，互動效果滿意。A主播合成后通過視頻云平臺分發(fā)給觀看用戶，A、B主播之間的音畫同步問題得到很好的解決，不會向使用多個數(shù)據(jù)流發(fā)送時，用戶側(cè)出現(xiàn)的多個主播之間音畫不同步現(xiàn)象。
音視頻質(zhì)量，相對于UpServer端合成導(dǎo)致的二次編碼損失，A主播的音視頻在采集后先進(jìn)行合成，后進(jìn)行編碼，故A主播的音視頻沒有二次編碼造成質(zhì)量損失的問題。在該實(shí)現(xiàn)思路下，B主播的音視頻質(zhì)量損失與UpServer合成相同，考慮到視頻顯示上以A主播為主，故影響不大。
缺點(diǎn)也有兩條，一是對A主播的手機(jī)性能、網(wǎng)絡(luò)性能要求更高一點(diǎn)，畢竟執(zhí)行的任務(wù)增加了；考慮到即使不進(jìn)行整體的合成工作，為滿足本地觀看和收聽需要，也要執(zhí)行相關(guān)的合成工作，故增加的任務(wù)量并不太多，整體在可控范圍內(nèi)。
二是與Server端合成相比要耽擱一些時間，增加一次A主播到UpServer服務(wù)器之間的往返網(wǎng)絡(luò)時延（RTT），但也僅限B主播音視頻增加該時延，A主播的音視頻是在合成后編碼打包直接發(fā)送的，故不增加該網(wǎng)絡(luò)時延。
總結(jié)，使用A主播進(jìn)行連麥的音頻視頻合成還是非常有價值的，既可以保證A、B主播之間的及時互動，也可以降低UpServer資源消耗，是我推薦的一種實(shí)現(xiàn)方式。
后記
這篇文字是移動直播連麥實(shí)現(xiàn)思路的整體介紹，主要包括音頻視頻合成的幾種實(shí)現(xiàn)思路：A主播合成、B主播合成、C用戶端合成和Server端合成媒體數(shù)據(jù)，比較了它們之間的一些優(yōu)劣等。基于比較結(jié)果，筆者反對使用B主播合成和C用戶端合成兩種實(shí)現(xiàn)方式，贊同A主播合成或是Server端負(fù)責(zé)媒體數(shù)據(jù)流的合成。
至于是使用A主播合成，還是Server端負(fù)責(zé)合成，個人理解是看公司的運(yùn)營成本，如果公司、為該功能實(shí)現(xiàn)投入不計(jì)成本，那么建議選擇由Server端合成媒體數(shù)據(jù)；如果公司精打細(xì)算、依靠低成本高技術(shù)手段推進(jìn)業(yè)務(wù)，那么建議選擇A主播合成模式。
后續(xù)將分別介紹A主播合成、UpServer合成音視頻數(shù)據(jù)流的實(shí)現(xiàn)細(xì)節(jié)。
總結(jié)
以上是生活随笔為你收集整理的移动直播连麦实现思路：整体篇的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 这么多连麦方案，到底哪种适合你？
- 下一篇： 最新 WebRTC 源码目录结构分析