本文為《程式設計師》原創文章，未經允許不得轉載，更多精彩文章請訂閱2016年《程式設計師》
作者簡介： 張亞偉，齊聚科技技術研究院技術總監，擁有多年跨平臺直播開發經驗與技術積累。
責編：屠敏，歡迎技術投稿、約稿、給文章糾錯，請傳送郵件至[email protected]。

導語：本文專為介紹移動直播連麥實現架構和思路而寫，介紹了移動直播連麥的整體情況、各種實現架構和優劣比較等，包括連麥介紹、角色定義、連麥特點要求，合成思路介紹、各種合成方式比較等幾個小節。

移動直播連麥是主播在直播期間，與一位或多位粉絲進行實時音視訊互動，同時其他觀眾能觀看到該互動過程。移動直播連麥功能的推出讓直播的傳播方式由文字互動轉變成媒體互動模式，主播和觀眾的身份也轉換為發起者和參與者，相比傳統的單向直播，觀眾能更直接地參與，滿足與主播音視訊實時互動，對提升移動直播應用的活躍度和粘性都有明顯作用，故連麥已成為移動直播的必備功能。

連麥簡述

瞭解移動直播連麥實現架構，需要定義以下參與角色，首先介紹客戶端（如圖1），按使用者在連麥直播中的角色差異分別定義為A端（A主播）、B端（B主播）、C端（使用者）。

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所示。

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主播的媒體資料流，在伺服器之間傳遞時使用獨立的兩條線進行標示。

該實現思路有兩個特點：一是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伺服器實現，具體的工作流程介紹如下。

• 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、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合成音視訊資料流的實現細節。

瞭解最新移動開發相關資訊和技術，請關注mobilehub公眾微訊號（ID: mobilehub)。

130+位講師，16大分論壇，中國科學院院士陳潤生，美國伊利諾伊大學香檳分校（UIUC）計算機系教授翟成祥，馭勢科技聯合創始人、CEO吳甘沙、上交所前總工程師白碩等專家將親臨2016中國大資料技術大會。票價折扣即將結束，預購從速。