音視頻通訊能力作為標(biāo)配滲透到了各個行業(yè)，騰訊音視頻實驗室音頻技術(shù)負責(zé)人郭亮在LiveVideoStackCon 2017上分享了騰訊音視頻實驗在流暢無卡頓、回聲消除等音頻前處理、網(wǎng)絡(luò)部署與覆蓋等各個技術(shù)上的深度解析，以及前沿技術(shù)創(chuàng)新在音視頻場景中的實踐，本文為分享的整理。

演講 / 郭亮

整理 / LiveVideoStack

一、行業(yè)背景與趨勢

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

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

1.直播行業(yè)的細分

教育是非常火的音視頻應(yīng)用場景之一，比如像VIPKID在線課堂的用戶群體數(shù)量就非常大；電商也是比較大的應(yīng)用場景，由于它自帶流量的屬性，因此變現(xiàn)能力較強；游戲賽事，近年來如王者榮耀等游戲推動了直播的發(fā)展；再有就是旅游的、秀場的、社交等等應(yīng)用都不約而同的用起了音視頻技術(shù)。前兩年更火的是以觀看為主的單向直播，而近一兩年趨勢則轉(zhuǎn)變?yōu)橐越逃㈦娚獭歌這一類互動性更強的直播方式。

2.優(yōu)秀直播產(chǎn)品的特性

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

3.主流直播方案

?

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

4.騰訊云互動直播方案

?

我們在做視頻云時分析了各個方案的優(yōu)缺點，最終推出了一套方案（上圖），其實目前主流服務(wù)平臺的方案都大同小異：以UDP的實時傳輸作為主要的實時溝通的方案，在小范圍追求低延遲、高質(zhì)量的情況下，我們建立一個UDP小范圍的傳輸網(wǎng)絡(luò)，同時支持旁路推流，以及點播錄制，支持CDN分發(fā)。這樣我們既支持了一個高互動的網(wǎng)絡(luò)，同時也支持大范圍分發(fā)、錄制、后處理、可接入機房這樣的服務(wù)后臺體系。下面的方案中使用CDN做分發(fā)的主要原因還是出于成本控制，因為一旦用戶量很大，使用上面的方案所帶來的成本就會成為企業(yè)沉重的負擔(dān)。

二、音視頻質(zhì)量

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

音視頻的質(zhì)量

可擴展的功能

技術(shù)創(chuàng)新

音視頻的質(zhì)量我將它分為兩類：

網(wǎng)絡(luò)傳輸以及抗性方面的質(zhì)量

音視頻內(nèi)核的質(zhì)量

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

1.網(wǎng)絡(luò)傳輸與抗性

• 服務(wù)器部署覆蓋全球

我們會在全球各個主流國家進行布點，這也是很多大公司集中采購的優(yōu)勢之一，同時我們這些資源也可以進行很好的復(fù)用。舉個例子，如上圖我們在北京進行一個現(xiàn)場或者互動的直播，美國的朋友想觀看，那么此時我們可以提供多條鏈路：從加拿大獲取、從北京拉專線直連、從上海或者香港轉(zhuǎn)中轉(zhuǎn)等等，這樣我們就能實時從多條鏈路中擇優(yōu)選擇質(zhì)量最好的鏈路傳輸。當(dāng)然并不是所有時間都必須使用最優(yōu)的網(wǎng)絡(luò)，這里我們還會有所控制，比如上面的例子中從北京到上海再到美國這條鏈路是最好的，但同時上海的用戶量也非常大，那么怎么合理的在后臺進行用戶分布的控制，同樣是很重要的。

僅僅通過主觀評定還遠遠不夠，很多時候需要用數(shù)據(jù)說話，我們在全球用戶量比較大的主流國家之間的網(wǎng)絡(luò)鏈路質(zhì)量進行了量化，我們根據(jù)延時、丟包等相應(yīng)指標(biāo)綜合考核評分，實時監(jiān)控網(wǎng)絡(luò)鏈路的質(zhì)量。如圖上所示，我們定義紅色為網(wǎng)絡(luò)質(zhì)量相對比較差的地區(qū)，可以看到從非洲和澳大利亞出來的網(wǎng)絡(luò)很差，如果接入自動監(jiān)控的機制就可以看到這個地方網(wǎng)絡(luò)一定是有問題的。這樣我們就可以提前發(fā)現(xiàn)問題，進行監(jiān)控。同時可以很好的給用戶做排查。

