音視訊通訊能力作為標配滲透到了各個行業，騰訊音視訊實驗室音訊技術負責人郭亮在LiveVideoStackCon 2017上分享了騰訊音視訊實驗在流暢無卡頓、回聲消除等音訊前處理、網路部署與覆蓋等各個技術上的深度解析，以及前沿技術創新在音視訊場景中的實踐，本文為分享的整理。

演講 / 郭亮

整理 / LiveVideoStack

一、行業背景與趨勢

感謝主辦方LiveVideoStack給予這次分享機會來介紹我們整體的技術方案，以及互相探討學習。首先，做下自我介紹，我是來自騰訊音視訊實驗室的郭亮，主要負責騰訊視訊雲的整體解決方案，以及互動直播、點播的解決方案。 

眾所周知在前年下半年和去年移動直播非常火，雖然今年整體直播行業略有降溫，但並不代表音視訊也降溫了，同時音視訊的應用場景變得越來越多，我們作為一家視訊雲服務平臺，更能深刻地感受到這種變化，像上圖中聚美、蘑菇街、大智慧以及全民K歌、唱吧等等，這類自帶粉絲特性以及自帶行業特性的App越來越火。

1.直播行業的細分

教育是非常火的音視訊應用場景之一，比如像VIPKID線上課堂的使用者群體數量就非常大；電商也是比較大的應用場景，由於它自帶流量的屬性，因此變現能力較強；遊戲賽事，近年來如王者榮耀等遊戲推動了直播的發展；再有就是旅遊的、秀場的、社交等等應用都不約而同的用起了音視訊技術。前兩年更火的是以觀看為主的單向直播，而近一兩年趨勢則轉變為以教育、電商、K歌這一類互動性更強的直播方式。

2.優秀直播產品的特性

我們可以看到一個優秀的直播產品所需的特性很多，雖然現在使用WebRTC可以快速搭建起直播產品，但同時也會發現存在各種問題：延時、回聲、動效等等，因此對於一個初創的團隊而言，從頭到尾搭建音視訊是非常耗人力以及時間成本，而且一旦錯過視窗期也意味著錯過了一些非常重要的資源。因此我們也認為“讓專業的人去做專業的事”。

3.主流直播方案

在現如今的行業中，很多公司都在推基於音視訊服務的平臺，那麼又該如何去做技術選型呢？又有哪些方案可供選擇？上圖中的直播方案其實也都是比較傳統的方案：RTMP、FLV、HLS、RTP等等，在幾年前PC端比較火時，RTMP和FLV因為無需安裝額外的東西而具有非常廣泛的應用，移動端的火爆則讓具有手機瀏覽器支援特性的HLS得到了大範圍的應用。上圖列了一些優缺點，可以看到它們各有千秋，如RTMP和HLS適應性較強，但延時和可控制性上都是有一定的缺陷。

4.騰訊雲互動直播方案

我們在做視訊雲時分析了各個方案的優缺點，最終推出了一套方案（上圖），其實目前主流服務平臺的方案都大同小異：以UDP的實時傳輸作為主要的實時溝通的方案，在小範圍追求低延遲、高質量的情況下，我們建立一個UDP小範圍的傳輸網路，同時支援旁路推流，以及點播錄製，支援CDN分發。這樣我們既支援了一個高互動的網路，同時也支援大範圍分發、錄製、後處理、可接入機房這樣的服務後臺體系。下面的方案中使用CDN做分發的主要原因還是出於成本控制，因為一旦使用者量很大，使用上面的方案所帶來的成本就會成為企業沉重的負擔。

二、音視訊質量

上面簡單的介紹了一下我們的方案，接下來是今天主要分享的三部分內容：

1. 音視訊的質量

2. 可擴充套件的功能

3. 技術創新

音視訊的質量我將它分為兩類：

1. 網路傳輸以及抗性方面的質量

2. 音視訊核心的質量

之所以這樣分類，主要是自身使用場景和服務客戶的過程中，經常會反映出兩個問題：一個是卡頓、延時大，另一個是回聲、畫質不清晰等問題，由此分為了兩個方面。

1.網路傳輸與抗性

• 伺服器部署覆蓋全球

