今年，最受歡迎的遊戲當屬狼人殺，據不完全統計，截止到現在已經有40多款狼人殺APP上線，熱度毫不遜於如日中天的視頻直播市場。
事實上，狼人殺與視頻直播一樣，也是高度依賴語音視頻技術的應用，但前者對產品的互動能力的要求比後者更高。語音互動是狼人殺遊戲當中的重要環節，但資深玩家肯定知道，很多排在前列的狼人殺APP即使在複盤討論等社交環節，也不能讓用戶同時發言，更不要說相互能看到視頻了，這大大影響了產品的使用者體驗。
從目前的趨勢來看，越來越多的產品開始使用多路連麥技術來解決這一問題。然而多路連麥技術仍然存在很多挑戰，例如如何解決跨網傳輸問題？如何在複雜的網路環境中降低延遲？...
雷鋒網瞭解到，即構科技為狼人殺的特定應用場景量身定做了一項名為“狼人殺蟲洞連麥技術”的語音視頻通訊雲計算服務。那麼，這一項技術的核心是什麼？解決了什麼痛點？如何進行驗證？
本期硬創公開課邀請到了即構科技市場運營總監冼牛為大家深度解讀狼人殺蟲洞連麥技術。
嘉賓介紹
冼牛，即構科技市場運營總監，資深技術人，市場行銷新兵，客串投資顧問，骨灰級游泳者。北京郵電大學電腦碩士，香港大學工商管理碩士，一直秉承人醜應該多讀書的理念，讀書不斷。2008年起旅居香港至今，2015年回流深圳南山創業，服務過愛立信香港，摩根大通香港，和分期樂集團等老東家。
2002年北郵碩士期間開始鑽研視訊會議，現深耕語音視頻雲服務，直播技術應用和直播行業研究。
以下內容整理自本期公開課，雷鋒網做了不改變願意的編輯：
顧名思義，狼人殺蟲洞連麥技術是為狼人殺應用量身定做的一款產品，連麥技術不是新鮮的技術，在2016年網路直播元年，就已經被很多一線的直播公司應用。
2017年，狼人殺引領了一波新的浪潮到來，這款應用的直播技術也因此發生了一些變化。今天主要講的是狼人殺蟲洞連麥技術的系統結構以及它能為狼人殺這種場景解決哪些痛點。
背景
我們可以從兩個維度來比較市面上的狼人殺遊戲：1）有沒有視頻；2）能不能同時說話。
從市面上主流的狼人殺遊戲的比較中可以發現，有些只支援音訊，比較少能支援視頻，有些只支援單向的語音，比較少能支援連麥互動。
參考去年直播行業的發展趨勢，請允許我斷言，今年乃至明年狼人殺會把直播行業發展成熟的語音視頻技術繼承過來，並且結合本身的應用場景，發展出更多豐富的玩法。
目前，狼人殺的產品形態主要是遊戲環節，同時在探索複盤討論環節的玩法，甚至還有才藝表演等更多的玩法。後兩種玩法包含更多的社交元素，對語音視頻互動有更高的要求。
在遊戲環節，通過單向的語音視頻通訊技術就可以實現；在社交環節，對語音視頻互動技術的要求甚高，必須要有多路連麥技術才能獲得良好的用戶體驗。
技術痛點
目前，狼人殺類APP存在以下技術痛點：延遲大、無連麥、無視頻、語音失真、卡頓不流暢、和語音有回聲等。
延遲比較大可能因為目前的狼人殺類APP主要是採用單向音視頻通訊，拉流端直接推流到CDN網路，然後拉流端直接從CDN網路拉流，一般的延遲會大於3秒。
狼人殺包含遊戲環節和討論複盤環節，甚至才藝表演等環節。在遊戲環節中，用戶輪流發言，發言之間會需要思考時間，因此還勉強可以玩，但是用戶體驗比較差。
在討論複盤環節甚至其他社交環節，用戶會同時發言，而且要求能看到其它使用者的視頻。在這種應用場景下，這麼大的延遲會成為狼人殺類APP往社交化發展的絆腳石。
另外，很多狼人殺遊戲中，卡頓不流暢，背景雜音，語音失真、回聲的問題都是普遍存在。
失真有可能是因為回聲消除和噪音抑制過度造成的。卡頓可能是因為在語音網路傳輸的過程中處理得不好，丟包或者抖動等網損都會造成的，也可能是因為終端設備解碼和播放處理不流暢而造成。
解決方案
要在語音視頻通訊中獲得超低的延遲，就要在網路中找到最短最優的傳輸路徑。
在網路中，從A點到B點最短的距離，我們借用宇宙學中的概念，把它叫做網路上的蟲洞。
狼人殺蟲洞連麥技術所做的就是通過一系列的策略和演算法優化各個環節，配以優質的網路資源，繞開網路擁塞、穿越物理距離，選擇最優網路路徑，實現超低延遲的連麥互動。
即構的狼人殺連麥解決方案可以在超低延遲和流暢的基礎上實現語音視頻連麥互動，讓身處世界不同角落的用戶，感覺就像是在面對面對話一樣玩狼人殺。回聲消除，雜訊抑制，和自動增益控制等痛點都得到有效的解決。
在圖中，左邊顯示的是即構的客戶美播直播的9路連麥的場景，最右邊是12路連麥的場景，中間是使用即構狼人殺蟲洞連麥SDK開發的貼近狼人殺應用場景的DEMO，按住按鈕就可以顯示視頻同時說話。
連麥的流程
狼人殺連麥和直播連麥的流程是類似的。圖中深藍顏色代表的是終端和業務層的邏輯，淺藍色代表的是伺服器端的邏輯。
首先是第一主播先發佈直播，把流推到伺服器，然後伺服器再流轉推到CDN，普通用戶再從CDN拉流。這一過程是單向的音視頻通訊，並沒有連麥互動的。
然後第二主播向業務伺服器申請連麥，業務伺服器再把這個請求傳遞給第一主播。通過業務伺服器，連麥雙方用信令完成了連麥的申請和應答。
兩個主播連麥時，可以相互看到對方，所以拉流和推流都必須在媒體伺服器，因為媒體伺服器網路資源更好，而對於處於觀看模式下的觀眾則可以採取低成本的方式，即從CDN拉流。
另外，從圖中可以看出，整個傳輸和處理環節可以分為三個部分：推流端、拉流端和雲端。
推流端包括採集、前處理、編碼和推流，採集是推流端的麥克風或者攝像頭採集音視頻的資料，前處理包括音訊變聲、視頻濾鏡等。推流可以推到雲端或者CDN，在雲端會做混流、轉碼工作，隨後就是分發，把流分發到CDN網路然後推到邊緣節點，讓觀眾端拉流。
拉流端和推流端的過程是相反的，拉流後進行解碼，然後做後處理、渲染。
在圖中，左邊處於連麥模式的使用者在進行連麥互動時，語音視頻、信令全部是經過媒體伺服器集群，右邊是不需要連麥的使用者，只需要從CDN網路拉流。
系統架構
連麥模式的使用者接入到連麥模式的伺服器集群，這些伺服器的計算資源和網路資源比較優質，而且在演算法策略上做了很多工作，可以獲得比較低的延遲。連麥模式的伺服器集群包括語音視訊伺服器集群，信令伺服器和調度伺服器。語音視訊伺服器集群負責語音視頻流的轉碼等處理，信令伺服器負責信令的同步和通訊，調度伺服器負責網路資源，計算資源，存儲資源，和流量等的全域調度。
中間是混流伺服器，它支援旁路混流服務，從語音視訊伺服器集群拉取多路單獨的語音視頻流，然後進行解碼，音畫同步，混流，然後在重新編碼，最後推送到CDN網路。
聆聽模式的使用者要看這些語音視頻，可以從CDN網路的邊緣節點拉流播放。混流伺服器加上CDN網路提供了旁路直播的服務，雖然一定程度犧牲了即時性，但是可以維持相對比較低的成本。
語音視頻終端
語音視頻的連麥涉及到了三部分內容：終端的處理，包括回聲消除、噪音抑制、音量自動增益這些語音前處理部分；在網路傳輸上，為了對抗網路損傷必須要配置三個模組，抖動緩衝、前向糾錯、丟幀補償；另外還需做到相容性跨平臺，安卓手機稂莠不齊，在安卓的相容性上需要花很多功夫。
語音前處理：回聲消除具有挑戰性，當兩個用戶對講的時候對技術要求很高，這需要看對講時語音的通透度，語音消除本質就是參考遠端信號把近端的回聲處理掉，處理後可能會有兩個問題，如果處理過度會造成語音失真，如果處理不夠則會導致一部分回聲沒被消除。
噪音抑制：也有同樣的要求，在沒有噪音的時候需要盡可能的把語音保護好。傳統的降噪的做法是通過分析背景雜音的強度和頻譜分佈，分析用戶的聲音的頻譜，然後根據分析的結果建模模型，構建一個濾波器；這個濾波器能區分用戶的聲音和背景雜音，把噪音頻段外的聲音予以保留，把噪音頻段內的聲音能量降低，最終的效果就是抑制了噪音，讓用戶的聲音更加清晰。
音量自動增益：主要在兩個場景中發揮作用，一是在嘈雜環境中，它能自動調整麥克風的音量，增強有效的聲音資訊；另外，如果使用者離麥克風較遠，拾音效果會調整得比較好。
自我調整複雜網路：包括三個模組：抖動緩衝、前向糾錯、和丟幀補償。網路抖動是不可避免的，抖動會導致資料的損傷，為了對抗抖動需要在演算法上做一系列的處理，及適當地增加延遲，讓抖動變得比較平緩。
前向糾錯：用空間換時間，一次傳送多個冗餘數據包，就算丟包丟到20%-30%，接收方也可以把有效資料恢復，但是資料量是變多了，占的頻寬也會更多。前向糾錯和丟幀補償一般結合起來互補使用。
丟幀補償：用時間換空間，如果傳一個資料包沒接收到，就通過一定的智慧策略來重傳，由於每次傳輸的資料不包含冗餘數據，因此占的頻寬資源比較少，然後由於可能要多次重傳，因此花費的時間也會比較多。
相容性：主要體現在安卓設備上，因為安卓手機中低端的機型很多，在聲學的設計上不太合理，揚聲器和麥克風會出現耦合，這就會導致聲學的演算法在這些設備商運行的效果不好。即構的做法是儘量調用底層C介面，而不去調用Java介面，抹平設備之間的差異，以實現相容性。
跨平臺：現在一般採用的是QT開發框架，它開發的一套代碼可以同時跑在Windows和Mac上。QT開發框架還不完美，開發出來的代碼在Mac上跑還多多少少會有些問題，需要花時間去發現和修正。
語音視頻雲端
雲端主要考慮五個要素：海量併發、全網覆蓋、熱備容災、QoE保障、擴容能力。
海量併發：要做到海量併發系統架構必須是分散式伺服器群，每一個節點能感知周圍的網路環境，把資訊上報給調度伺服器，調度伺服器對全網的網路資源，計算資源，和流量資源進統一調度和負載均衡。
全網覆蓋：採用多個核心機房覆蓋主要城市，在偏遠地區採用多節點代理，把請求轉發給核心節點處理，這樣能做到全網覆蓋。
熱備容災：採用多個公有基礎雲服務，不同的公有雲之間相互熱備容災。
QoE保障： 跨運營商網路傳輸是瓶頸，即構在所有接入點都採用BGP，確保接入的品質和不受跨網瓶頸的影響。；
無上限擴容：隨著使用者規模的增長，即構能為客戶進行無感知無上限擴容，免除擴容過程中的成本和對用戶的負面影響。
難點1：低延遲
連麥互動最基礎的需求是延遲要低。一般情況下要做到300-500ms左右，才能有好的互動體驗。
以這張圖為例，推流端在北京，拉流端有兩個用戶（一個在廣州，一個在深圳），這三個玩家在玩狼人殺遊戲的時候，音視頻的推流要傳到廣州和深圳，可能會經過武漢或者寧波。
要做到低延遲的話，首先要有好的基建，另外需要選擇最佳路徑，第三個策略就是要在每個環節（採集、前處理、編碼、推流、混流、轉碼等）做到最優。
難點2：混流
目前市面上混流的選擇有三種：一種是在推流端進行混流，第二種是在拉流端進行混流，第三種是在雲端進行混流。
推流端混流：把和推流端連麥的其它使用者的音視頻流彙集在某一個玩家手機上，在手機上進行混流再轉推到CDN上，這種成本很低。
拉流端混流：拉流端拉多流，然後進行混流，最後在終端設備進行渲染播放。
雲端混流：所有連麥使用者的音視頻流彙集到雲端，把多路音視頻流混合成一路音視頻流，然後轉推CDN網路。
雲端混流是推薦的做法，它能借用雲端的能力：穩定而且充足的網路資源，計算資源，可擴展性，和運維能力
例如上圖顯示的，三個主播向語音視訊伺服器集群推流，然後進行連麥。連麥用戶端必須從媒體伺服器拉單獨的多路流，這樣才能保證低延遲，
旁路伺服器還會從語音視訊伺服器把單流拉出去進行混流，同時保留多路流，給觀眾端保留兩個選擇，可以拉混流也可以拉多流。
如果要節省成本，就把混流轉推到CDN網路，觀眾從邊緣節點拉混流；如果要讓觀眾獲取好的體驗，也可以拉多流。
難點3：回聲消除
這張圖描述了回聲消除的基本原理。
下行信號傳過來，通過語音終端揚聲器播放，這個聲音也會被設備的麥克風採集，所以麥克風採集到的聲音包含使用者有效的語音，還包括揚聲器發出來的回聲，這時候就要把回聲和有效的語音分離。
分離的前提是要有一個參考信號——下行信號，雖然經過揚聲器播放下行信號和回聲會有差異，但二者是高度相似，簡單來說回聲和下行信號存在一個函數關係。
回聲消除的本質就是把這個函數解出來，通過AEC再把回聲消除掉。
測試方法總結
在這些技術條件都滿足後，上線之前，需要做一系列測試。
語音視頻測試的影響因素包括：
1）語音視頻參數設置
2）網路環境
3）移動終端
4）聲音環境
而具體評估指標包括：
1）延遲情況
2）卡頓情況
3）連麥路數
4）自動增益控制
5）噪音抑制
6）回聲消除
一般來說，測試方法有兩種：第一種是比較客觀的測試方法，例如使用消音室；第二種是主觀測試方法，測試人員的樣本數目要多到具有統計意義。
這兩種方法對於互聯網創業團隊的實操性不夠強。這裡推薦第三種實操性比較強的測試方法，可以由互聯網創業團隊因地制宜來操作。
1）設定不同的語音視頻設置；
2）真實網路的環境，和使用網損類比設備來類比各種網路情況；
3）跨國家地區，跨運營商網路，還有不同的接入方式；
4）各種移動終端設備，重點是安卓手機，按照出貨量排行，充分覆蓋各種安卓機型。
總的原則就是，首先要貼近用戶的場景，接著要覆蓋影響因素的組合，然後是關注核心評估指標，最後是方案必須是團隊容易實施的。
精彩問答
Q：在網路狀況比較差的情況下，有沒有比較好的降低延遲的辦法？
A：網路狀況差在傳輸層面表現出來的問題就是延遲比較大，和丟包率高。
要做低延遲的話會面臨協議上的選擇：標準RTMP協定還是UDP私有協定。無論是標準RTMP協定還是UDP私有協定，即構科技都做到了網路自我調整，實現了穩定的低延遲和流暢的效果。
RTMP的優點：標準協定，業界公開透明，更加開放、可控、和可替代；天然支援和CDN對接。
RTMP的不足：在大方面受限於網路底層的擁塞控制，在個別網路極端糟糕情況下延遲會增大；RTMP標準協議對流控等沒有端到端雙向支援，惡劣情況下效果保障會比較複雜。
使用UDP私有協議,即構實現了端到端全鏈條可控，包括流控碼控、冗餘和重傳等等，對抗惡劣網路更有保障。即構專門支援了把私有協定和格式轉換成RTMP標準協定和格式，可以轉碼推向標準CDN等協力廠商伺服器。
Q：跨地區、跨運營商如何實現？
A：要解決跨網通信的瓶頸的話，必須在接入的時候使用BGP，雖然成本會增加，但能夠有效解決跨網問題。
跨地區的話，需要設計好分散式的網路架構，用優質的節點資源去保證全面覆蓋，要有調度伺服器進行全域智慧調度。
Q：即構科技的方案最多可以支援幾個人的視頻互動？具體方案和視頻直播有什麼區別？
A：即構的狼人殺蟲洞連麥技術在移動端最多可以支援20路，在PC端最多可以支援32路，目前有客戶在用。
狼人殺技術方案和視頻直播技術方案的區別還是很多的，這裡只提一個點：狼人殺對超多路語音視頻連麥的需求會更大，12路連麥是最基本的需求，連麥互動的頻率會更加強；
而視頻直播對超多路的連麥需求不會太大。因此，即構科技在技術上會對狼人殺超多路連麥和強互動的需求作出全面的支持。
Q：音視頻編解碼這塊，即構的方案有什麼特點？
A: 音視頻的解碼器，音訊是AAC，視頻是x264。在這個基礎上我們做了兩個事情：1）音視頻轉碼器的深度優化；2）音視頻轉碼器的智慧調度策略。
（雷鋒網此前也針對
多路連麥技術
做出瞭解讀，歡迎查閱！）