聊一聊直播利器，連麥互動背後的混流方案：到底該怎麼混？（二）

來自專欄 即構科技Zego實時語音視頻技術專欄

借《無間道》中曾志偉黑老大的名言作為開場白：出來混，遲早是要還的。

雖然話這麼說，但是在哪混，跟對了老大，命運際遇就會大不相同。在連麥互動直播中，在哪混（流），同樣很重要，做對了選擇，用戶體驗就會大不相同。

閑話少說，容我開篇論道。

可以在哪混？

在決定在哪混之前，讓我們先搞清楚可以在哪裡混。

上一篇我們討論要不要混流，這一篇我們將討論在哪裡混流。

圖一 連麥互動直播方案系統拓撲圖

圖一是目前業界主流的連麥互動直播方案系統拓撲圖。

拓撲圖裡包含以下實體：

1) 推流端（主播端）：主播的工作環境，包括手機硬體配置和網路環境。手機的計算能力和上行網路往往會成為連麥互動直播的瓶頸。

2) 服務端（伺服器集群）：龐大而複雜的伺服器集群，實現音視頻雲端的調度和計算能力。具體會包括信令伺服器，媒體伺服器集群，混流調度中心和混流伺服器集群等。

3) CDN網路：第三方獨立的公共服務網路，提供緩衝，存儲和轉發的能力。

4) 拉流端（觀眾端）：觀眾觀看直播的環境，包括手機硬體配置和網路環境。拉流端一般來說是從CDN拉流，而不會參與連麥互動，手機的計算能力和下行網路不會成為直播的瓶頸。

拓撲圖中的實體之間的活動包含：

1) 推流：推流端把原始音視頻流推到媒體伺服器集群。

2) 拉流：分為兩種情形：推流端從伺服器集群拉取其它主播的音視頻流；拉流端從CDN網路邊緣節點拉取音視頻流播放，可以是單流或者多流。

3) 轉推CDN：分兩種情形：如果在服務端混流，伺服器集群會把一路混好的音視頻流推到CDN網路；如果在推流端混流，推流端會把一路混好的音視頻流推到CDN網路。

搞清楚江湖上有哪些山頭後，我們就可以明智地選擇在哪裡混了。

首先，排除CDN網路，因為它是第三方服務，在連麥互動直播雲服務平台的掌控之外。

接著，在拉流端混流其實就是上一篇中提到的不混流方案。拉流端拉多流，在播放的時候根據業務側的需求，對多路流進行靈活操控。拉流端混流方案的優勢是高度靈活易於操控，劣勢是網路帶寬成本相對比較高。因為已經在上一篇深入討論過，所以這裡不再展開討論。

最後剩下的選擇，是推流端和服務端：推流端使用了音視頻雲服務的SDK，服務端是提供音視頻雲服務的伺服器集群，兩者都是可以做混流的地方。

決定在哪混？

我們現在要決定在哪混，擺在面前有兩個選擇：推流端 vs 服務端。

我們要搞清楚在推流端混流和在服務端混流的優勢和劣勢，才能作出明智的選擇。

在推流端混流

如果要搞清楚在推流端混流的優勢和劣勢，那麼得先搞明白在推流端混流的技術邏輯。

圖二 推流端混流技術邏輯圖

圖二是在圖一的基礎上，增加了推流端混流的技術邏輯（藍色部分）:

1) 推流端向伺服器集群推原始音視頻流。

2) 推流端從服務端拉取其它推流端推上去的音視頻流。混流將在第一主播的推流端進行。第一主播要等到其它所有主播的音視頻流到達以後才能開始混流。

3) 推流端進行混流的工作內容包括解碼，對齊畫面（音畫同步），抖動緩衝，和重新編碼。

4) 推流端（第一主播）把混好的單流推到CDN網路，以便拉流端拉流播放。

接著，讓我們看看在推流端混流會帶來多少額外的工作量。

在推流端混流有以下步驟：

