解析騰訊雲遊戲多媒體引擎GME技術方案

在網絡遊戲中，不管是大逃殺、棋牌類、電子競技類仍是娛樂休閒類小遊戲，玩家和玩家之間的互動和語音聊天都是一個必不可少的環節。做爲一個通用的技術需求，若是由遊戲廠商本身從零開始研發相應的音頻技術，既不經濟也不具有技術優點，所以市面上有一些廠商提供第三方的遊戲音頻SDK，讓遊戲開發商免於重複造輪子的同時，能把更多時間花在提高核心競爭力上。

GME遊戲多媒體引擎由騰訊多媒體實驗室（即原音視頻實驗室）提供基礎技術方案。騰訊多媒體實驗室前身是QQ音視頻團隊，依託QQ的海量用戶平臺，在音視頻網絡通訊、音視頻直播、圖像處理和音視頻處理等技術領域積累了十幾年的技術和實戰經驗。「騰訊雲大學」邀請騰訊雲GME專家工程師 王文濤老師 分享關於「騰訊雲GME技術方案介紹」課程的內容。

GME遊戲多媒體引擎，主要由實時語音，離線語音與語音分析三大功能模塊組成。

1. 實時語音主要解決遊戲中兩位或多位玩家可以在遊戲內經過語音進行溝通的問題。GME的實時語音功能針對不一樣的遊戲類型或者遊戲場景有不一樣的優化：對於時效性要求比較高的遊戲好比FPS類遊戲，GME提供低延遲的普通音質；對於K歌類遊戲，則支持高保真的語音音質；此外對於相似國戰等遊戲場景則提供十萬人超大語音房間知足遊戲的語音溝通需求。
2. 離線語音實現相似微信的語音消息功能，爲遊戲玩家提供了異步化的消息溝通方式。同時，還支持語音轉文字功能，並支持多達120種語言。
3. 語音分析功能，主要爲遊戲開發者和遊戲運營方提供各類不良信息的篩選和過濾，維護遊戲內生態良性發展。

此外GME還提供一些特點功能，包括：趣味變聲、K歌伴奏和3D方位語音。

GME 實時語音提供超低時延、流暢優先的實時語音對講，適合MOBA中游戲的語音開黑。GME提供的高清音質實時語音，則很適合語音直播類App；此外，GME提供的混音伴奏功能，爲線上卡拉OK功能提供了很好的支持；3D語音特效也支持棋牌類遊戲，狼人殺以及大逃殺類遊戲中聽音辨位的能力。

接下來咱們將詳細介紹一下游戲實時語音引擎。在介紹遊戲實時音頻引擎以前，先簡單介紹一下數字信號是如何傳輸的。

如圖中的數字傳輸系統模型所示：信源，對咱們來講即麥克風採集到聲源數據，通常這裏會轉換爲數字信號，接下來通過編碼，再通過調製解調經過網絡傳輸到對端，再經過解碼後，投遞到信宿，就經過揚聲器或者耳機等設備將聲音渲染出來。幾乎全部的音頻傳輸系統都是基於這個模型進行，包括咱們將要介紹的遊戲實時音頻傳輸引擎。

這其中有個很是重要的編碼環節。編碼的目的在於減小傳輸碼率和存儲量，以提升傳輸和存儲的效率，同時能夠在進行編碼的同時結合一些音頻處理的能力。咱們舉個例子：1分鐘，採樣頻率爲44100Hz,採樣深度爲16bits,雙聲音Wav文件大小：60*44100*2*2約10M的數據，通過Mp3 128kbps壓縮後：128*60/8=約0.94M,壓縮後只有原來10分之一不到。

這裏又區分爲信源編碼和信道編碼。信源編碼，主要解決有效性問題，經過對信源的壓縮、擾動和加密等一系列處理，力求用最少的碼率傳遞最大的信息量，使得信號更易傳輸和存儲。

信道編碼，主要解決可靠性問題，即儘可能使得處理過的音頻信號在傳輸過程當中不出錯或者少出錯，甚至能對出錯進行檢測和糾正。

在信源編碼中又能夠細分爲語音或者人聲編碼，以及音頻或者音樂編碼。二者針對的分別是人類的兩個聲音器官即嘴和耳朵，分別對應發音模型與聽覺模型進行編碼設計。語音編碼包括Speex、ISAC以及Silk編碼，而音頻編碼常見的有Celt和AAC等。

信道編碼也比較多：好比線性分組碼，卷積碼，Turbo碼，LDPC碼以及RS編碼等。並且信道編碼不僅是應用到音頻數據傳輸，其餘類型的數據傳輸也是能夠應用到。

實時音頻引擎就是在數字傳輸系統的模型基礎上，使用以前提到的音頻編碼以及音頻的特別處理過程構建起來的。實時語音引擎的主要目的是採集發送端用戶的音頻輸入，通過處理和編碼後經過網絡傳遞到接送端，並對音頻數據進行還原，最終經過揚聲器等設備播放出來。

