視頻全面數(shù)字化時代的到來，讓越來越多的開發(fā)者逐漸關(guān)注音視頻技術(shù)。隨著音視頻技術(shù)的應(yīng)用越來越廣泛，對于音視頻技術(shù)的要求也越來越高，既要簡單易接入，又要滿足高并發(fā)、低延遲、高清明眸，少流量……除此之外，與時俱進不斷優(yōu)化技術(shù)能力，應(yīng)對5G、出海等熱點需求。騰訊視頻云是如何滿足多場景的應(yīng)用，賦能行業(yè)，引領(lǐng)視頻技術(shù)的發(fā)展呢?

6月29日，云+社區(qū)主辦的技術(shù)沙龍-“音視頻及融合通信技術(shù)”在北京成功舉辦，騰訊云經(jīng)過多年的技術(shù)沉淀，并結(jié)合自身的最佳實踐，引領(lǐng)了現(xiàn)場近300位開發(fā)者關(guān)于“音視頻”技術(shù)的不一樣的思考。

以下為本次沙龍的現(xiàn)場演講摘要：

一、移動直播連麥技術(shù)實踐

首先聚焦在直播場景下，在當前這個全民直播的時代，連麥逐漸成長為直播領(lǐng)域非常重要的業(yè)務(wù)場景之一，但是網(wǎng)絡(luò)往往是不穩(wěn)定的，那么如何在網(wǎng)絡(luò)不可控及弱網(wǎng)的情況下來保證高質(zhì)量的連麥通訊服務(wù)呢?騰訊高級工程師蔣磊現(xiàn)場為大家闡述了騰訊在這方面的最佳實踐?！　?/p>

連麥直播概述

連麥直播與普通直播的區(qū)別在于，后者類似單口相聲，一個直播表演很多觀眾看;連麥直播是對口相聲和群口相聲，有大主播和小主播，普通觀眾看大主播和小主播的畫面?！　?/p>

　　(連麥基本原理)

不過往往理想很美好，現(xiàn)實卻很骨感。在技術(shù)實現(xiàn)上并非嘴上說說就可以了，連麥直播通常會遇到這三類問題：延時、回聲和混流。

延時　　

普通直播的延時主要來自于轉(zhuǎn)碼處理過程中產(chǎn)生的百毫秒級別的延時，以及CDN延時。

因為CDN回源的工作機制，在H.264這種GOP編碼方式下，回源必須拿到GOP的I幀(關(guān)鍵幀)才能分發(fā)。通常情況下CDN引入的延時就有1-3秒，因此要解決普通直播引入的延時，最好的解決辦法就是不走CDN?！　?/p>

解決辦法就是使用UDP協(xié)議，由主播端推流到upload，upload拉流至rtmp-acc節(jié)點，然后小主播再從rtmp-acc節(jié)點獲取數(shù)據(jù)，同樣的，小主動將將流推到upload上并讓大主播從rtmp-acc上拉。內(nèi)部都走高速專線，所以整體延時會很低。通過UDP加速這樣的方式，可以實現(xiàn)大主播到小主播之間500毫秒以內(nèi)的延時?！　?/p>

當然還有一部分延時來自網(wǎng)絡(luò)。網(wǎng)絡(luò)總是處于波動的狀態(tài)，或多或少會有丟包的情況出現(xiàn)。這里的解決方案就是通過 jitterbuffer 這樣的蓄水池平滑數(shù)據(jù)流來實現(xiàn)。因為網(wǎng)絡(luò)傳輸過程中會有不均勻的抖動，數(shù)據(jù)會在 jitterbuffer 緩存一下再給到解碼器，在實際直播里可以將 jitterbuffer 設(shè)置在200毫秒左右，但是這樣又需要處理 jitterbuffer 累積延時問題。因為技術(shù)上通過jitterbuffer實現(xiàn)了緩沖，但客觀上網(wǎng)絡(luò)還是抖動的，而jitterbuffer這個“蓄水池”只有蓄滿了才會往下一步送數(shù)據(jù)，所以一旦網(wǎng)絡(luò)一直抖動，延時就會不斷增加，為了解決這個問題我們就必須要修正累積的延時。在騰訊云的LiteAVSDK中，播放器已經(jīng)做好的累積延時的修正。

回聲

回聲是另外一個最常遇到的問題，回聲通常會分為兩類，第一類是線路回聲，一般由硬件廠商自己解決;另一類就是聲學(xué)回聲。

聲學(xué)回聲的原理是什么?當原聲傳到對方揚聲器播放之后，被對方的麥克風(fēng)再采集一次，通過通信線路傳回來再次播放，大主播就會聽到自己的聲音。而且人的耳朵特別靈敏，超過10毫秒以上的回聲就能被分辨出，而通信線路的延時往往在50毫秒以上，因此回聲必須要做消除?！　?/p>

依上圖所示，為了解決回聲，將播放器播放的音頻數(shù)據(jù)與麥克風(fēng)采集的音頻數(shù)據(jù)進行波形比對，反向把波形消掉，這個過程就叫AEC。騰訊云已經(jīng)AEC功能在LiteAVSDK中內(nèi)置，開發(fā)者無需再額外編程，可以直接使用。

畫面混合

