2
雷鋒網按：本文作者冼牛，即構科技市場運營總監(jiān)，香港大學MBA，十年研發(fā)經驗，音視頻云服務技術專家，專注連麥互動直播技術應用研究。 本文是連麥互動背后的混流方案系列的第二篇，接著上一篇：《聊一聊直播利器，連麥互動背后的混流方案》談要不要混流，來談談如何混？在哪里混？
借《無間道》中曾志偉黑老大的名言作為開場白：出來混，遲早是要還的。
雖然話這么說，但是在哪混，跟對了老大，命運際遇就會大不相同。在連麥互動直播中，在哪混（流），同樣很重要，做對了選擇，用戶體驗就會大不相同。
在上一篇《混流 vs 不混流》發(fā)了之后，很多朋友找到我說：很喜歡這一類技術干貨，鼓勵繼續(xù)寫下去，但是：1）多配點圖，沒圖的文章基本看不下去，就像沒手機吃不下飯。2）不要太長，不求能在衛(wèi)生間里看完，但求能在上下班路上看完。3）多說人話，少說碼農語言，因為老板不編碼好多年了。
雖然心里想著：臣妾做不到......，但是一說出口就變成：這個可以有！
閑話少說，容我開篇論道。
在決定在哪混之前，讓我們先搞清楚可以在哪里混。
上一篇我們討論要不要混流，這一篇我們將討論在哪里混流。
圖一 連麥互動直播方案系統(tǒng)拓撲圖
圖一是目前業(yè)界主流的連麥互動直播方案系統(tǒng)拓撲圖。
拓撲圖里包含以下實體：
1) 推流端（主播端）：主播的工作環(huán)境，包括手機硬件配置和網絡環(huán)境。手機的計算能力和上行網絡往往會成為連麥互動直播的瓶頸。
2) 服務端（服務器集群）：龐大而復雜的服務器集群，實現(xiàn)音視頻云端的調度和計算能力。具體會包括信令服務器，媒體服務器集群，混流調度中心和混流服務器集群等。
3) CDN網絡：第三方獨立的公共服務網絡，提供緩沖，存儲和轉發(fā)的能力。
4) 拉流端（觀眾端）：觀眾觀看直播的環(huán)境，包括手機硬件配置和網絡環(huán)境。拉流端一般來說是從CDN拉流，而不會參與連麥互動，手機的計算能力和下行網絡不會成為直播的瓶頸。
拓撲圖中的實體之間的活動包含：
1) 推流：推流端把原始音視頻流推到媒體服務器集群。
2) 拉流：分為兩種情形：推流端從服務器集群拉取其它主播的音視頻流；拉流端從CDN網絡邊緣節(jié)點拉取音視頻流播放，可以是單流或者多流。
3) 轉推CDN：分兩種情形：如果在服務端混流，服務器集群會把一路混好的音視頻流推到CDN網絡；如果在推流端混流，推流端會把一路混好的音視頻流推到CDN網絡。
搞清楚江湖上有哪些山頭后，我們就可以明智地選擇在哪里混了。
首先，排除CDN網絡，因為它是第三方服務，在連麥互動直播云服務平臺的掌控之外。
接著，在拉流端混流其實就是上一篇中提到的不混流方案。拉流端拉多流，在播放的時候根據業(yè)務側的需求，對多路流進行靈活操控。拉流端混流方案的優(yōu)勢是高度靈活易于操控，劣勢是網絡帶寬成本相對比較高。因為已經在上一篇深入討論過，所以這里不再展開討論。
最后剩下的選擇，是推流端和服務端：推流端使用了音視頻云服務的SDK，服務端是提供音視頻云服務的服務器集群，兩者都是可以做混流的地方。
決定在哪混？
我們現(xiàn)在要決定在哪混，擺在面前有兩個選擇：推流端 vs 服務端。
我們要搞清楚在推流端混流和在服務端混流的優(yōu)勢和劣勢，才能作出明智的選擇。
如果要搞清楚在推流端混流的優(yōu)勢和劣勢，那么得先搞明白在推流端混流的技術邏輯。
圖二 推流端混流技術邏輯圖
圖二是在圖一的基礎上，增加了推流端混流的技術邏輯（藍色部分）:
1) 推流端向服務器集群推原始音視頻流。
2) 推流端從服務端拉取其它推流端推上去的音視頻流?；炝鲗⒃诘谝恢鞑サ耐屏鞫诉M行。第一主播要等到其它所有主播的音視頻流到達以后才能開始混流。
3) 推流端進行混流的工作內容包括解碼，對齊畫面（音畫同步），抖動緩沖，和重新編碼。
4) 推流端（第一主播）把混好的單流推到CDN網絡，以便拉流端拉流播放。
接著，讓我們看看在推流端混流會帶來多少額外的工作量。
在推流端混流有以下步驟：
1) 推流端拉流，等待其它主播的音視頻流到達、2) 解碼、 3) 混流、4) 編碼、5) 轉推流。
其中第1步至第2步是推流端在不混流的情況下也必須要做的事情，第3步至第5步是在要混流的情況下額外增加的工作。兩路流混成一路流的工作量大概是解碼一路流的一半不到，解碼一路流的工作量大概是編碼一路流的一半。然而，要考慮隨著混流數(shù)目的增加，混流的工作量也會相應增加。
然后，讓我們看看混流的要求和推流端的特點?；炝魇且粋€比較燒資源的事情，推流端是一個比較缺資源的地方，這倆天生八字不合。現(xiàn)在突然說要讓它們在一起，那我們就要先研究一下它們的要求和特點。
（推流端）混流的要求
1) 比較好的上行網絡帶寬，因為推流端（第一主播）要推原始流和混流兩路流。另外，網絡要保持相對穩(wěn)定，因為混流過程中的抖動緩沖將會由于網絡不穩(wěn)定而加長，從而增加延遲。
2) 比較好的手機硬件配置，因為要對多路音視頻流進行轉碼和混流，比較耗費計算資源。如果需要轉碼的音視頻流的碼率總和比較高的話，某些采用軟編的安卓平臺可能會出現(xiàn)手機太燙，從而導致攝像頭采集的時候丟幀的現(xiàn)象。
推流端的特點
1) 主播的網絡環(huán)境可能是家庭寬帶或者4G。下行帶寬大概100M bps, 上行帶寬大概1M bps。家庭寬帶的穩(wěn)定性和網速會隨著繁忙時段而變化。這個在我國生活的人們都懂的。
2) 主播的直播終端是主播個人的智能手機。目前主流的手機配置是四核，可以進行連麥互動直播。然而，手機硬件配置終究難以和PC相提并論，更不要說和服務器相比了。
3) 不可控。直播業(yè)務平臺或者直播云服務平臺都無法掌控推流端的手機配置和網絡環(huán)境。傳統(tǒng)的秀場直播平臺或者和傳統(tǒng)媒體結合的直播平臺會給主播提供直播間，擁有比較好硬件配置和網絡環(huán)境。其它娛樂直播平臺的主播一般都是使用個人手機和家庭寬帶進行直播的。
這么擺開來一對比，一眼就能看出這倆真是八字不合：一個處女座，一個不給力。
最后，讓我們來總結一下推流端混流的優(yōu)勢和劣勢。
1) 成本低
整體來說，推流端混流是一個低成本的方案。它在兩個方面降低成本：計算資源和網絡帶寬。本質上，在推流端混流就是服務端把混流的成本轉嫁給推流端。服務端的計算資源和網絡帶寬都相對比較昂貴，而推流端的計算資源和網絡帶寬都是沉著成本。如果在推流端做混流，就降低了服務端的成本，充分利用了推流端能共享的資源。
2) 服務端壓力小
在服務端混流是相對來說是集中的模式，這樣會增加服務端的壓力。在推流端混流是完全分布式的模式，這樣可以降低服務端的壓力。
3) 本地輸出混流后的數(shù)據
在推流端混流以后將會輸出混流后的音視頻流，這樣方便本地進行錄制，或者直接把音視頻流推到CDN網絡進行分發(fā)。
在推流端混流的劣勢
1) 增加額外延遲
首先，在推流端進行混流會增加額外的延遲，主要是因為要等待所有其它推流端的音視頻流到達，才能開始混流。從圖二我們可以看到，在服務端混流，只要所有主播的音視頻流到達服務端，就可以開始混流；在推流端混流，要在前者的基礎上，其它所有推流端的音視頻流再被拉流到推流端，才能開始混流。這是額外的時間開銷。其次，推流端混流完畢以后推流到CDN網絡的延遲也相對較大，因為推流端的硬件配置和上行帶寬質量都無法和服務端相比。最后，考慮到推流端種種不穩(wěn)定的情況，額外的延遲只會增多而不會減少。
2) 手機硬件配置瓶頸
在推流端進行混流要求比較好的手機硬件配置。一般來說，目前主流的四核手機能滿足連麥互動直播的要求。然而，如果算上混流的工作量，手機的硬件配置將會成為瓶頸。比如說，如果安卓手機采用軟編，并且需要混的音視頻流的數(shù)目比較多的話，手機會因為計算量較大而發(fā)熱，很可能會導致攝像頭（離CPU比較近）采集視頻的時候出現(xiàn)丟幀的現(xiàn)象。
3) 上行網絡帶寬瓶頸
在推流端進行混流要求比較好的上行網絡帶寬。如果下行網絡帶寬是100M bps，那么上行網絡帶寬相對應一般是1M bps，好一點的會到4M bps。根據即構科技的經驗，音視頻流平均的碼率是800k bps。推流端將會推兩路流：原始的音視頻流和混流后的音視頻流，因此總共推流的碼率大概是1.6M bps。再考慮到網絡帶寬在上網人數(shù)較多的時間段會打折扣，和網絡不穩(wěn)定等情況，推流端的上行網絡帶寬往往是不能夠滿足推流端混流的要求的。
4) 推流端環(huán)境不可控
綜合上面第二和第三點，推流端的環(huán)境是不可控的。直播業(yè)務平臺或者直播云服務平臺都沒辦法管控推流端的硬件配置，使用習慣，網絡信號和網絡帶寬等因素。因此，在推流端做混流的效果也是不可控的。
5) 難以擴展
在音視頻云服務方案設計階段，我們預期方案是易于擴展的。隨著直播業(yè)務平臺的發(fā)展，對推流端的計算能力和網絡帶寬都將會有升級的要求。然而，推流端的環(huán)境是不可控的，而且也是難以擴展的。相對而言，在服務端做推流，如果要增加服務端的CPU或者增加網絡帶寬，都是在音視頻云服務平臺掌控范圍以內的事情。
綜上所述，推流端不是一個理想的做混流的地方，但是它提供了一個低成本的混流方案。推流端混流能夠滿足相當一部分直播業(yè)務平臺的某個發(fā)展階段的業(yè)務需求。這個市場需求是應該被充分發(fā)掘和滿足的。
如果要搞清楚在服務端混流的優(yōu)勢和劣勢，那么得先搞明白在服務端混流的技術邏輯。
圖三 服務端混流技術邏輯圖
圖三是在圖一的基礎上，增加了服務端混流的技術邏輯（藍色部分）:
1) 推流端分別向服務器集群推原始流。
2) 服務端等待所有推流端的音視頻流到達以后，開始混流?；炝鞯墓ぷ鲀热萃瑯影ń獯a，對齊畫面（音畫同步），抖動緩沖，和重新編碼。
3) 服務端把混好的單流推到CDN網絡，以便拉流端拉流播放。
接著，讓我們看看在服務端混流會帶來多少額外的工作量。
在服務端混流有以下步驟：
1）推流端推流，服務端等待所有主播的音視頻流到達 2）解碼 3）混流 4）編碼 5）轉推流。
所有步驟和在推流端混流幾乎一樣，只不過工作環(huán)境不一樣。所有的步驟都是服務端額外增加的工作量。服務端混流的工作內容和推流端混流不一樣的地方在于：推流端解碼是不管混流還是不混流都要做的事情，而服務端解碼卻是因為要混流才額外做的工作。
然后，讓我們看看混流的要求和服務端的特點。混流是一個比較燒資源的事情，服務端是一個資源比較豐富的地方，這倆貌似比較般配?，F(xiàn)在突然說要讓他們在一起，那我們還是要先給他們對一下八字。
在推流端混流的要求在上面已經分析過，這里只討論在服務端混流的要求。
（服務端）混流的要求
1）比較好的上行網絡帶寬。所有推流端推出的音視頻流在服務端集中，混流以后再轉推到CDN網絡。每一個連麥直播間相對應一路混流，因此這種集中混流的方式對服務端上行網絡會造成一定的壓力。
2）比較好的服務端硬件配置。這種集中混流的方式對服務端的計算資源會造成一定的壓力。
服務端的特點
1) 網絡帶寬資源相對比較充足，而且支持擴展。
2) 計算資源相對比較充足，而且支持擴容。
3) 完全可控。音視頻云服務平臺可以根據網絡和計算的壓力對服務端進行配置調整。
4) 可以擴容。服務端一般都會采取服務器集群的設計方式，具有彈性，和可以擴容。對于網絡帶寬和計算資源的增長需求，可以比較靈活地進行升級，甚至可以做到動態(tài)地分配。
這么擺開來一對比，一眼就能看出這倆真的比較般配：一個喜歡買買買，一個家底豐厚。
最后，讓我們來總結一下服務端混流的優(yōu)勢和劣勢。
在服務端混流的優(yōu)勢
1) 低延遲
在服務端混流，天然地具有低延遲的特點。在服務端混流只需要等待所有其它主播的音視頻流到達服務端就可以開始混流；在這個基礎上，在推流端混流還要從服務端再拉流到推流端，要等待所有其它主播的音視頻流被拉下來后才可以開始混流。在服務端混流的系統(tǒng)設計天然地比在推流端混流減少了這一段的網絡傳輸?shù)臅r間。另外，服務端的計算能力和網絡帶寬都是要比推流端高幾個量級的，混流的過程和推流到CDN網絡所耗費的時間，在服務端都會比推流端要來得少。綜合起來，服務端混流可以獲得比推流端混流低的延遲。
2) 計算資源充足
服務端的計算資源相對充足，而且可以進行擴展和調度，不會成為瓶頸。
3) 網絡帶寬資源充足
服務端的網絡帶寬相對充足，而且可以進行擴展和調度，不會成為瓶頸。
4) 可控可擴展
其實這是服務端最大的優(yōu)勢。在服務端有著云服務平臺充沛的資源，可以進行彈性的調整和擴展，有著專業(yè)團隊專業(yè)的服務和強力的支持。這是云服務平臺的優(yōu)勢；這是集團軍作戰(zhàn)的方式；這是靠組織打硬仗的理念。說得通俗一點，根據即構科技的經驗，1個核可以支持5路流，8個核就可以支持40路流，隨著流不斷增加，我就不斷增加CPU，無感知地增強計算能力。換成終端手機的話，是沒辦法增加CPU的，要么換手機，要么只能等著燒糊。
在服務端混流的劣勢
1) 成本高
在服務端混流，會讓服務端承擔了額外的計算成本和網絡帶寬成本，從而推高運營成本。
2) 壓力大
在服務端混流，也叫作集中式混流。音視頻流的帶寬壓力，以及轉碼和混流的計算壓力都會匯集到服務端，天然地增加服務端的壓力。這個情況也對服務端的架構設計提出挑戰(zhàn)，要求服務端能夠有擴展性，能夠通過分布式和集群的方式來應對壓力。
綜上所述，服務端是一個理想的做混流的地方，它擁有低延遲和高服務品質的優(yōu)勢，但是它的成本也相對比較高。它能夠滿足相當一部分發(fā)展成熟或者走精品路線的直播業(yè)務平臺的業(yè)務需求。這個市場需求是主流，而且是未來的趨勢。
經過上面的論道，我們回過頭來對比在推流端混流和在服務端混流的優(yōu)勢和劣勢，我們會發(fā)現(xiàn)這兩種方案其實各有各的優(yōu)點。都代表了可觀的市場需求。在行業(yè)發(fā)展的各個階段，這兩種需求都應該得到尊重和滿足，以促進行業(yè)的健康發(fā)展和成熟。
然而，從一個中長期的視角來看，云服務平臺的優(yōu)勢已經被承認和充分發(fā)展。云服務平臺的哲學就是：通過云服務平臺的資源和能力，加上專業(yè)的團隊，給業(yè)界提供高質量的專業(yè)服務。在服務廣大客戶群體的過程中，即構科技觀察到這樣的趨勢：越來越多的直播業(yè)務平臺，特別是第一梯隊的平臺，十分善于借助云服務平臺的優(yōu)勢來確保高質量的用戶體驗，進而快速地擴大市場份額。
好了，搞清楚江湖上各個山頭的好處和不足后，我們就可以機智地選擇在哪里混了?？偠灾?，有三個地方可以混（流）：推流端，服務端和拉流端。即構科技側重考慮用戶體驗和服務質量，優(yōu)先提供了服務端混流和拉流端混流兩種方案，并且會在適當?shù)臅r機，根據市場需求提供推流端混流方案。
最后，回應一下讀者的吐槽：為毛你的文章看起來那么像編程語言，那么對稱和結構化？
我的回答：你說呢？這些文章都是我把即構團隊的源代碼，經過Google Translate翻譯成中文以后，再加以人肉潤色而成的。技術背景的同學請自行體會一下。
這一篇討論完了推流端和服務端混流的故事，下面還會繼續(xù)分享即構科技的技術經驗，一篇一個技術點。請繼續(xù)關注即構科技技術干貨分享系列，歡迎交流，拍磚請輕。
雷峰網原創(chuàng)文章，未經授權禁止轉載。詳情見轉載須知。