1) 推流端拉流，等待其它主播的音視頻流到達、2) 解碼、 3) 混流、4) 編碼、5) 轉推流。

其中第1步至第2步是推流端在不混流的情況下也必須要做的事情，第3步至第5步是在要混流的情況下額外增加的工作。兩路流混成一路流的工作量大概是解碼一路流的一半不到，解碼一路流的工作量大概是編碼一路流的一半。然而，要考慮隨著混流數目的增加，混流的工作量也會相應增加。

然後，讓我們看看混流的要求和推流端的特點。混流是一個比較燒資源的事情，推流端是一個比較缺資源的地方，這倆天生八字不合。現在突然說要讓它們在一起，那我們就要先研究一下它們的要求和特點。

（推流端）混流的要求

1) 比較好的上行網路帶寬，因為推流端（第一主播）要推原始流和混流兩路流。另外，網路要保持相對穩定，因為混流過程中的抖動緩衝將會由於網路不穩定而加長，從而增加延遲。

2) 比較好的手機硬體配置，因為要對多路音視頻流進行轉碼和混流，比較耗費計算資源。如果需要轉碼的音視頻流的碼率總和比較高的話，某些採用軟編的安卓平台可能會出現手機太燙，從而導致攝像頭採集的時候丟幀的現象。

推流端的特點

1) 主播的網路環境可能是家庭寬頻或者4G。下行帶寬大概100M bps, 上行帶寬大概1M bps。家庭寬頻的穩定性和網速會隨著繁忙時段而變化。這個在我國生活的人們都懂的。

2) 主播的直播終端是主播個人的智能手機。目前主流的手機配置是四核，可以進行連麥互動直播。然而，手機硬體配置終究難以和PC相提並論，更不要說和伺服器相比了。

3) 不可控。直播業務平台或者直播雲服務平台都無法掌控推流端的手機配置和網路環境。傳統的秀場直播平台或者和傳統媒體結合的直播平台會給主播提供直播間，擁有比較好硬體配置和網路環境。其它娛樂直播平台的主播一般都是使用個人手機和家庭寬頻進行直播的。

這麼擺開來一對比，一眼就能看出這倆真是八字不合：一個處女座，一個不給力。

最後，讓我們來總結一下推流端混流的優勢和劣勢。

在推流端混流的優勢

1) 成本低

整體來說，推流端混流是一個低成本的方案。它在兩個方面降低成本：計算資源和網路帶寬。本質上，在推流端混流就是服務端把混流的成本轉嫁給推流端。服務端的計算資源和網路帶寬都相對比較昂貴，而推流端的計算資源和網路帶寬都是沉著成本。如果在推流端做混流，就降低了服務端的成本，充分利用了推流端能共享的資源。

2) 服務端壓力小

在服務端混流是相對來說是集中的模式，這樣會增加服務端的壓力。在推流端混流是完全分散式的模式，這樣可以降低服務端的壓力。

3) 本地輸出混流後的數據

在推流端混流以後將會輸出混流後的音視頻流，這樣方便本地進行錄製，或者直接把音視頻流推到CDN網路進行分發。

在推流端混流的劣勢

1) 增加額外延遲

首先，在推流端進行混流會增加額外的延遲，主要是因為要等待所有其它推流端的音視頻流到達，才能開始混流。從圖二我們可以看到，在服務端混流，只要所有主播的音視頻流到達服務端，就可以開始混流；在推流端混流，要在前者的基礎上，其它所有推流端的音視頻流再被拉流到推流端，才能開始混流。這是額外的時間開銷。其次，推流端混流完畢以後推流到CDN網路的延遲也相對較大，因為推流端的硬體配置和上行帶寬質量都無法和服務端相比。最後，考慮到推流端種種不穩定的情況，額外的延遲只會增多而不會減少。

2) 手機硬體配置瓶頸