我們會在全球各個主流國家進行布點，這也是很多大公司集中採購的優勢之一，同時我們這些資源也可以進行很好的複用。舉個例子，如上圖我們在北京進行一個現場或者互動的直播，美國的朋友想觀看，那麼此時我們可以提供多條鏈路：從加拿大獲取、從北京拉專線直連、從上海或者香港轉中轉等等，這樣我們就能實時從多條鏈路中擇優選擇質量最好的鏈路傳輸。當然並不是所有時間都必須使用最優的網路，這裡我們還會有所控制，比如上面的例子中從北京到上海再到美國這條鏈路是最好的，但同時上海的使用者量也非常大，那麼怎麼合理的在後臺進行使用者分佈的控制，同樣是很重要的。

僅僅通過主觀評定還遠遠不夠，很多時候需要用資料說話，我們在全球使用者量比較大的主流國家之間的網路鏈路質量進行了量化，我們根據延時、丟包等相應指標綜合考核評分，實時監控網路鏈路的質量。如圖上所示，我們定義紅色為網路質量相對比較差的地區，可以看到從非洲和澳大利亞出來的網路很差，如果接入自動監控的機制就可以看到這個地方網路一定是有問題的。這樣我們就可以提前發現問題，進行監控。同時可以很好的給使用者做排查。

做網路有幾個要點：

1. 部署要好，若部署不好，後面的東西做的再好都會產生問題

2. 部署好之後抗性也要強，這樣即使在部署較好，但網路質量下降時，也可以很好應對

• 影響秒開的因素

如何做秒開？為了更好的定位問題，我們把它定義為兩個階段：進房速度和出畫速度。首先進房速度要快，一旦耗時很長，使用者的產品體驗就會非常差，你也很難想象使用者滑屏之後出現兩秒的黑屏，因此進房速度一定要快，這就需要對並行和裝置有一定深刻的理解。第二，出畫速度要快，直播中有人進來時會向伺服器請求資料，而只有收到第一個GOP I幀，後面的資料才能出來，但同樣有可能出現當請求時GOP的I幀剛過去，這就要花費一定時間等待，如此是無法滿足使用者體驗的。

• 雙GOP快取機制

針對上面GOP I幀的問題，我們在Server緩衝一個GOP，這樣就可以拉到最近的一個I幀，從而保證使用者能儘快的看到畫面。同時也做了一些優化，快取一個GOP是否能保證使用者在最快的時間內就看到畫面？能否保證在最快的時間就把這個延時降下來？答案其實其不行的。比如現在多拉了一個GOP，但哪怕GOP設的很小，它也會多拉一些資料，所以我們會對它做對齊的處理，包括音視訊對齊，以及一些時間戳的操作。

其實或者無論音訊還是視訊，都會有快進慢放的操作。對於普通場景來說快進慢放的感受可能不明顯，但對音樂等這類節奏感很強的應用，就會非常明顯。因此我們按照串並聯方案，快取兩個GOP，根據它合適的時機來推最合適的GOP，從而減少快進慢放對體驗的影響。

不過在實踐過程中我們發現，雖然它大部分情況下都能保證出畫或進房時間很快，但不穩定性非常強。這主要是由於當推了一個GOP，在幾十毫秒或者幾百毫秒內，同時下來的資料量會非常大，從而造成網路擁塞，那麼假如這時剛好把I幀丟掉了，首屏載入一樣會有問題。我們針對這個問題做了推流速度的微控制，比如20毫秒推500K，但僅靠控制還是不夠的，還需要做一些如QoS保障機制、FEC、關鍵幀的重發等等機制將質量保證到最好。

• 網路三級自適應調控機制

上圖是我們網路控制的架構——三級自適應的調控機制，它分別對應了不同的網路在幾百毫秒級別微小的丟包、一兩秒網路抖動情況下、以及長時間的網路頻寬已經有了明顯變化的情況下，採用不同的機制來對整個編解碼流控進行調整。在網路抖動很小時，會首先調整位元速率，接下來是對幀率的細微調整，當確認長時間網路較差時，我們會對整體編碼的策略和編碼引數進行調整，通過這樣的方式來實現良好的網路抗性。

• 快速網路探測專利技術

