音視頻融合通信技術(shù)的最佳實(shí)踐，全在這里了

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

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

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

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

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

連麥直播概述

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

　　(連麥基本原理)

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

延時(shí)　　

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

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

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

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

回聲

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

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

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

畫(huà)面混合

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

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

騰訊云連麥直播實(shí)踐--MLVBLiveRoom

在過(guò)去的幾年里騰訊云使用了非常多的技術(shù)手段來(lái)解決連麥中遇到這些問(wèn)題，并且將這些技術(shù)方案打磨好，實(shí)現(xiàn)了MLVBLiveRoom方案。　　

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

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

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

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

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

XP2P簡(jiǎn)介

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

XP2P產(chǎn)品功能

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

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

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

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

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

做P2P的時(shí)候不應(yīng)該探測(cè)帶寬，因?yàn)檫@會(huì)發(fā)很多包，對(duì)帶寬來(lái)說(shuō)是一種浪費(fèi)，所以應(yīng)該使用自然探測(cè)。還有一點(diǎn)，P2P要使用TCP剩下的帶寬，要公平競(jìng)爭(zhēng)，而不是肆意搶占TCP帶寬。因?yàn)門(mén)CP存在著啟動(dòng)慢、擁塞控制差、抗抖動(dòng)差、重傳歧義等問(wèn)題，相比之下XNTP就具有快速啟動(dòng)、基于合理建模的數(shù)學(xué)公式的速率控制、以及丟包率反饋傳輸速率、雙序號(hào)包索引等優(yōu)勢(shì)。　　

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

XP2P的應(yīng)用場(chǎng)景

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

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

XP2P的未來(lái)與展望　　

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這是一個(gè)標(biāo)準(zhǔn)化的一體化方案，這種方案的特點(diǎn)是雙端用戶(hù)自己控制，只需推RTMP流過(guò)來(lái)由騰訊分發(fā)，支持RTMP、DASH、HLS通過(guò)不同的碼分發(fā)。另外，我們也支持用戶(hù)自建源站，騰訊云進(jìn)行回源分發(fā)，這個(gè)在新聞資訊分發(fā)場(chǎng)景比較多。　　

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

精細(xì)化運(yùn)營(yíng)

系統(tǒng)做好了就相當(dāng)于做到了90分，后期要通過(guò)精細(xì)化的優(yōu)化和運(yùn)營(yíng)實(shí)現(xiàn)95、99分。精細(xì)化運(yùn)營(yíng)也涉及一些問(wèn)題?！　?/p>

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

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

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

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

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

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

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

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

實(shí)時(shí)音視頻與PSTN融合的背景　　

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

常見(jiàn)的QQ語(yǔ)音通話和視頻通話，兩個(gè)QQ客戶(hù)通過(guò)外網(wǎng)發(fā)起語(yǔ)音通話，一般處理會(huì)分為兩個(gè)部分，一個(gè)是信令層的處理，一個(gè)是碼流層的處理。

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

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

RTC與PSTN差異　　

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

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

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

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

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

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

融合方法　　

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

智能識(shí)別是把視頻里的目標(biāo)人物識(shí)別出來(lái)，把語(yǔ)音識(shí)別成文字，把視頻里面所有出現(xiàn)的文字識(shí)別出來(lái)，還有識(shí)別出來(lái)LOGO、臺(tái)標(biāo)之類(lèi)的物體，等等。

智能審核，包括涉黃、涉政、涉暴畫(huà)面的檢測(cè)和字幕審核、語(yǔ)音審核。

智眸：視頻智能識(shí)別和分析平臺(tái)　　

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

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

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

同時(shí)要做公有云、私有云的一體化部署，因?yàn)楹芏嗟目蛻?hù)希望敏感資源不要上公有云，所以有私有化的需求。　　

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

結(jié)合實(shí)用場(chǎng)景，還要做一些應(yīng)用場(chǎng)景優(yōu)化。　　

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

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

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

語(yǔ)音識(shí)別也作了前置處理。對(duì)于點(diǎn)播視頻先做一個(gè)離線的VAD處理，把語(yǔ)音活動(dòng)部分檢測(cè)出來(lái)，送到引擎端識(shí)別，減少靜音包識(shí)別帶來(lái)的網(wǎng)絡(luò)的負(fù)載，并可進(jìn)行多線程識(shí)別加速?！　?/p>

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

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

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

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

應(yīng)用場(chǎng)景

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

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

視頻搜索推薦，識(shí)別之后知道這個(gè)視頻屬于哪一類(lèi)，是娛樂(lè)類(lèi)還是搞笑類(lèi)等等。

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

視頻審核。

跳過(guò)片頭片尾。

實(shí)時(shí)字幕。例如把主播的語(yǔ)音直接識(shí)別出來(lái)生成字幕加入到直播流中等。

尾聲

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

現(xiàn)場(chǎng)花絮　　

生成海報(bào)

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