畫面混合分為客戶端與云端，客戶端即大小主播相互之間要看到的畫面，有兩個部分，一個是自己本地的預(yù)覽，另一個是拿到的對方數(shù)據(jù)畫面。本地預(yù)覽相對比較簡單，只要播放器支持多實例就可以搞定了。　　

在云端，混流的模塊從upload拿到數(shù)據(jù)之后按照設(shè)定的參數(shù)分層疊加，再通過CDN分發(fā)，就是云端混流。云端混流可以極大減輕客戶端播放的壓力。騰訊云可以同時最大支持16路混流，輸入源可以是純音頻、視頻、畫布和圖片。

騰訊云連麥直播實踐--MLVBLiveRoom

在過去的幾年里騰訊云使用了非常多的技術(shù)手段來解決連麥中遇到這些問題，并且將這些技術(shù)方案打磨好，實現(xiàn)了MLVBLiveRoom方案?！　?/p>

MLVBLiveRoom基于LiteAVsdk+IMSDK，結(jié)合騰訊云云直播和云通信IM服務(wù)，從普通的直播，到連麥直播、跨房PK都在一個組件里直接搞定;通過在騰訊云的云端提供的房間管理服務(wù)，普通開發(fā)者不需要再考慮過多房間狀態(tài)和房間管理的細節(jié);同時基于優(yōu)圖實驗室的P圖技術(shù)可以實現(xiàn)人臉AI特效及視頻動態(tài)特效;并且它的接入做得足夠簡單，普通開發(fā)者半天時間就可以跑通整個流程。　　

除此之外，MLVBLiveRoom通過儀表盤數(shù)據(jù)把底層的音視頻數(shù)據(jù)回調(diào)給開發(fā)者，開發(fā)者可以通過onNetStatus拿到直播過程最直接的數(shù)據(jù)，從而更方便地實現(xiàn)線上業(yè)務(wù)的監(jiān)測與運維。

除了MLVBLiveRoom之外，為了解決連麥直播中普通觀眾的上下麥平滑切換問題，騰訊云還實現(xiàn)了TRTC低延時大房間的方案，讓主播和觀眾們都統(tǒng)一加入到同一個低延時大房間里面，每一個用戶都通過UDP的方式推流和播放，這種方式可以實現(xiàn)極低延時，主播之間最低可以到100毫秒，普通觀眾的延時可以控制在1000毫秒以內(nèi)。

二、騰訊云直播PCDN加速方案

直播場景音視頻的流暢度直接關(guān)系到用戶的體驗感受。騰訊云P2P是業(yè)內(nèi)領(lǐng)先成熟的P2P產(chǎn)品，其中多個產(chǎn)品線已經(jīng)成熟，現(xiàn)在已經(jīng)推廣到斗魚、企鵝、電競、英雄聯(lián)盟等各個不同的平臺。云+社區(qū)技術(shù)沙龍請到了騰訊XP2P負責(zé)人張鵬現(xiàn)場為開發(fā)者帶來了《騰訊直播PCDN加速方案》的分享?！　?/p>

XP2P簡介

P2P簡單而言，就是你有我有大家都有的東西，我們可以通過網(wǎng)絡(luò)相互連接來分享之。P2P架構(gòu)體現(xiàn)了互聯(lián)網(wǎng)架構(gòu)的核心技術(shù)，因此這種概念被描述在RFC 1里面，可謂由來已久，是早期互聯(lián)網(wǎng)建設(shè)者心中最夢寐以求的架構(gòu)。從2014年到現(xiàn)在經(jīng)歷了5年的打磨完善，產(chǎn)品也非常的穩(wěn)健成熟，覆蓋Android、IOS、H5、PC等各種平臺，它有更多的節(jié)點進行加速，延遲也是等同于CDN甚至優(yōu)于CDN的起播速度，在S8賽事期間峰值達到8T，經(jīng)歷了大規(guī)模的直播活動的檢驗，同時也見證了flash由盛轉(zhuǎn)衰的過程。

XP2P產(chǎn)品功能

騰訊云XP2P，是為了滿足直播需求的帶寬和延遲而開發(fā)出來的。技術(shù)上，首先P2P所有的節(jié)點都要有數(shù)據(jù)一致性。對于視頻來說就涉及到視頻流的切片。過去的技術(shù)是無法在原始直播流上進行切片的，現(xiàn)在切片操作對直播流無任何損害，完全不修改它里面的mux信息和codec信息?！　?/p>

這種方式跟FLV流合成一體，P2P的數(shù)據(jù)可以直接交給播放器，對視頻內(nèi)容的侵入性可以做到非常完美。用這樣的方式還可以實現(xiàn)自適應(yīng)碼率，是比HLS、Dash還要領(lǐng)先的技術(shù)?！　?/p>

P2P的客戶端首先要做穿透。當前的互聯(lián)網(wǎng)有NAT(網(wǎng)絡(luò)地址轉(zhuǎn)換)，就是說公網(wǎng)地址不夠，局域網(wǎng)上用內(nèi)網(wǎng)地址在發(fā)送請求的時候，加一個斷口標識這個請求。這帶來的一個問題是A知道B的地址但是無法連接，會直接被NAT阻止。　　

