連麥已經成為互動直播的基本功能，但連麥的成本較高，對業務形成比較大的壓力。北京密境和風科技有限公司iOS技術負責人唐賡在LiveVideoStack Meet上分享了花椒直播在降低連麥成本方面的一些探索，此外對連麥費用構成、降低成本可采用方案，以及實際效果進行分析。

演講 / 唐賡

整理 / LiveVideoStack

class="video_iframe" data-vidtype="2" allowfullscreen="" frameborder="0" data-ratio="1.7647058823529411" data-w="480" data-src="http://v.qq.com/iframe/player.html?vid=t0524zlq15o&width=638&height=358.875&auto=0" style="display: none; width: 638px !important; height: 358.875px !important;" width="638" height="358.875" data-vh="358.875" data-vw="638" src="http://v.qq.com/iframe/player.html?vid=t0524zlq15o&width=638&height=358.875&auto=0"/>

我將從以下五部分分享我們在連麥成本控制方面的嘗試和經驗：連麥接入方案、費用構成分析、嘗試方案、實現過程中存在的問題以及實際效果分析。

連麥接入方案

上圖是最常見的單向直播架構，左側主播端將直播流推到源站，源站再通過CDN分發到邊緣節點，所有客戶端則是從這些邊緣節點拉取數據，這是最普通的方案。單向直播對技術的要求相對較低，它對延遲、實時性沒有過高的需求，但是對CDN的要求會相對高一些，來保證直播的連通性和覆蓋率。

但是對連麥的接入方案而言，連麥本身對實時性是有較高要求，當然這個要求主要是針對連麥的主播之間的，因此連麥服務商都會有連麥服務器來保證主播之間實時互動的連通性和實時性，連麥服務使用的肯定是核心服務器，那么相對而言成本也會高很多。而對于普通的觀眾端則依舊是從CDN邊緣節點拉流觀看直播。

但是這個架構我們在實際應用過程中遇到了很多問題：首先就是開播之前必須選擇是否使用連麥，這決定了主播推送的流是否要接入連麥服務器，因為連麥成本(單價)是普通直播的20倍、甚至40倍，而有的主播雖然在開播前選擇連麥，但在直播過程中卻并沒有用到，這無形之中就極大增加了直播成本。也正是因為如此，給所有主播都開啟連麥是不可能的，而且也僅僅有小部分主播需要使用到連麥功能。而另一個問題則是在直播過程中突然有連麥需求怎么辦？下播重新推流顯然是不現實的，一方面會影響觀看體驗，一方面也很難再次聚集人氣。此外伴隨直播玩法的更新，象主播間的連麥PK、多個直播間合并這樣的需求也在不斷增加，如何支持這些需求，這就需要對直播架構進行重新設計。

連麥成本構成分析

連麥成本首先是連麥服務費，它的計算方式分為按照房間數*時長計算和按流量計算兩種，無論用哪種方式計算，通常價格都是普通CDN的20倍、甚至40倍以上。費用構成的第二部分就是中間CDN費用，這部分又會有兩種方案：一種是直接使用連麥服務廠商提供的SDK中的CDN解決方案，一種是自建或單獨購置CDN，兩種方案相較而言可能第二種方式在費用上會更合適些。此外還可能會產生的成本就是合流費用，這部分費用產生的原因是連麥會產生多個窗口，假如采用拉取多路流再在客戶端拼合成需要的布局，一個因為手機和各客戶端本身分辨率有差異，另外為保持所有客戶端獲取一致體驗需要手機端代碼來保證播放同步，這在實現過程中會遇到很多麻煩，因此我們采用將多個流合流為一路推送到客戶端，目前幾大連麥服務廠商都提供了合流服務，但同時在費用上它甚至比連麥服務還要再貴幾倍。因此我們使用FFmpeg自己開發了一套實現方案。

降低成本的實現&遇到的問題

上圖是我們改進后的架構，主播在正常開播時依舊是采用傳統的單向直播方案，直播流會走綠色的線推給源站進行推流，而連麥服務初始狀態是隱藏的，一旦有需求，主播只要同意連麥請求就會自動切換到連麥服務器上，再推給源站推流。