?

做網(wǎng)絡(luò)有幾個要點：

部署要好，若部署不好，后面的東西做的再好都會產(chǎn)生問題

部署好之后抗性也要強，這樣即使在部署較好，但網(wǎng)絡(luò)質(zhì)量下降時，也可以很好應(yīng)對

• 影響秒開的因素

如何做秒開？為了更好的定位問題，我們把它定義為兩個階段：進房速度和出畫速度。首先進房速度要快，一旦耗時很長，用戶的產(chǎn)品體驗就會非常差，你也很難想象用戶滑屏之后出現(xiàn)兩秒的黑屏，因此進房速度一定要快，這就需要對并行和設(shè)備有一定深刻的理解。第二，出畫速度要快，直播中有人進來時會向服務(wù)器請求數(shù)據(jù)，而只有收到第一個GOP I幀，后面的數(shù)據(jù)才能出來，但同樣有可能出現(xiàn)當(dāng)請求時GOP的I幀剛過去，這就要花費一定時間等待，如此是無法滿足用戶體驗的。

• 雙GOP緩存機制

?

針對上面GOP I幀的問題，我們在Server緩沖一個GOP，這樣就可以拉到最近的一個I幀，從而保證用戶能盡快的看到畫面。同時也做了一些優(yōu)化，緩存一個GOP是否能保證用戶在最快的時間內(nèi)就看到畫面？能否保證在最快的時間就把這個延時降下來？答案其實其不行的。比如現(xiàn)在多拉了一個GOP，但哪怕GOP設(shè)的很小，它也會多拉一些數(shù)據(jù)，所以我們會對它做對齊的處理，包括音視頻對齊，以及一些時間戳的操作。

其實或者無論音頻還是視頻，都會有快進慢放的操作。對于普通場景來說快進慢放的感受可能不明顯，但對音樂等這類節(jié)奏感很強的應(yīng)用，就會非常明顯。因此我們按照串并聯(lián)方案，緩存兩個GOP，根據(jù)它合適的時機來推最合適的GOP，從而減少快進慢放對體驗的影響。

不過在實踐過程中我們發(fā)現(xiàn)，雖然它大部分情況下都能保證出畫或進房時間很快，但不穩(wěn)定性非常強。這主要是由于當(dāng)推了一個GOP，在幾十毫秒或者幾百毫秒內(nèi)，同時下來的數(shù)據(jù)量會非常大，從而造成網(wǎng)絡(luò)擁塞，那么假如這時剛好把I幀丟掉了，首屏加載一樣會有問題。我們針對這個問題做了推流速度的微控制，比如20毫秒推500K，但僅靠控制還是不夠的，還需要做一些如QoS保障機制、FEC、關(guān)鍵幀的重發(fā)等等機制將質(zhì)量保證到最好。

• 網(wǎng)絡(luò)三級自適應(yīng)調(diào)控機制

?

上圖是我們網(wǎng)絡(luò)控制的架構(gòu)——三級自適應(yīng)的調(diào)控機制，它分別對應(yīng)了不同的網(wǎng)絡(luò)在幾百毫秒級別微小的丟包、一兩秒網(wǎng)絡(luò)抖動情況下、以及長時間的網(wǎng)絡(luò)帶寬已經(jīng)有了明顯變化的情況下，采用不同的機制來對整個編解碼流控進行調(diào)整。在網(wǎng)絡(luò)抖動很小時，會首先調(diào)整碼率，接下來是對幀率的細微調(diào)整，當(dāng)確認長時間網(wǎng)絡(luò)較差時，我們會對整體編碼的策略和編碼參數(shù)進行調(diào)整，通過這樣的方式來實現(xiàn)良好的網(wǎng)絡(luò)抗性。

• 快速網(wǎng)絡(luò)探測專利技術(shù)

前面介紹的都是事后處理，也就是在我監(jiān)控到出現(xiàn)丟包、網(wǎng)絡(luò)的延時比較大之后，再對發(fā)送碼流、發(fā)送碼率進行調(diào)整，其實此時已經(jīng)晚了，因為網(wǎng)絡(luò)已經(jīng)變壞了，而當(dāng)作出調(diào)整時，它可能又已經(jīng)恢復(fù)了，那這就是無效的調(diào)整。因此我們結(jié)合了國外的一些前沿技術(shù)做了一套快速的網(wǎng)絡(luò)探測技術(shù)，大家可能用過RTC的知道它有一個卡爾曼濾波帶寬預(yù)測，我們設(shè)計了一套更為優(yōu)秀的算法，總結(jié)來說，我們可以在網(wǎng)絡(luò)達到臨界點之前，提前感知到網(wǎng)絡(luò)的變化，從而作出調(diào)整保證用戶觀看體驗。