STUN協(xié)議是P2P打洞建立起連接的核心協(xié)議。進入互聯(lián)網(wǎng)之后之后STUN有一個連接圖。首先向STUN公網(wǎng)連接，如果沒有收到則說明對方有防火墻，如果收到了就可以看公網(wǎng)地址和內(nèi)網(wǎng)地址是否一樣，如果一樣說明前面沒有NAT，它是公網(wǎng)地址。接下來向服務(wù)器發(fā)一個包，讓服務(wù)器換一個IP地址給我回包，如果收到的話就是一個真正的公網(wǎng)地址，如果沒收到是因為前面有一個防火墻?！　?/p>

如果公網(wǎng)地址跟內(nèi)網(wǎng)地址不一樣，說明里面有一個NAT。首先請求原來的服務(wù)器換一個地址回消息。如果這個消息收到了就是公網(wǎng)地址，收不到的話說明是一個限制性的，或者對稱型的。接下來就是由STUN再去請求，注意這個請求是用同一個內(nèi)網(wǎng)請求，然后看返回的地址和第一次返回的官網(wǎng)地址是否一樣，如果不一樣的話就是對稱型的;如果一樣接下來需要再探測是ID限制型還是端口限制型，然后再朝這個服務(wù)器換一個端口回消息，如果能收到就是ID限制型，如果收不到消息就是端口限制型?！　?/p>

做P2P的時候不應(yīng)該探測帶寬，因為這會發(fā)很多包，對帶寬來說是一種浪費，所以應(yīng)該使用自然探測。還有一點，P2P要使用TCP剩下的帶寬，要公平競爭，而不是肆意搶占TCP帶寬。因為TCP存在著啟動慢、擁塞控制差、抗抖動差、重傳歧義等問題，相比之下XNTP就具有快速啟動、基于合理建模的數(shù)學(xué)公式的速率控制、以及丟包率反饋傳輸速率、雙序號包索引等優(yōu)勢。　　

XNTP的Pacing發(fā)送可以選擇均勻發(fā)送，一個RTT是40毫秒，發(fā)40個包，每一毫秒發(fā)一個包，這樣對路由器非常均勻，就可以更少丟包的同時把網(wǎng)絡(luò)利用上去。

XP2P的應(yīng)用場景

對于P2P的應(yīng)用場景，無論是直播、點播、文件都是適用的，文件適合大文件的分發(fā)。對于4K視頻加速，有P2P的助力，4K體驗會更勝一籌。尤其對于大型直播活動比如說賽事、春節(jié)聯(lián)歡晚會，是非常適合P2P來提高質(zhì)量節(jié)省帶寬的。對于短視頻、常規(guī)視頻，更是P2P加速的強項。對于大規(guī)模、大文件的分發(fā)也可以用P2P，其原理類似點播視頻的P2P。

P2P接入也非常簡單，先是注冊騰訊云在云官網(wǎng)開通，通過騰訊云的官網(wǎng)下載SDK并接入，雖然不似某些云廠商吹噓的一行就接入，但是花個10行，也是能夠完美接入的，然后測試上線然后運維，非常簡單，還會有專人對接。

XP2P的未來與展望　　

騰訊云X-P2P某種意義上實現(xiàn)了多播協(xié)議，即優(yōu)化了網(wǎng)絡(luò)質(zhì)量，又降低了網(wǎng)絡(luò)的負載;而456(4K、5G、IPv6)的到來，將會使X-P2P進一步發(fā)揮能力和得到更廣泛的應(yīng)用;區(qū)塊鏈的底層所使用的P2P技術(shù)和騰訊云X-P2P有異曲同工之妙，然而libp2p除了搞了一堆不必要的概念，還沒有看到怎么接觸到穿透的核心技術(shù);邊緣計算也將依賴穩(wěn)健、安全、高效的P2P技術(shù)底層;XNTP傳輸協(xié)議如果再優(yōu)化一下，甚至將可以和quic相提并論;最終，X-P2P可能回歸最初的夢想，在互聯(lián)網(wǎng)上產(chǎn)生出徹底去中心化的服務(wù)模式。

三、騰訊視頻云海外直播系統(tǒng)架構(gòu)設(shè)計與最佳實踐

近幾年國內(nèi)視頻直播市場逐漸疲軟，越來越多的廠商開始涉足海外直播。云+社區(qū)技術(shù)沙龍請到騰訊高級技術(shù)專家，海外直播技術(shù)負責(zé)人胡仁成老師分享《騰訊視頻云海外直播系統(tǒng)架構(gòu)設(shè)計與最佳實踐》?！　?/p>

海外直播系統(tǒng)在應(yīng)用軟件層面跟國內(nèi)沒有太大的區(qū)別。直播系統(tǒng)架構(gòu)包含三大塊，一是公有云和網(wǎng)絡(luò)基礎(chǔ)設(shè)施的建設(shè);第二是在此基礎(chǔ)設(shè)施上架設(shè)軟件系統(tǒng)，實現(xiàn)直播流媒體的分發(fā);第三，在已完成的系統(tǒng)上更深入化優(yōu)化。

海外網(wǎng)絡(luò)與機房建設(shè)　　