前面介紹的都是事後處理，也就是在我監控到出現丟包、網路的延時比較大之後，再對傳送碼流、傳送位元速率進行調整，其實此時已經晚了，因為網路已經變壞了，而當作出調整時，它可能又已經恢復了，那這就是無效的調整。因此我們結合了國外的一些前沿技術做了一套快速的網路探測技術，大家可能用過RTC的知道它有一個卡爾曼濾波頻寬預測，我們設計了一套更為優秀的演算法，總結來說，我們可以在網路達到臨界點之前，提前感知到網路的變化，從而作出調整保證使用者觀看體驗。

2.音視訊核心質量

• 優異的回聲抵消技術方案

前面重點講解了網路質量，下面我們繼續介紹音視訊核心的質量。雖然現在iPhone和很多安卓機型都自帶回聲抵消，而且WebRTC中也有AECM模組，即使對於沒有音視訊基礎的人，也可以做到Run起來沒有回聲，但這只是比較初級的體驗。雖然蘋果回聲抵消做得比較好，但對於像全民K歌這類專業級的音樂應用來說，它對回聲抵消要求還是無法滿足的。比如使用iOS的回聲抵消後聲音的頻譜一定會下到12K，但是對於音樂應用最少要保證16K的頻譜，也就是32位取樣才能比較真實的還原聲音的質量。

在安卓上，使用AECM則存在適配能力以及偶爾出現回聲的問題，最重要的是ACEM的雙講剪下會非常的厲害。除此以外還存在另一個比較大的問題：手機一般至少會有三種音量的型別——通話音量、鈴聲音量和媒體音量，我們在放歌或直播時一般使用的是媒體音量，但如果你想使用系統的回聲抵消能力，則必須切換為通話音量，但對於iOS來說，切換為通話音量型別會對音質有一定損傷。

因此回聲抵消也一直是我們自研的核心技術。回聲抵消有兩個技術：首先是自適應濾波、殘餘噪音消除是否乾淨，但在此之前更重要的是訊號對齊，如果訊號對齊不好，即便演算法再優秀也是沒有辦法將聲音消除乾淨的。因此我們在訊號對齊方面也是有多套對齊方案同時上，這主要是為了滿足不同的場景間的特性區別：比如安卓的碎片化，包括PC端XP、Win7、Win8，Win10的特性也都不一樣，某些系統上時間戳非常準、而有些則使用線譜非常準的。我們自研的一套指紋對齊，它更加精準，會在系統特性、效能消耗以及最終效果之間做平衡。

第二點就是適應濾波器、殘留回聲的抑制以及一些細分場景的調優。上圖是Skype（上）和我們自研（下）的效果對比，紅框部分中可以看到，下面的回聲抵消很快就將回聲收斂了，雖然上面也做了很好的收斂，但時間比較長。在我們日常使用時可能會有這種體驗：正常溝通時沒有問題，但在有人突然說話時會出現漏回聲的情況，這就是由於收斂慢造成的，因此這也是考核回聲抵消比較重要的因素之一。

• 領先的視訊編解碼引擎

其實在視訊編解碼這部分大家的做法基本差不多，就是軟硬結合的方式，對軟體的效能以及在X264或者其他的編解碼器在程式碼基礎上進行視訊編碼優化，以及在部分硬體上提供硬體編解碼。而我們的優勢在於使用QQ的產品做運營和測試，因為QQ每天有幾千萬次雙語音呼叫，基本上可以遍佈所有的機型，所以在硬體編解碼的機型適配上有一套很好的流程：比如我們給全網1%的使用者下發一個配置，當他登陸時，會選擇合適時機進行一個Test，然後上報結果，我們通過這個結果得知硬體編解碼的質量如何，若效果沒問題，就可以把這個配置再通過後臺系統重新下發，如此就可以形成一個良好的閉環系統，讓很多安卓手機都能享受到硬體編解碼的好處。

三、可擴充套件的功能框架

可擴充套件功能重點還是依託於我們的架構，在服務幾百家客戶的過程中，我們也發現每家客戶的需求是不一樣的，體現在幾個層次：

1.SDK層

