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

演講 / 郭亮

整理 / LiveVideoStack

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

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

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

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

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

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

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

3.主流直播方案

?

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

4.騰訊云互動(dòng)直播方案

?

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

二、音視頻質(zhì)量

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

音視頻的質(zhì)量

可擴(kuò)展的功能

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

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

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

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

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

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

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

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

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

?

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

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

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

• 影響秒開的因素

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

• 雙GOP緩存機(jī)制

?

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

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

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

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

?

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

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

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

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

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

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

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

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

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

?

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

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

三、可擴(kuò)展的功能框架

?

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

1.SDK層

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

2.采集層

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

3.處理層

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

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

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

1.跨房間連麥

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

2.歌房合唱

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

3.低照度處理

?

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

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

• 在視頻時(shí)不同幀之間的銜接要做的非常的精細(xì)

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

4.手勢識別

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

5.無參考評估

?

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

WebRTCon 2018 7折火熱報(bào)名

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

點(diǎn)擊閱讀原文了解大會(huì)詳情。

總結(jié)

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

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