當前騰訊云在全球的網(wǎng)絡(luò)布局從地域分為三大區(qū)，北美、亞太(香港、新加坡)、歐洲(德國)。海外大概接近2千家運營商。要完成這2千家運營商的互聯(lián)不可能每家都進行直接互聯(lián)?！　?/p>

按運營商的級別可以劃分為三類Tier1、Tier2、Tier3。Tier1是跨大區(qū)跨州互聯(lián)的，Tier2是區(qū)域互聯(lián)的，Tier3是國家內(nèi)部覆蓋，一般是面向終端用戶提供網(wǎng)絡(luò)服務(wù)的運營商。在海外還要布局很多加速點，如下圖所示：　　

海外直播系統(tǒng)建設(shè)

直播需要低延時、低卡頓，根據(jù)這個原則所有的流系統(tǒng)不能部署在同一個地方。因此需要采取去中心化的方案，在已有DC的機房都會部署一個源站系統(tǒng)。　　

每一個源站都會包含流媒體接入的能力，同時部署轉(zhuǎn)碼、錄制、截圖、存儲和CDN分發(fā)能力。去中心化的設(shè)計方案很適合本地化直播服務(wù)，主播的流推到最近的源站，質(zhì)量更好。

下面的問題是狀態(tài)同步，比如說巴西的主播推了流上來，中國的觀眾看的時候怎么樣找到巴西主播的流在哪?挑戰(zhàn)很大?！　?/p>

第一個要求是雙活，我們自研了一套狀態(tài)組件，去滿足我們提出的一些能力的要求。其中，我們選擇通過間隔心跳保持數(shù)據(jù)同步的最終一致性，它有一個容忍的尺度和閾值，這個根據(jù)業(yè)務(wù)特點去調(diào)優(yōu)。

第二個要求就是同步方案，這里狀態(tài)同步的思想遵循95%本地分發(fā)的原則，9個大源站的狀態(tài)并不是互相同步。通過挑選集中點，把海外其它7個源站同步到香港，然后再從香港到國內(nèi);小的源站查一下香港就可以，這樣減少了設(shè)計開發(fā)的復(fù)雜度?！　?/p>

去中心化設(shè)計又引入了另外一個問題就是如何實現(xiàn)跨區(qū)拉流，有5%的用戶要看美國的流怎么辦?這時候就要保證這一整條鏈路的服務(wù)質(zhì)量，狀態(tài)一定要準;狀態(tài)同步過去之后還要保證回源鏈路的穩(wěn)定性，在核心鏈路上鋪設(shè)回源專線，走騰訊云的內(nèi)網(wǎng)專線?！　?/p>

這是一個標準化的一體化方案，這種方案的特點是雙端用戶自己控制，只需推RTMP流過來由騰訊分發(fā)，支持RTMP、DASH、HLS通過不同的碼分發(fā)。另外，我們也支持用戶自建源站，騰訊云進行回源分發(fā)，這個在新聞資訊分發(fā)場景比較多?！　?/p>

海外直播另一個特點是對版權(quán)保護的需求。騰訊云也提供了一個基于iOS和安卓系統(tǒng)的DRM方案，支持Widevine和Fairplay。

精細化運營

系統(tǒng)做好了就相當于做到了90分，后期要通過精細化的優(yōu)化和運營實現(xiàn)95、99分。精細化運營也涉及一些問題。　　

這些問題總體分三類，第一是騰訊海外直播系統(tǒng)自動化運維、監(jiān)控的能力的構(gòu)建;第二是如何解決海外調(diào)度復(fù)雜的問題;第三是如何解決網(wǎng)絡(luò)設(shè)施落后的國家跨區(qū)傳輸以及最后一公里的視頻流傳輸和優(yōu)化問題?！　?/p>

首先是全方位監(jiān)控系統(tǒng)。騰訊云能在一秒或者五秒以內(nèi)感知到某個業(yè)務(wù)流量突長，并且能夠在增長的過程中自動化擴展更多服務(wù)節(jié)點或服務(wù)帶寬給它承載。我們的監(jiān)控能精細到每個國家每個運營商的AS號，看它的丟包率，延時等技術(shù)指標，然后找團隊去優(yōu)化。在應(yīng)用層面我們有自動化的監(jiān)控系統(tǒng)能夠?qū)崟r發(fā)現(xiàn)哪些機器宕掉了，實時把異常節(jié)點剔除掉?！　?/p>

第一，如果巴西的丟包率很高，為了解決TCP由于丟包導(dǎo)致傳輸速率不穩(wěn)或者下降的問題我們選擇采用Quic方案。我們設(shè)計開發(fā)了一套TCP和QUIC互相轉(zhuǎn)換的協(xié)議插件，這里接受用戶的RTMP流，然后轉(zhuǎn)化成Quic傳輸?shù)矫绹脑凑?，再把它剝離成RTMP推到美東的源站。這中間用了Quic加速，優(yōu)化了中間鏈路弱網(wǎng)的問題。上行優(yōu)化之后，卡頓率從6.5%降到4.8%。

第二步優(yōu)化了下行回源鏈路，下行回源也用了類似的Quic代理做了協(xié)議轉(zhuǎn)換，卡頓率從4.8%降到3.6%?！　?/p>