2.音視頻內(nèi)核質(zhì)量

• 優(yōu)異的回聲抵消技術(shù)方案

前面重點講解了網(wǎng)絡(luò)質(zhì)量，下面我們繼續(xù)介紹音視頻內(nèi)核的質(zhì)量。雖然現(xiàn)在iPhone和很多安卓機型都自帶回聲抵消，而且WebRTC中也有AECM模塊，即使對于沒有音視頻基礎(chǔ)的人，也可以做到Run起來沒有回聲，但這只是比較初級的體驗。雖然蘋果回聲抵消做得比較好，但對于像全民K歌這類專業(yè)級的音樂應(yīng)用來說，它對回聲抵消要求還是無法滿足的。比如使用iOS的回聲抵消后聲音的頻譜一定會下到12K，但是對于音樂應(yīng)用最少要保證16K的頻譜，也就是32位采樣才能比較真實的還原聲音的質(zhì)量。

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

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

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

?

• 領(lǐng)先的視頻編解碼引擎

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

三、可擴展的功能框架

?

可擴展功能重點還是依托于我們的架構(gòu)，在服務(wù)幾百家客戶的過程中，我們也發(fā)現(xiàn)每家客戶的需求是不一樣的，體現(xiàn)在幾個層次：

1.SDK層

有些人喜歡用音頻，有些人可能音視頻都需要，有些人可能需要插件服務(wù)，為什會把這個單獨列出來做插件化呢？其實大家對安裝包的要求是非常高的，尤其是在一些游戲上，眾所周知在iOS上是有一條紅線的，當(dāng)超過一百兆之后就不能用移動網(wǎng)絡(luò)來下載，另外代碼段是不能超過一百兆的，但是很多大型的游戲代碼量非常大，而它對安裝包的要求也非常高，這時我們就可以靈活的定制，按需出包。

2.采集層

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

3.處理層

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

四、技術(shù)創(chuàng)新

最后分享我們的一些技術(shù)創(chuàng)新，可能大家首先會想到AI，不過從我的角度來看AI是一個工具，可以用它來做很多東西。而我們的技術(shù)創(chuàng)新也是一樣的，并非一定要做很高深的技術(shù)，而將技術(shù)真正的用到產(chǎn)品中，為產(chǎn)品創(chuàng)造更多更好的玩法，以及更好的用戶體驗。

1.跨房間連麥

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

2.歌房合唱

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

3.低照度處理

?

除了上面的介紹，我們在音視頻內(nèi)核做了很多技術(shù)上的優(yōu)化。比如在暗的場景下拍照、拍攝會有問題，因此我們做了低照度的處理，上圖從左到右是處理過的圖，可以看到清晰度有了非常大的提升，而在這里著重介紹是因為我們已經(jīng)實現(xiàn)視頻的低照度增強，而不單單是圖像級的，但其中會有幾個難點：

• 性能上會有比較大的優(yōu)化訴求

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

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

4.手勢識別

手勢識別，目前借助機器學(xué)習(xí)已經(jīng)可以很好的實現(xiàn)，它的核心主要在于識別準(zhǔn)確和性能損耗的降低。我們是基于現(xiàn)在一些成熟的框架，目前對一幀的識別大概可以在20毫秒以內(nèi)返回結(jié)果，這樣就可以很好的滿足實時性的要求，給用戶一個更好的玩法體驗。

5.無參考評估

?

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

WebRTCon 2018 7折火熱報名

WebRTCon希望與行業(yè)專家一同分享、探討當(dāng)下技術(shù)熱點、行業(yè)最佳應(yīng)用實踐。如果你擁有音視頻領(lǐng)域獨當(dāng)一面的能力，歡迎申請成為講師，分享你的實踐和洞察，請聯(lián)系 speaker@livevideostack.com。

點擊閱讀原文了解大會詳情。

總結(jié)

以上是生活随笔為你收集整理的腾讯音视频实验室：基于音视频细分场景的技术创新探索的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。