因此通常的語音引擎的通常架構如圖所示：經過麥克風等音頻採集設備，將聲音等模擬信號採集成數字信號；同時，在遊戲或者k歌中，咱們可能還須要將本地的一些媒體文件與上述用戶聲音進行混音後進行網絡傳輸，爲了能將音頻數據傳輸到對端，須要進行音頻編碼；端接收到數據以後將對數據進行還原，並經過外放設備進行播放，就完成了整個語音引擎的處理流程。

遊戲實時音頻須要解決實際應用場景如下幾個問題。

首先，回聲消除問題，在遊戲實時語音過程當中，特別是手機場景下，手機的麥克風和揚聲器距離較近，致使麥克風不只採集到近端玩家說話的聲音，也同時採集到手機揚聲器播放出來的其餘玩家的語音，以及遊戲自身的背景音樂等聲音。這裏，麥克採集到揚聲器播放的聲音稱爲回聲。實時語音通話時，須要消除這種回聲，保留純淨的近端講話人語音，而後傳送到對端。對一個至少混合了兩個聲音的聲音流，要把它們各自分開，而後去掉其中一個聲音（回聲），難度何其之大。就像一瓶藍墨水和一瓶紅墨水倒在一塊兒，而後須要把紅墨水提取出來同樣，因此回聲消除被認爲是音頻處理中最難的技術之一。

其次，噪聲抑制問題也是遊戲語音引擎須要解決的一大難題。通常傳統社交語音類app通話場景中，通話者通常會選擇相對安靜的場所，說話也相對比較正式和清晰。而遊戲開黑時，玩家所處在商場、大街和地鐵等各類嘈雜的環境都有。而且，玩家在玩遊戲時說話聊天聲音比較隨意。此外，雙手操做遊戲過程當中，也容易堵住手機上下端的麥克風拾音孔，遊戲過程當中遊戲自己也伴隨背景音效，各類緣由致使手機麥克採集到的語音信噪比（近端採集信號和噪聲信號能量之比）會很低。所以，要保證遊戲語音通話清晰流暢度，遊戲場景中的實時語音通話，比通常常規網絡社交軟件語音通話對於語音引擎具備更高的要求。

再次，還有嘯叫問題，咱們通常都會對採集到的、比較小的聲音作增益處理。若是聲音播放端與採集端物理距離比較接近，播放出的聲音又被採集進音頻信道，進而一併作放大處理，就造成正反饋效應，會聽到聲音越變越大、越變越尖銳。

此外，爲了能更好的對用戶的聲音進行增益處理以及編碼，減小沒必要要的數據傳輸，咱們只對講話時進行採集，這就須要檢測人聲，進而引入人聲檢測功能。

以上是遊戲實時前端的狀況，接下來介紹一下後臺。

遊戲實時音頻引擎的後臺須要能支持鑑權，轉包，流控，轉碼以及統計等功能。針對大規模音頻服務的後臺，還須要能支持高併發，低延遲，以及服務的健壯性，彈性可伸縮安全性等。同時爲了知足國內外客戶的需求，須要能有全球鏈路保證全部用戶都能就近接入。

對於一個遊戲實時音頻來講，評判其好壞的質量指標包括：音質、延時、碼率、頻譜、性能和網絡抗性。音質通常分爲主觀評測和客觀評測，客觀評測可使用音質測試的專業設備測試端到端音質，並進行打分。使用音質測試設備測試端到端延時，延時越小越好。

GME的總體結構和應用如圖所示。GME做爲一個總體，由客戶端的SDK以及對應的語音後臺，存儲後臺以及識別後臺等構成。

GME實施遊戲音頻引擎的流程：

1. 採集播放：聲音信號從麥克風採集、模擬放大、ADC變換獲得數字信號進入語音前處理環節。

2. 音頻處理：其中包含了回聲消除、噪聲抑制、音量自動調節、嘯叫抑制等等，混音模塊混入伴奏 。

3. 進行音頻編碼以及信道編碼，包括包頭和FEC編碼，主要解決網絡抗抖動抗丟包處理。

4. 經過網絡接口發送數據。

5. 接收端從網絡層收到數據包，按用戶id分流爲多路不一樣的數據流，每條數據流都有解碼鏈來處理（包含FEC解碼、包頭解碼、Jitter緩存區中緩存）。

6. 外放設備播放解碼後的PCM音頻流

7. 爲了作回聲抑制，會有一路解碼數據從播放端傳遞到回聲抑制模塊，爲回聲抑制模塊提供參考信號。