做最后一公里邊緣協(xié)議站的優(yōu)化時，騰訊自營了一套類似于BBR，但克服了BBR的缺陷的方案，叫QTCP，在最后一公里優(yōu)化了弱網(wǎng)傳輸?shù)膯栴}，整體卡頓率降低了20%。

另外，海外直播系統(tǒng)設(shè)計還需要考慮在綜合成本的限制下取得一個邊際收益的最大值，這是我們目前做海外直播的一個重要的思路。

四、實時音視頻與PSTN結(jié)合的解決辦法

如今，融合通信技術(shù)顯得愈加重要。融合通信技術(shù)具體是指什么?云+技術(shù)沙龍請到騰訊云通信平臺高級工程師顏學(xué)偉老師帶來《實時音視頻與PSTN結(jié)合的解決辦法》的分享?！　?/p>

實時音視頻與PSTN融合的背景　　

實時音視頻通信(RTC)最主要的特點是“實時”，一般分為三個級別，延遲3秒以上是偽實時，1秒到3秒為“準實時”，真正的實時是1秒以內(nèi)。騰訊云的實時音視頻可以做到300毫秒以下。

常見的QQ語音通話和視頻通話，兩個QQ客戶通過外網(wǎng)發(fā)起語音通話，一般處理會分為兩個部分，一個是信令層的處理，一個是碼流層的處理。

信令層主要用于通話的建立、連接、資源的準備，并協(xié)商碼流編解碼類型等相關(guān)信息，碼流層專注于音視頻數(shù)據(jù)處理。而實時音視頻要做到比較低的延時，我們在傳輸協(xié)議上直接選擇UDP，因為UDP雖然不可靠，但是它的性能比較高，相對于TCP少了三次握手和四次揮手。

因為外網(wǎng)的環(huán)境時好時壞，UDP又是不可靠的，在Internet傳輸音視頻數(shù)據(jù)時容易產(chǎn)生抖動，所以我們需要一個抗抖動的能力。當網(wǎng)絡(luò)質(zhì)量不好產(chǎn)生丟包時，我們也需要一個抗丟包的能力。而且外網(wǎng)的質(zhì)量波動比較大，也需要一種自適應(yīng)的方式來動態(tài)調(diào)節(jié)發(fā)送的碼流，稱之為流控，就是隨時檢測主被叫雙方接收的包量，來計算丟包率、延時和碼率，用于來控制發(fā)送端的采樣率和發(fā)送的碼率，當時網(wǎng)絡(luò)質(zhì)量不好時，我們可以把發(fā)送端的采樣率和碼率降低，減少發(fā)送的整體包量，進而減小網(wǎng)絡(luò)的擁堵。網(wǎng)絡(luò)質(zhì)量好時，我們可以提高發(fā)送端的采樣率和碼率，增加發(fā)送的整體包量，會讓接收端有較好的語音質(zhì)量。

RTC與PSTN差異　　

首先我們要看一下兩者的差異。實時音視頻我主要以QQ語音通話為例，剛才也說過一個完整的音視頻處理是要分很多步的，音頻采集、預(yù)處理、編碼、網(wǎng)絡(luò)傳輸、解碼和播放。網(wǎng)絡(luò)傳輸協(xié)議上，QQ語音通話是使用自己的私有協(xié)議，而PSTN使用的是標準的SIP+RTP協(xié)議，這是語音運營商采用的標準協(xié)議。

QQ支持的編碼有很多，有SILK、AAC、OPUS等，但對于PSTN，使用SIP_TRUNK方式對接的語音編碼，目前三大運營商，電信、聯(lián)通和移動，僅支持G711A、G711U、G729等編碼。

RTC采樣率都是16K、48K，PSTN一般為8K。

組包間隔，語音數(shù)據(jù)包發(fā)送的時候需要以一定的時間間隔來周期進行發(fā)送，比如說像QQ支持20毫秒、40毫秒、60毫秒的間隔發(fā)送，PSTN基本上是20毫秒。

語音質(zhì)量，對于VOIP會有很多相應(yīng)的語音的優(yōu)化手段，但是PSTN是專用網(wǎng)絡(luò)，網(wǎng)絡(luò)質(zhì)量相對高，丟包較少，優(yōu)化的手段也比較少。

RTC除了1對1絕大多數(shù)場景是支持多人，比如說純視頻、純語音通話可以支持客戶端混音和服務(wù)端混音，但是手機端基本上是1V1。多人會議是多個人，但是手機端是不支持同時接收多路碼進行混音的，必須要混好成一路后，才能下發(fā)給手機。顯然這是兩者之間的差異。

融合方法　　

有這么多的差異，我們有沒有方法把兩者結(jié)合起來呢?我們就要找一個突破口——求同存異，適配融合。

剛才說的是差異的地方，有沒有相同的地方呢?PSTN經(jīng)過長時間的發(fā)展，可以把PSTN專用網(wǎng)絡(luò)的信令流和數(shù)據(jù)流通過SIP_TRUNK的方式在Internet上面?zhèn)鬏敚@就是一個相同的地方。這個地方存在的突破口，存在可以融合的點。剩下對其它不同的部分進行融合適配，即對音頻碼流和信令協(xié)議進行適配。