在推流端進行混流要求比較好的手機硬體配置。一般來說，目前主流的四核手機能滿足連麥互動直播的要求。然而，如果算上混流的工作量，手機的硬體配置將會成為瓶頸。比如說，如果安卓手機採用軟編，並且需要混的音視頻流的數目比較多的話，手機會因為計算量較大而發熱，很可能會導致攝像頭（離CPU比較近）採集視頻的時候出現丟幀的現象。

3) 上行網路帶寬瓶頸

在推流端進行混流要求比較好的上行網路帶寬。如果下行網路帶寬是100M bps，那麼上行網路帶寬相對應一般是1M bps，好一點的會到4M bps。根據即構科技的經驗，音視頻流平均的碼率是800k bps。推流端將會推兩路流：原始的音視頻流和混流後的音視頻流，因此總共推流的碼率大概是1.6M bps。再考慮到網路帶寬在上網人數較多的時間段會打折扣，和網路不穩定等情況，推流端的上行網路帶寬往往是不能夠滿足推流端混流的要求的。

4) 推流端環境不可控

綜合上面第二和第三點，推流端的環境是不可控的。直播業務平台或者直播雲服務平台都沒辦法管控推流端的硬體配置，使用習慣，網路信號和網路帶寬等因素。因此，在推流端做混流的效果也是不可控的。

5) 難以擴展

在音視頻雲服務方案設計階段，我們預期方案是易於擴展的。隨著直播業務平台的發展，對推流端的計算能力和網路帶寬都將會有升級的要求。然而，推流端的環境是不可控的，而且也是難以擴展的。相對而言，在服務端做推流，如果要增加服務端的CPU或者增加網路帶寬，都是在音視頻雲服務平台掌控範圍以內的事情。

綜上所述，推流端不是一個理想的做混流的地方，但是它提供了一個低成本的混流方案。推流端混流能夠滿足相當一部分直播業務平台的某個發展階段的業務需求。這個市場需求是應該被充分發掘和滿足的。

在服務端混流

如果要搞清楚在服務端混流的優勢和劣勢，那麼得先搞明白在服務端混流的技術邏輯。

圖三 服務端混流技術邏輯圖

圖三是在圖一的基礎上，增加了服務端混流的技術邏輯（藍色部分）:

1) 推流端分別向伺服器集群推原始流。

2) 服務端等待所有推流端的音視頻流到達以後，開始混流。混流的工作內容同樣包括解碼，對齊畫面（音畫同步），抖動緩衝，和重新編碼。

3) 服務端把混好的單流推到CDN網路，以便拉流端拉流播放。

接著，讓我們看看在服務端混流會帶來多少額外的工作量。

在服務端混流有以下步驟：

1）推流端推流，服務端等待所有主播的音視頻流到達 2）解碼 3）混流 4）編碼 5）轉推流。

所有步驟和在推流端混流幾乎一樣，只不過工作環境不一樣。所有的步驟都是服務端額外增加的工作量。服務端混流的工作內容和推流端混流不一樣的地方在於：推流端解碼是不管混流還是不混流都要做的事情，而服務端解碼卻是因為要混流才額外做的工作。

然後，讓我們看看混流的要求和服務端的特點。混流是一個比較燒資源的事情，服務端是一個資源比較豐富的地方，這倆貌似比較般配。現在突然說要讓他們在一起，那我們還是要先給他們對一下八字。

在推流端混流的要求在上面已經分析過，這裡只討論在服務端混流的要求。

（服務端）混流的要求

1）比較好的上行網路帶寬。所有推流端推出的音視頻流在服務端集中，混流以後再轉推到CDN網路。每一個連麥直播間相對應一路混流，因此這種集中混流的方式對服務端上行網路會造成一定的壓力。

2）比較好的服務端硬體配置。這種集中混流的方式對服務端的計算資源會造成一定的壓力。

服務端的特點

1) 網路帶寬資源相對比較充足，而且支持擴展。

2) 計算資源相對比較充足，而且支持擴容。