從上述介紹中咱們能夠看到，針對回聲消除算法模塊須要得到音頻渲染端的一個參考信號做爲基準。而在實際處理工做有不少工程類問題須要解決：好比在回聲消除算法在處理語音信號過程當中，面對現網中各類各樣手機機型，手機硬件差別較大，特別是有些手機採集語音非線性失真大，且硬件處理效果不佳。即便是硬件較好的手機，在網絡不穩定或自己系統CPU資源被其它線程佔用時，也會致使採集和播放之間會產生相對延時變化等狀況。這些都會形成回聲消除算法中線性自適應濾波器的發散，致使通過線性濾波後回聲殘餘依舊很大。

而GME中的回聲消除算法模塊經過大量驗證數據，自適應地解決回聲消除線性處理部分，改進了殘餘回聲估計，同時對延時跟蹤，雙端檢測，近端語音存在機率方面作了從新精心打磨。在遊戲背景音回聲大、手機採集線性失真嚴重、延時抖動等常見的惡劣場景，緩解了回聲殘餘的問題，且保持良好的近端語音通話質量。其餘諸如人聲檢測，嘯叫抑制，噪聲抑制等方面，GME提供了基於傳統的和基於場景的深度學習算法來解決上述問題。

在網絡傳輸階段，主要須要解決抗抖動，抗丟包等問題。抗丟包，主要是自適應重傳策略，或者冗餘編碼等方式解決。控制播放延時，經過拉昇、加速算法來趨近於目標網絡抖動延時，處理過程當中不丟棄數據包，減小語音卡頓(整個過程要儘可能確保有數據播放)，解決抗抖動問題。這須要大量的測試得到對應的算法參數，而GME也利用了網絡實驗室的損傷儀，網絡模擬器等硬件設備，針對不一樣場景得到算法參數，並在諸如QQ等騰訊系產品上進行大規模驗證。

GME的實時音視頻後臺大致上分爲三個模塊：接入層，控制層和數據層。

接入層主要負責對接不一樣的類型的客戶端設備，並對接入客戶鏈接作負載均衡，以及做爲安全門戶等做用。控制層則主要提供控制信令，包括轉包，策略，配置以及統計計費等。而數據層則主要對音頻數據進行處理，包括傳輸或者代理用戶的音頻數據，並作轉碼，掃描等。

特別說明一下，這裏有H5的接入，由於瀏覽器的一些能力限制，能支持的RTC功能相對能力較弱，爲了能瀏覽器接入實時語音，同時又不對既有的後臺架構作重大調整和適配，因此咱們將部分功能移到後臺來實現，至關於後臺有一個瀏覽器的代理，接入GME的實時音頻後臺，進而完成對h5瀏覽器的實時語音支持。

以前提到了實時語音對延遲要求很高，而騰訊雲基礎網絡設置也很好的支持GME的能力，包括基礎設施、網絡接入和服務承載方面。

爲了保證服務質量，GME後臺也支持實時用戶數據監控，保證對突發問題能及時預警或者對資源進行自動擴容。

GME構建了一整套質量測試平臺，進而對音頻質量以及穩定性作出持續的監控。使用思博倫POLQA音質測試設備測試端到端音質。使用全頻帶音樂樣本做爲數據，和Adobe Audition查看輸出頻譜。使用思博倫POLQA音質測試設備測試端到端延時。ios和PC使用wireshark，android鏈接root手機使用tcpdump命令抓包。以語音樣本做爲輸入，經過損傷儀增長網絡損傷。

GME在不一樣場景下提供不一樣的音質體驗和不一樣的抗網絡損傷技術，實時語音音質在網絡無損的場景下的平均MOS分達到4.38（滿分5分），平均延時低於200ms；經過先進的丟包恢復技術、丟包補償算法以及優秀的網絡抗性，即便在50%以上丟包、1000ms的網絡抖動下，也能保持順暢的溝通和很好的音質。例如MOBA類遊戲中，在保證正常的語音溝通和良好的性能前提下，移動網絡模式每分鐘流量消耗低於500KB，CPU佔用率平均在10%如下等。

在fps類遊戲中，槍聲、腳步聲音效的方位一貫是高端玩家很是重要的輔助信息，但當玩家打開遊戲內置實時語音功能時，這些爲了沉浸體驗專門製做的遊戲音效會丟失或減弱，整個遊戲音質進入到「打電話」級別。緣由是通常手機都分爲媒體音量和通話音量，媒體音量是爲了聽音樂等使用的，採樣率較高，音質效果較好，但沒有音頻處理好比回聲消除等；通話音量主要爲了打電話用，採樣率比較低，只保證能聽清楚人生，且爲了解決回升消除問題，系統提供了回升消除算法。

在咱們的場景中，遊戲爲了高質量音質，使用了媒體音量，但開通實時音頻後若是繼續用媒體音量，雖然保留了較好的遊戲音質，則會有明顯的回聲，高噪聲等問題；因此通常遊戲開了實時音頻後都會切換到通話音量，利用系統的3A處理來解決回升噪聲等問題，但負面效應就是遊戲音質降低。因此GME與Wwise提出了聯合解決方案，在保證媒體音量的前提下，在實時語音中增長3A算法保證明時語音效果。