有些人喜歡用音訊，有些人可能音視訊都需要，有些人可能需要外掛服務，為什會把這個單獨列出來做外掛化呢？其實大家對安裝包的要求是非常高的，尤其是在一些遊戲上，眾所周知在iOS上是有一條紅線的，當超過一百兆之後就不能用行動網路來下載，另外程式碼段是不能超過一百兆的，但是很多大型的遊戲程式碼量非常大，而它對安裝包的要求也非常高，這時我們就可以靈活的定製，按需出包。

2.採集層

對於接入多個服務一起操作的情況而言，音視訊的採集可能是不需要我們來做的，這時我們需要幫他來做處理和其他操作，比如在手機直播時實現伴奏等功能。

3.處理層

這部分我們也是開放的，比如提供給使用者美顏、變聲、濾鏡等體驗：我們的實時美顏技術會設定一個域值，根據它來控制美顏的程度；同時提供趣味音效等多種功能。之所以在這部分做可擴充套件，主要考慮到人主觀看法是不一樣的，使用者本身訴求的差異化可能會很大，比如大家對於美白的需求就會有所差別，甚至對於歐洲人來說美白功能是完全不需要的，因此我們這部分做了自適應。除了以上功能，我們還做了動效與背景的替換，比如動態貼紙等等。這部分需要著重關注的是效能的消耗和貼服性。

四、技術創新

最後分享我們的一些技術創新，可能大家首先會想到AI，不過從我的角度來看AI是一個工具，可以用它來做很多東西。而我們的技術創新也是一樣的，並非一定要做很高深的技術，而將技術真正的用到產品中，為產品創造更多更好的玩法，以及更好的使用者體驗。

1.跨房間連麥

房間對於傳統音視訊互動是不可迴避的一個方面，我們實現了一套跨房間連麥的機制，這套連麥機制不僅支援主播間的連麥，同時支援粉絲上麥，將兩個房間的粉絲聚合起來，這樣無形中增強了這種PK體驗和互動性，也創造了更多的玩法，而在實際使用者活躍度的統計中確實可以看到明顯的提升。

2.歌房合唱

除了網路抗性和部署方面以外，音視訊不同步也是非常重要的問題。我們在7月全民K歌中實現了多人合唱的功能，甚至有按字出歌詞的功能，但大家都知道每個人的網路延遲都不一樣，幾十毫秒的網路延遲是無法實現這種效果的，坦誠來講，這其實是產品體驗上看到的效果，實際的技術實現是一個領唱、一合唱、最後放給觀眾端，在這個過程中我們做了很多音畫同步以及對齊的處理，這裡的同步除了演唱者以外還包括了歌詞的對齊，從而讓觀眾感覺和KTV唱的體驗是一致的。

3.低照度處理

除了上面的介紹，我們在音視訊核心做了很多技術上的優化。比如在暗的場景下拍照、拍攝會有問題，因此我們做了低照度的處理，上圖從左到右是處理過的圖，可以看到清晰度有了非常大的提升，而在這裡著重介紹是因為我們已經實現視訊的低照度增強，而不單單是影象級的，但其中會有幾個難點：

• 效能上會有比較大的優化訴求

• 在視訊時不同幀之間的銜接要做的非常的精細

• 如何在極亮的場景處理的不模糊，沒有很多的噪點

4.手勢識別

手勢識別，目前藉助機器學習已經可以很好的實現，它的核心主要在於識別準確和效能損耗的降低。我們是基於現在一些成熟的框架，目前對一幀的識別大概可以在20毫秒以內返回結果，這樣就可以很好的滿足實時性的要求，給使用者一個更好的玩法體驗。

5.無參考評估

音視訊的主觀評估一直是難點，因此我們建立了一個無參考評估的體系，上圖淺的地方代表質量比較差，深的地方代表質量比較好，這樣我們就在全國給音視訊做無參考的評估，這也是我們一個比較核心的體驗，關於這部分內容大家可以詳見《直面音視訊質量評估之痛——走進騰訊音視訊質量體系》。

WebRTCon 2018 7折火熱報名

WebRTCon希望與行業專家一同分享、探討當下技術熱點、行業最佳應用實踐。如果你擁有音視訊領域獨當一面的能力，歡迎申請成為講師，分享你的實踐和洞察，請聯絡 [email protected]。

點選閱讀原文瞭解大會詳情。