我們?nèi)诤系姆绞降膶崿F(xiàn)有兩種，第一種是讓QQ客戶端去適配PSTN的差異，第二種是讓PSTN去適配VOIP的差異。首先PSTN是國際通用的標準，讓它適應(yīng)VOIP眾多的編碼和私有協(xié)議，那么現(xiàn)在的手機設(shè)備肯定要更新升級，這顯然不大現(xiàn)實。另外一種就是讓QQ去適應(yīng)PSTN的差異。QQ同樣有歷史包袱，他發(fā)展了那么多年，如果支持RTP和SIP改動也很大，開發(fā)周期也是非常漫長的。即然這兩種方法都不行，我們就想到新增一個中間模塊去分別適配VOIP和PSTN的差異。這個模塊我們稱之為適配層，可以放到Internet上，讓VOIP和PSTN協(xié)議互轉(zhuǎn)和碼流互轉(zhuǎn)。適配層有兩個主要功能，一個是對信令的適配，還有一個是對碼流的適配。

最終系統(tǒng)架構(gòu)圖　　

最上面一部分是實時音視頻對外提供的OpenSdk，它跟QQ的音視頻內(nèi)核是一樣的，只是去掉了QQ那些特殊的業(yè)務(wù)邏輯，它目前支持安卓、IOS、windows、web SDK，基本上是全終端?？蛻舳诵帕畎l(fā)向后臺互動直播系統(tǒng)，首先經(jīng)過信令處理模塊App，進行機器調(diào)度分配要經(jīng)過Info，由于我們整個過程都是要動態(tài)自適應(yīng)調(diào)整，會有一個流控模塊。然后這個信令會轉(zhuǎn)到一個信令適配模塊，我們叫會控。而碼流的適配、編碼的轉(zhuǎn)換，有一個模塊就是混音。因為手機端不具備多路混音的能力，所以我們必須在服務(wù)端進行混音，這樣將多人的碼流混成一路發(fā)給手機端，手機端就能聽到多個人的聲音了。

下面那部分進入PSTN網(wǎng)絡(luò)，會控把QQ私有協(xié)議轉(zhuǎn)換成內(nèi)部私有協(xié)議，通過PSTN策略進行一系列的分配策略，再通過處理信令的sip_server將內(nèi)部私有協(xié)議轉(zhuǎn)換成標準的SIP協(xié)議和運營商的SIP_SERVER相通，同理將對應(yīng)的碼流通過混音和proxy轉(zhuǎn)成標準rtp碼和運營商媒體Svr相通?！　?/p>

重點說一下混音，從QQ的私有協(xié)議轉(zhuǎn)到標準的RTP協(xié)議還算比較容易，但編碼轉(zhuǎn)換就要復(fù)雜很多。因為手機端不具備混音的能力，所以我們這部分不像VOIP客戶端可以客戶端混音，手機端必須要在服務(wù)端混好才能下發(fā)一路碼流給手機端。我們是采用服務(wù)端混音，如有多個VOIP進行互相通話的時候會同時發(fā)多路音頻流，由外網(wǎng)傳輸?shù)交煲艉笈_，首先會選路操作。選路是指在多個說話的人里面最多選幾路語音流來進行混音操作，比如說QQ語音通話最多選六路。主要原因，第一個是說話的人多了大家聽不清楚，第二人就是選擇的語音流路數(shù)越多越消耗服務(wù)器資源，這樣一臺服務(wù)器就支持不了多少人了。選路之后，就要進行解碼，解碼完再進行重采樣，然后再進行混音，之后就要編碼，然后再通過Proxy進行傳輸最后會傳輸?shù)竭\營商的媒體SVR，最后到運營商網(wǎng)絡(luò)，就可以下發(fā)到手機端，這樣就實現(xiàn)了手機端也可聽到多路語音的功能。

系統(tǒng)優(yōu)化　　

因為是語音通話，所以系統(tǒng)上線之后，在語音上面增強必不可少。手機端的語音增強手段比較有限，因為它在運營商的公共網(wǎng)絡(luò)相對外網(wǎng)質(zhì)量好很多，少抖動和少丟包。在VOIP端由于直接是外網(wǎng)，所以要做的語音質(zhì)量優(yōu)化比較多。比如說語音采樣之后，會進行回音消除和降噪。為了避免抖動會引入jitterbuffer，jitterbuffer有一定緩存包它有一定大小，如果在緩存范圍外的丟包，則要通過PLC進行補包。還有為了節(jié)省帶寬我們會做VAD，如果VOIP端長期不說話的時候，我們可以不發(fā)完整的靜音包，可以會發(fā)特殊的EOS包，包大小會非常小，這樣可以節(jié)省帶寬。網(wǎng)絡(luò)質(zhì)量是隨時動態(tài)變化的，所以我們要進行自適應(yīng)調(diào)節(jié)，以2秒為一個單位來，實時統(tǒng)計一下當前網(wǎng)絡(luò)的超時率、丟包、抖動情況，綜合調(diào)節(jié)客戶端的采樣率和碼率?！　?/p>