• 老版本兼容問題

但在實現過程中我們也遇到了一些問題：首先是版本問題，如果要實現這樣一個架構，我們就必須通過IM通道通知所有客戶端流流名變更、流服務器地址變更，然后手機就會立刻從新的地址拉流，但老版本并不支持這個協議。此外還有H5和PC Web的問題。

這張圖是我們針對老版本兼容改進的架構，當主播切換到連麥后原本推流的綠色虛線就會消失，改由連麥服務器按照原來的流名繼續推流到源站，這樣就可以保證老版本客戶端能夠源源不斷看到直播內容，而新客戶端也可以正常拉取到新的流。這里需要注意的一點，為了保證老版本客戶端收到的內容也是新的畫面，就需要連麥服務器在原來流名推的是合流之后的流。

• 推流保護機制

但在我們實現過程中發現這條路走不通，因為CDN廠商有一套推流保護機制來防止流被別人惡意劫持， 它會記住上一次推流到這個流名的IP，并且在一定時間內不允許更換IP，或者需要特殊的API調用去通知它IP更換。因此這個問題只能通過和CDN廠商協商來解決了。

• 推流參數變更

推流參數變更也是我們遇到的坑，原本的推流是由手機端直接推的，而手機的推流參數與連麥服務器和合流務器輸出的參數是不一樣的，這就可能會出現沒有聲音、直播畫面出現異常等等各種問題。對于這個問題，我們也是和推流中所有環節的廠商——包括連麥服務商和各家CDN廠商規定了一套推流參數規則來解決這個問題。當然這些服務商也并非只有我們一家，因此他們在對我們參數適配的同時也還要兼顧其他客戶的正常使用，所以測試、發布的過程也是非常謹慎小心的。

• 新增CDN廠商不兼容

在規定推流參數的同時又衍生出了一個新的問題，就是新增CDN廠商的不兼容。我們的推流參數不是固定不變的，因為在手機端推流時，分辨率、碼率、幀率都會根據當前網絡帶寬、手機CPU消耗等因素做動態調整，因此我也只能要求新增的CDN廠商按照我們的規范支持分辨率、碼率的動態調整。

除此之外還會有一些其他的坑，比如我們自身用了很多私有協議，而廠商可能用的是公有協議，那么在對接時協議之間又會有很多不兼容，需要做適配轉換。

實際效果分析

在經歷一系列的問題改進，最終能達到的效果基本可以歸納為4點。首先對于主播而言，他可以隨時進行連麥，不需要在開播前就必須做出選擇。第二點我們實現了多個直播間合并直播，并且加入了一些設計：當多個主播連麥時，直播間觀眾看到的主播位置排序一定是當前主播在第一位，這個在實現過程中需要注意給到合流服務器的所有排列組合信息是正確的；在合并直播的基礎上我們也做了主播才藝的PK。此外實現了老版本的平滑過渡。當然最大的好處就是成本降低，主播只有在有連麥需求的時候才會自動切換到連麥服務器，而我們也設定了一個時間域值，當主播一定時間不連麥后我們會自動切回普通直播，這樣就比較明顯的減少了連麥成本。

以上是我們嘗試的新的直播架構，以及實現過程中遇到的問題和解決思路，謝謝大家。

LiveVideoStack招募全職技術編輯和社區編輯

LiveVideoStack是專注在音視頻、多媒體開發的技術社區，通過傳播最新技術探索與應用實踐，幫助技術人員成長，解決企業應用場景中的技術難題。如果你有意為音視頻、多媒體開發領域發展做出貢獻，歡迎成為LiveVideoStack社區編輯的一員。你可以翻譯、投稿、采訪、提供內容線索等。

通過contribute@livevideostack.com聯系，或在LiveVideoStack公眾號回復『技術編輯』或『社區編輯』了解詳情。

總結

以上是生活随笔為你收集整理的你还在为20倍的连麦成本发愁吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。