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