因為是實時音視頻，所以低延時是重中之重。在外網(wǎng)傳輸，延時大部分引入很多是在媒體SVR的分配上面。如在不同運營商的延時會有10到25毫秒延時，而且不同的運營商某些城市可能會有丟包，不同的機房網(wǎng)絡(luò)延遲差不多是20到35毫秒，如果直接外網(wǎng)，易抖動、質(zhì)量不穩(wěn)定。對于這些問題，我們可能通過調(diào)度分配來解決，我們盡量將媒體SVR分配到同一運營商，盡量分配到同機房。對于有條件的地方可以直接專線連接。　　

抗網(wǎng)絡(luò)丟包有兩種方法，第一種是ARQ自動重傳。我們每一個媒體節(jié)點都是采用UDP來傳輸且每一個媒體節(jié)點都會緩存一定數(shù)量的音頻包，每個音頻包里面會有一個序號，接收客戶端收包時會根據(jù)包中的序列號判斷是否是連續(xù)的，如果不是則有丟包，此時會去它的前一個媒體節(jié)點問一下，緩存中有沒有這個包，有的話就直接重發(fā)一次，沒有的話，它就再向前一個節(jié)點問一下，如果所有中間節(jié)點都沒有就會一直問到發(fā)送端，發(fā)送端再把這個包再傳一次。ARQ明顯缺點是增加延遲。

第二種是FEC，發(fā)送端在發(fā)音頻包的時候，可以多發(fā)幾個冗余包。接收到如果發(fā)現(xiàn)音頻包丟了，而冗余包沒有丟，則會嘗試使用冗余包把音頻包恢復(fù)。增加FEC也是動態(tài)的，當網(wǎng)絡(luò)質(zhì)量不好會多加一些冗余包，反之則會少加一些?！　?/p>

最后一個是提高系統(tǒng)可用性。只要是大規(guī)模的應(yīng)用或系統(tǒng)，這是必不可少的要解決的問題，解決這個問題簡單來說就兩個方面，第一個是增加冗余資源，第二是實現(xiàn)自動切換。機器冗余可以多運營商部署、多機房部署，多地部署，自動切換則是死機時可以自動切換、IDC異常時可以自動屏蔽出問題的IDC、自動屏蔽出問題的資源等方式。

五、音視頻AI技術(shù)落地實踐　　

現(xiàn)在AI技術(shù)廣泛應(yīng)用在各領(lǐng)域，音視頻領(lǐng)域就是典型。云+技術(shù)沙龍請到騰訊視頻云高級工程師孫祥學(xué)老師帶來《音視頻AI技術(shù)落地實踐》的分享。

視頻+AI碰撞的結(jié)果　　

視頻+AI的第一種應(yīng)用是極速高清。極速高清是在不降低視頻質(zhì)量的前提下壓縮視頻碼率，降帶寬，降成本。它跟AI的結(jié)合點在于智能場景的識別。傳統(tǒng)的編碼是不區(qū)分視頻類別的，而極速高清能借助AI識別出視頻分類和場景針對性優(yōu)化。

第二種應(yīng)用是云剪輯，一邊進行視頻編輯、貼片、生成字幕等處理，另一邊可實時預(yù)覽，處理完之后可以導(dǎo)出分發(fā)到各個平臺。

第三種應(yīng)用是視頻的智能識別和分析，主要包括智能識別、智能編輯和智能審核?！　?/p>

智能識別是把視頻里的目標人物識別出來，把語音識別成文字，把視頻里面所有出現(xiàn)的文字識別出來，還有識別出來LOGO、臺標之類的物體，等等。

智能審核，包括涉黃、涉政、涉暴畫面的檢測和字幕審核、語音審核。

智眸：視頻智能識別和分析平臺　　

騰訊智眸智能媒體生產(chǎn)平臺。它包括基礎(chǔ)服務(wù)層、AI引擎層、媒體處理層、基礎(chǔ)應(yīng)用層、基礎(chǔ)產(chǎn)品層?！　?/p>

智眸衍生出來三大產(chǎn)品線，包括智能識別、智能編輯、智能審核。我們在云官網(wǎng)上有相應(yīng)的API接口，可以組合調(diào)用來滿足自己的實際應(yīng)用場景?！　?/p>

智能識別系統(tǒng)的架構(gòu)分四層，有對外接入、邏輯處理、模型識別和數(shù)據(jù)層。這個系統(tǒng)大概的執(zhí)行流程是：首先進行用戶庫管理，包括人臉入庫、敏感詞的管理;接下來可以驗證入庫目標人物是否支持檢索;第三步是提交視頻處理任務(wù)，分別進行截圖處理、音頻處理、識別上報，策略層是基于配置和上報的數(shù)據(jù)進行整合過濾，然后返回結(jié)果。

同時要做公有云、私有云的一體化部署，因為很多的客戶希望敏感資源不要上公有云，所以有私有化的需求。　　

視頻處理也是系統(tǒng)的核心，這套多媒體處理框架，從(PPT左邊)是文件輸入(包括點播、直播、本地文件)，一般的流程是解封裝、讀取壓縮數(shù)據(jù)，然后解碼分別生成視頻截圖和音頻PCM數(shù)據(jù)。因為對端ASR引擎對輸入是有要求的，所以要統(tǒng)一做重采樣、轉(zhuǎn)碼、分片等。完了把所有的截圖、音頻分片放到各自的線程隊列里去，然后每張圖要同時進行所有的識別，然后把所有的識別結(jié)果進行統(tǒng)一上報。音頻是獨立的，按固定間隔發(fā)送給ASR引擎即可。