3) 完全可控。音視頻雲服務平台可以根據網路和計算的壓力對服務端進行配置調整。

4) 可以擴容。服務端一般都會採取伺服器集群的設計方式，具有彈性，和可以擴容。對於網路帶寬和計算資源的增長需求，可以比較靈活地進行升級，甚至可以做到動態地分配。

這麼擺開來一對比，一眼就能看出這倆真的比較般配：一個喜歡買買買，一個家底豐厚。

最後，讓我們來總結一下服務端混流的優勢和劣勢。

在服務端混流的優勢

1) 低延遲

在服務端混流，天然地具有低延遲的特點。在服務端混流只需要等待所有其它主播的音視頻流到達服務端就可以開始混流；在這個基礎上，在推流端混流還要從服務端再拉流到推流端，要等待所有其它主播的音視頻流被拉下來後才可以開始混流。在服務端混流的系統設計天然地比在推流端混流減少了這一段的網路傳輸的時間。另外，服務端的計算能力和網路帶寬都是要比推流端高几個量級的，混流的過程和推流到CDN網路所耗費的時間，在服務端都會比推流端要來得少。綜合起來，服務端混流可以獲得比推流端混流低的延遲。

2) 計算資源充足

服務端的計算資源相對充足，而且可以進行擴展和調度，不會成為瓶頸。

3) 網路帶寬資源充足

服務端的網路帶寬相對充足，而且可以進行擴展和調度，不會成為瓶頸。

4) 可控可擴展

其實這是服務端最大的優勢。在服務端有著雲服務平台充沛的資源，可以進行彈性的調整和擴展，有著專業團隊專業的服務和強力的支持。這是雲服務平台的優勢；這是集團軍作戰的方式；這是靠組織打硬仗的理念。說得通俗一點，根據即構科技的經驗，1個核可以支持5路流，8個核就可以支持40路流，隨著流不斷增加，我就不斷增加CPU，無感知地增強計算能力。換成終端手機的話，是沒辦法增加CPU的，要麼換手機，要麼只能等著燒糊。

在服務端混流的劣勢

1) 成本高

在服務端混流，會讓服務端承擔了額外的計算成本和網路帶寬成本，從而推高運營成本。

2) 壓力大

在服務端混流，也叫作集中式混流。音視頻流的帶寬壓力，以及轉碼和混流的計算壓力都會彙集到服務端，天然地增加服務端的壓力。這個情況也對服務端的架構設計提出挑戰，要求服務端能夠有擴展性，能夠通過分散式和集群的方式來應對壓力。

綜上所述，服務端是一個理想的做混流的地方，它擁有低延遲和高服務品質的優勢，但是它的成本也相對比較高。它能夠滿足相當一部分發展成熟或者走精品路線的直播業務平台的業務需求。這個市場需求是主流，而且是未來的趨勢。

經過上面的論道，我們回過頭來對比在推流端混流和在服務端混流的優勢和劣勢，我們會發現這兩種方案其實各有各的優點。都代表了可觀的市場需求。在行業發展的各個階段，這兩種需求都應該得到尊重和滿足，以促進行業的健康發展和成熟。

然而，從一個中長期的視角來看，雲服務平台的優勢已經被承認和充分發展。雲服務平台的哲學就是：通過雲服務平台的資源和能力，加上專業的團隊，給業界提供高質量的專業服務。在服務廣大客戶群體的過程中，即構科技觀察到這樣的趨勢：越來越多的直播業務平台，特別是第一梯隊的平台，十分善於藉助雲服務平台的優勢來確保高質量的用戶體驗，進而快速地擴大市場份額。

好了，搞清楚江湖上各個山頭的好處和不足後，我們就可以機智地選擇在哪裡混了。總而言之，有三個地方可以混（流）：推流端，服務端和拉流端。即構科技側重考慮用戶體驗和服務質量，優先提供了服務端混流和拉流端混流兩種方案，並且會在適當的時機，根據市場需求提供推流端混流方案。