結(jié)合實用場景，還要做一些應(yīng)用場景優(yōu)化?！　?/p>

騰訊優(yōu)圖人臉識別有一個入庫的過程，即把所關(guān)注的目標人物人臉圖片通過特征提取入庫。人臉檢索處理衍生出來三種場景：建庫檢索是第一種;第二種是歷史掃描，比如要去從前面處理過的視頻中找出之前沒有入庫的目標人物;第三是無庫檢索，像監(jiān)控場景中需要找到某人第一次出現(xiàn)到最后一次出現(xiàn)的時間點。

還有幾點場景優(yōu)化，因為視頻是連續(xù)的，假如說現(xiàn)在某某出席某某會議，我如果知道這個名字在視頻語音里面出現(xiàn)，那他在下面視頻里出現(xiàn)的概率會比較高，我會進行一個ASR參考降低附近人臉相似度過濾閾值。OCR也是類似的，某個會議上有一個人截圖前面出現(xiàn)印有該目標人物人名文字的臺標，也可以類似處理，視頻中只看到側(cè)臉導(dǎo)致相似度分值比較低，我可以根據(jù)OCR人名把人臉相似度過濾值降低進行召回。再例如，一個人出席某個會議，從進入到結(jié)束不是一直看到正臉，可能是側(cè)臉，正臉、側(cè)臉，在庫里掃描的相似度分值可能是67、98、78。如果我連續(xù)時間參考序列上出現(xiàn)一個分值比較高，兩邊比較低的場景，我會把兩邊分值較低的時間點召回。

還有一點是無縫升級處理，人臉檢索引擎也會迭代，之前的庫提取出來人臉向量可能就用不上了，因為在新的庫里面向量維度都變了無法檢索，沒有參考意義，怎么樣讓用戶無感知做到無縫升級呢?我們把數(shù)據(jù)層做了多版本化的處理，我升級的時候用新版本庫，把之前舊版本庫提交的圖片去做一次提取，一旦兩個庫滿足一致性之后，即可支持新版本人臉庫的檢索。我先做一套類似于伴隨系統(tǒng)，兩庫同時跑，提取完之后做一個策略切換熱重啟即可完成升級?！　?/p>

語音識別也作了前置處理。對于點播視頻先做一個離線的VAD處理，把語音活動部分檢測出來，送到引擎端識別，減少靜音包識別帶來的網(wǎng)絡(luò)的負載，并可進行多線程識別加速?！　?/p>

按照固定間隔截圖，全部丟給后端引擎識別，后端引擎的壓力會很大。所以我們做一些過濾，對比多種圖片相似度檢測算法，做一個簡單的像素值的統(tǒng)計直方圖即可以達到過濾效果，且速度上有一定的優(yōu)勢。還有指定區(qū)域處理，在引擎識別之前先裁剪我關(guān)心的那部分，縮小文字區(qū)域檢測面積，最后會快很多?！　?/p>

對于視頻集錦的處理，比如進球集錦，通過R-C3D模型處理后會輸出很多可選時間段，加上非極大值抑制處理，再結(jié)合VAD處理讓剪出來的片段平滑一些?！　?/p>

新聞拆條是把幾十分鐘視頻所有的新聞片段都拆出來做分發(fā)，方便互聯(lián)網(wǎng)用戶點擊。處理邏輯是把關(guān)鍵幀檢測出來，檢測視頻是否切到導(dǎo)播臺，再做一個人臉檢測，看導(dǎo)播臺現(xiàn)在有多少人?如果有0個的話我就認為是轉(zhuǎn)場，1個的話就可能是引入新聞?；趦蓚€模型的綜合，最后根據(jù)人臉檢測得到一個時間序列，這樣就自然把片斷拆出來，30分鐘的新聞當中每個新聞事件做一個拆條，從而進行短視頻的分發(fā)。

人物拆條，某個領(lǐng)導(dǎo)人出席某個會議，我只想把我自己出現(xiàn)的那個片段剪出來。片頭片尾拆條，我們在視頻軟件上可以看到，自動跳過片頭片尾，一般是vip特權(quán)，現(xiàn)在大部分是人工處理的，如果能自動識別片頭片尾會降低很多的人工成本。

應(yīng)用場景

視頻+AI的應(yīng)用場景有：

媒資管理，做識別之后知道哪些視頻里面有哪些明星。

視頻搜索推薦，識別之后知道這個視頻屬于哪一類，是娛樂類還是搞笑類等等。

直播流監(jiān)控、電臺監(jiān)控，就是涉黃、涉暴、涉政的檢測，如果直播流有一些敏感的東西可以直接斷掉。

視頻審核。

跳過片頭片尾。

實時字幕。例如把主播的語音直接識別出來生成字幕加入到直播流中等。

尾聲

此次現(xiàn)場開發(fā)者的熱情超出了我們的想象，相信這樣一個干貨滿滿的技術(shù)沙龍，一定給現(xiàn)場的所有參會者都帶來了新的思考。讓我們更加有理由期待，未來，音視頻及融合通信技術(shù)，一定會更加深入到我們的日常生活中來。

現(xiàn)場花絮　　

生成海報

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責(zé)任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。