6月29日，云+社區主辦的技術沙龍-“音視頻及融合通信技術”在北京成功舉辦，騰訊云經過多年的技術沉淀，并結合自身的最佳實踐，引領了現場近300位開發者關于“音視頻”技術的不一樣的思考。
以下為本次沙龍的現場演講摘要：
一、移動直播連麥技術實踐
首先聚焦在直播場景下，在當前這個全民直播的時代，連麥逐漸成長為直播領域非常重要的業務場景之一，但是網絡往往是不穩定的，那么如何在網絡不可控及弱網的情況下來保證高質量的連麥通訊服務呢？騰訊高級工程師蔣磊現場為大家闡述了騰訊在這方面的最佳實踐。
連麥直播概述
連麥直播與普通直播的區別在于，后者類似單口相聲，一個直播表演很多觀眾看；連麥直播是對口相聲和群口相聲，有大主播和小主播，普通觀眾看大主播和小主播的畫面。
（連麥基本原理）
不過往往理想很美好，現實卻很骨感。在技術實現上并非嘴上說說就可以了，連麥直播通常會遇到這三類問題：延時、回聲和混流。
延時
普通直播的延時主要來自于轉碼處理過程中產生的百毫秒級別的延時，以及CDN延時。
因為CDN回源的工作機制，在H.264這種GOP編碼方式下，回源必須拿到GOP的I幀（關鍵幀）才能分發。通常情況下CDN引入的延時就有1-3秒，因此要解決普通直播引入的延時，最好的解決辦法就是不走CDN。
解決辦法就是使用UDP協議，由主播端推流到upload，upload拉流至rtmp-acc節點，然后小主播再從rtmp-acc節點獲取數據，同樣的，小主動將將流推到upload上并讓大主播從rtmp-acc上拉。內部都走高速專線，所以整體延時會很低。通過UDP加速這樣的方式，可以實現大主播到小主播之間500毫秒以內的延時。
當然還有一部分延時來自網絡。網絡總是處于波動的狀態，或多或少會有丟包的情況出現。這里的解決方案就是通過 jitterbuffer 這樣的蓄水池平滑數據流來實現。因為網絡傳輸過程中會有不均勻的抖動，數據會在 jitterbuffer 緩存一下再給到解碼器，在實際直播里可以將 jitterbuffer 設置在200毫秒左右，但是這樣又需要處理 jitterbuffer 累積延時問題。因為技術上通過jitterbuffer實現了緩沖，但客觀上網絡還是抖動的，而jitterbuffer這個“蓄水池”只有蓄滿了才會往下一步送數據，所以一旦網絡一直抖動，延時就會不斷增加，為了解決這個問題我們就必須要修正累積的延時。在騰訊云的LiteAVSDK中，播放器已經做好的累積延時的修正。
回聲
回聲是另外一個最常遇到的問題，回聲通常會分為兩類，第一類是線路回聲，一般由硬件廠商自己解決；另一類就是聲學回聲。
聲學回聲的原理是什么？當原聲傳到對方揚聲器播放之后，被對方的麥克風再采集一次，通過通信線路傳回來再次播放，大主播就會聽到自己的聲音。而且人的耳朵特別靈敏，超過10毫秒以上的回聲就能被分辨出，而通信線路的延時往往在50毫秒以上，因此回聲必須要做消除。
依上圖所示，為了解決回聲，將播放器播放的音頻數據與麥克風采集的音頻數據進行波形比對，反向把波形消掉，這個過程就叫AEC。騰訊云已經AEC功能在LiteAVSDK中內置，開發者無需再額外編程，可以直接使用。
畫面混合
畫面混合分為客戶端與云端，客戶端即大小主播相互之間要看到的畫面，有兩個部分，一個是自己本地的預覽，另一個是拿到的對方數據畫面。本地預覽相對比較簡單，只要播放器支持多實例就可以搞定了。
在云端，混流的模塊從upload拿到數據之后按照設定的參數分層疊加，再通過CDN分發，就是云端混流。云端混流可以極大減輕客戶端播放的壓力。騰訊云可以同時最大支持16路混流，輸入源可以是純音頻、視頻、畫布和圖片。
騰訊云連麥直播實踐--MLVBLiveRoom
在過去的幾年里騰訊云使用了非常多的技術手段來解決連麥中遇到這些問題，并且將這些技術方案打磨好，實現了MLVBLiveRoom方案。
MLVBLiveRoom基于LiteAVsdk+IMSDK，結合騰訊云云直播和云通信IM服務，從普通的直播，到連麥直播、跨房PK都在一個組件里直接搞定；通過在騰訊云的云端提供的房間管理服務，普通開發者不需要再考慮過多房間狀態和房間管理的細節；同時基于優圖實驗室的P圖技術可以實現人臉AI特效及視頻動態特效；并且它的接入做得足夠簡單，普通開發者半天時間就可以跑通整個流程。
除此之外，MLVBLiveRoom通過儀表盤數據把底層的音視頻數據回調給開發者，開發者可以通過onNetStatus拿到直播過程最直接的數據，從而更方便地實現線上業務的監測與運維。
除了MLVBLiveRoom之外，為了解決連麥直播中普通觀眾的上下麥平滑切換問題，騰訊云還實現了TRTC低延時大房間的方案，讓主播和觀眾們都統一加入到同一個低延時大房間里面，每一個用戶都通過UDP的方式推流和播放，這種方式可以實現極低延時，主播之間最低可以到100毫秒，普通觀眾的延時可以控制在1000毫秒以內。
二、騰訊云直播PCDN加速方案
直播場景音視頻的流暢度直接關系到用戶的體驗感受。騰訊云P2P是業內領先成熟的P2P產品，其中多個產品線已經成熟，現在已經推廣到斗魚、企鵝、電競、英雄聯盟等各個不同的平臺。云+社區技術沙龍請到了騰訊XP2P負責人張鵬現場為開發者帶來了《騰訊直播PCDN加速方案》的分享。
XP2P簡介
P2P簡單而言，就是你有我有大家都有的東西，我們可以通過網絡相互連接來分享之。P2P架構體現了互聯網架構的核心技術，因此這種概念被描述在RFC 1里面，可謂由來已久，是早期互聯網建設者心中最夢寐以求的架構。從2014年到現在經歷了5年的打磨完善，產品也非常的穩健成熟，覆蓋Android、IOS、H5、PC等各種平臺，它有更多的節點進行加速，延遲也是等同于CDN甚至優于CDN的起播速度，在S8賽事期間峰值達到8T，經歷了大規模的直播活動的檢驗，同時也見證了flash由盛轉衰的過程。
XP2P產品功能
騰訊云XP2P，是為了滿足直播需求的帶寬和延遲而開發出來的。技術上，首先P2P所有的節點都要有數據一致性。對于視頻來說就涉及到視頻流的切片。過去的技術是無法在原始直播流上進行切片的，現在切片操作對直播流無任何損害，完全不修改它里面的mux信息和codec信息。
這種方式跟FLV流合成一體，P2P的數據可以直接交給播放器，對視頻內容的侵入性可以做到非常完美。用這樣的方式還可以實現自適應碼率，是比HLS、Dash還要領先的技術。
P2P的客戶端首先要做穿透。當前的互聯網有NAT（網絡地址轉換），就是說公網地址不夠，局域網上用內網地址在發送請求的時候，加一個斷口標識這個請求。這帶來的一個問題是A知道B的地址但是無法連接，會直接被NAT阻止。
STUN協議是P2P打洞建立起連接的核心協議。進入互聯網之后之后STUN有一個連接圖。首先向STUN公網連接，如果沒有收到則說明對方有防火墻，如果收到了就可以看公網地址和內網地址是否一樣，如果一樣說明前面沒有NAT，它是公網地址。接下來向服務器發一個包，讓服務器換一個IP地址給我回包，如果收到的話就是一個真正的公網地址，如果沒收到是因為前面有一個防火墻。
如果公網地址跟內網地址不一樣，說明里面有一個NAT。首先請求原來的服務器換一個地址回消息。如果這個消息收到了就是公網地址，收不到的話說明是一個限制性的，或者對稱型的。接下來就是由STUN再去請求，注意這個請求是用同一個內網請求，然后看返回的地址和第一次返回的官網地址是否一樣，如果不一樣的話就是對稱型的；如果一樣接下來需要再探測是ID限制型還是端口限制型，然后再朝這個服務器換一個端口回消息，如果能收到就是ID限制型，如果收不到消息就是端口限制型。
做P2P的時候不應該探測帶寬，因為這會發很多包，對帶寬來說是一種浪費，所以應該使用自然探測。還有一點，P2P要使用TCP剩下的帶寬，要公平競爭，而不是肆意搶占TCP帶寬。因為TCP存在著啟動慢、擁塞控制差、抗抖動差、重傳歧義等問題，相比之下XNTP就具有快速啟動、基于合理建模的數學公式的速率控制、以及丟包率反饋傳輸速率、雙序號包索引等優勢。
XNTP的Pacing發送可以選擇均勻發送，一個RTT是40毫秒，發40個包，每一毫秒發一個包，這樣對路由器非常均勻，就可以更少丟包的同時把網絡利用上去。
XP2P的應用場景
對于P2P的應用場景，無論是直播、點播、文件都是適用的，文件適合大文件的分發。對于4K視頻加速，有P2P的助力，4K體驗會更勝一籌。尤其對于大型直播活動比如說賽事、春節聯歡晚會，是非常適合P2P來提高質量節省帶寬的。對于短視頻、常規視頻，更是P2P加速的強項。對于大規模、大文件的分發也可以用P2P，其原理類似點播視頻的P2P。
P2P接入也非常簡單，先是注冊騰訊云在云官網開通，通過騰訊云的官網下載SDK并接入，雖然不似某些云廠商吹噓的一行就接入，但是花個10行，也是能夠完美接入的，然后測試上線然后運維，非常簡單，還會有專人對接。
XP2P的未來與展望
騰訊云X-P2P某種意義上實現了多播協議，即優化了網絡質量，又降低了網絡的負載；而456（4K、5G、IPv6）的到來，將會使X-P2P進一步發揮能力和得到更廣泛的應用；區塊鏈的底層所使用的P2P技術和騰訊云X-P2P有異曲同工之妙，然而libp2p除了搞了一堆不必要的概念，還沒有看到怎么接觸到穿透的核心技術；邊緣計算也將依賴穩健、安全、高效的P2P技術底層；XNTP傳輸協議如果再優化一下，甚至將可以和quic相提并論；最終，X-P2P可能回歸最初的夢想，在互聯網上產生出徹底去中心化的服務模式。
三、騰訊視頻云海外直播系統架構設計與最佳實踐
近幾年國內視頻直播市場逐漸疲軟，越來越多的廠商開始涉足海外直播。云+社區技術沙龍請到騰訊高級技術專家，海外直播技術負責人胡仁成老師分享《騰訊視頻云海外直播系統架構設計與最佳實踐》。
海外直播系統在應用軟件層面跟國內沒有太大的區別。直播系統架構包含三大塊，一是公有云和網絡基礎設施的建設；第二是在此基礎設施上架設軟件系統，實現直播流媒體的分發；第三，在已完成的系統上更深入化優化。
海外網絡與機房建設
當前騰訊云在全球的網絡布局從地域分為三大區，北美、亞太（香港、新加坡）、歐洲（德國）。海外大概接近2千家運營商。要完成這2千家運營商的互聯不可能每家都進行直接互聯。
按運營商的級別可以劃分為三類Tier1、Tier2、Tier3。Tier1是跨大區跨州互聯的，Tier2是區域互聯的，Tier3是國家內部覆蓋，一般是面向終端用戶提供網絡服務的運營商。在海外還要布局很多加速點，如下圖所示：
海外直播系統建設
直播需要低延時、低卡頓，根據這個原則所有的流系統不能部署在同一個地方。因此需要采取去中心化的方案，在已有DC的機房都會部署一個源站系統。
每一個源站都會包含流媒體接入的能力，同時部署轉碼、錄制、截圖、存儲和CDN分發能力。去中心化的設計方案很適合本地化直播服務，主播的流推到最近的源站，質量更好。
下面的問題是狀態同步，比如說巴西的主播推了流上來，中國的觀眾看的時候怎么樣找到巴西主播的流在哪？挑戰很大。
第一個要求是雙活，我們自研了一套狀態組件，去滿足我們提出的一些能力的要求。其中，我們選擇通過間隔心跳保持數據同步的最終一致性，它有一個容忍的尺度和閾值，這個根據業務特點去調優。
第二個要求就是同步方案，這里狀態同步的思想遵循95%本地分發的原則，9個大源站的狀態并不是互相同步。通過挑選集中點，把海外其它7個源站同步到香港，然后再從香港到國內；小的源站查一下香港就可以，這樣減少了設計開發的復雜度。
去中心化設計又引入了另外一個問題就是如何實現跨區拉流，有5%的用戶要看美國的流怎么辦？這時候就要保證這一整條鏈路的服務質量，狀態一定要準；狀態同步過去之后還要保證回源鏈路的穩定性，在核心鏈路上鋪設回源專線，走騰訊云的內網專線。
這是一個標準化的一體化方案，這種方案的特點是雙端用戶自己控制，只需推RTMP流過來由騰訊分發，支持RTMP、DASH、HLS通過不同的碼分發。另外，我們也支持用戶自建源站，騰訊云進行回源分發，這個在新聞資訊分發場景比較多。
海外直播另一個特點是對版權保護的需求。騰訊云也提供了一個基于iOS和安卓系統的DRM方案，支持Widevine和Fairplay。
精細化運營
系統做好了就相當于做到了90分，后期要通過精細化的優化和運營實現95、99分。精細化運營也涉及一些問題。
這些問題總體分三類，第一是騰訊海外直播系統自動化運維、監控的能力的構建；第二是如何解決海外調度復雜的問題；第三是如何解決網絡設施落后的國家跨區傳輸以及最后一公里的視頻流傳輸和優化問題。
首先是全方位監控系統。騰訊云能在一秒或者五秒以內感知到某個業務流量突長，并且能夠在增長的過程中自動化擴展更多服務節點或服務帶寬給它承載。我們的監控能精細到每個國家每個運營商的AS號，看它的丟包率，延時等技術指標，然后找團隊去優化。在應用層面我們有自動化的監控系統能夠實時發現哪些機器宕掉了，實時把異常節點剔除掉。
第一，如果巴西的丟包率很高，為了解決TCP由于丟包導致傳輸速率不穩或者下降的問題我們選擇采用Quic方案。我們設計開發了一套TCP和QUIC互相轉換的協議插件，這里接受用戶的RTMP流，然后轉化成Quic傳輸到美國的源站，再把它剝離成RTMP推到美東的源站。這中間用了Quic加速，優化了中間鏈路弱網的問題。上行優化之后，卡頓率從6.5%降到4.8%。
第二步優化了下行回源鏈路，下行回源也用了類似的Quic代理做了協議轉換，卡頓率從4.8%降到3.6%。
做最后一公里邊緣協議站的優化時，騰訊自營了一套類似于BBR，但克服了BBR的缺陷的方案，叫QTCP，在最后一公里優化了弱網傳輸的問題，整體卡頓率降低了20%。
另外，海外直播系統設計還需要考慮在綜合成本的限制下取得一個邊際收益的最大值，這是我們目前做海外直播的一個重要的思路。
四、實時音視頻與PSTN結合的解決辦法
如今，融合通信技術顯得愈加重要。融合通信技術具體是指什么？云+技術沙龍請到騰訊云通信平臺高級工程師顏學偉老師帶來《實時音視頻與PSTN結合的解決辦法》的分享。
實時音視頻與PSTN融合的背景
實時音視頻通信（RTC）最主要的特點是“實時”，一般分為三個級別，延遲3秒以上是偽實時，1秒到3秒為“準實時”，真正的實時是1秒以內。騰訊云的實時音視頻可以做到300毫秒以下。
常見的QQ語音通話和視頻通話，兩個QQ客戶通過外網發起語音通話，一般處理會分為兩個部分，一個是信令層的處理，一個是碼流層的處理。
信令層主要用于通話的建立、連接、資源的準備，并協商碼流編解碼類型等相關信息，碼流層專注于音視頻數據處理。而實時音視頻要做到比較低的延時，我們在傳輸協議上直接選擇UDP，因為UDP雖然不可靠，但是它的性能比較高，相對于TCP少了三次握手和四次揮手。
因為外網的環境時好時壞，UDP又是不可靠的，在Internet傳輸音視頻數據時容易產生抖動，所以我們需要一個抗抖動的能力。當網絡質量不好產生丟包時，我們也需要一個抗丟包的能力。而且外網的質量波動比較大，也需要一種自適應的方式來動態調節發送的碼流，稱之為流控，就是隨時檢測主被叫雙方接收的包量，來計算丟包率、延時和碼率，用于來控制發送端的采樣率和發送的碼率，當時網絡質量不好時，我們可以把發送端的采樣率和碼率降低，減少發送的整體包量，進而減小網絡的擁堵。網絡質量好時，我們可以提高發送端的采樣率和碼率，增加發送的整體包量，會讓接收端有較好的語音質量。
RTC與PSTN差異
首先我們要看一下兩者的差異。實時音視頻我主要以QQ語音通話為例，剛才也說過一個完整的音視頻處理是要分很多步的，音頻采集、預處理、編碼、網絡傳輸、解碼和播放。網絡傳輸協議上，QQ語音通話是使用自己的私有協議，而PSTN使用的是標準的SIP+RTP協議，這是語音運營商采用的標準協議。
QQ支持的編碼有很多，有SILK、AAC、OPUS等，但對于PSTN，使用SIP_TRUNK方式對接的語音編碼，目前三大運營商，電信、聯通和移動，僅支持G711A、G711U、G729等編碼。
RTC采樣率都是16K、48K，PSTN一般為8K。
組包間隔，語音數據包發送的時候需要以一定的時間間隔來周期進行發送，比如說像QQ支持20毫秒、40毫秒、60毫秒的間隔發送，PSTN基本上是20毫秒。
語音質量，對于VOIP會有很多相應的語音的優化手段，但是PSTN是專用網絡，網絡質量相對高，丟包較少，優化的手段也比較少。
RTC除了1對1絕大多數場景是支持多人，比如說純視頻、純語音通話可以支持客戶端混音和服務端混音，但是手機端基本上是1V1。多人會議是多個人，但是手機端是不支持同時接收多路碼進行混音的，必須要混好成一路后，才能下發給手機。顯然這是兩者之間的差異。
融合方法
有這么多的差異，我們有沒有方法把兩者結合起來呢？我們就要找一個突破口——求同存異，適配融合。
剛才說的是差異的地方，有沒有相同的地方呢？PSTN經過長時間的發展，可以把PSTN專用網絡的信令流和數據流通過SIP_TRUNK的方式在Internet上面傳輸，這就是一個相同的地方。這個地方存在的突破口，存在可以融合的點。剩下對其它不同的部分進行融合適配，即對音頻碼流和信令協議進行適配。
我們融合的方式的實現有兩種，第一種是讓QQ客戶端去適配PSTN的差異，第二種是讓PSTN去適配VOIP的差異。首先PSTN是國際通用的標準，讓它適應VOIP眾多的編碼和私有協議，那么現在的手機設備肯定要更新升級，這顯然不大現實。另外一種就是讓QQ去適應PSTN的差異。QQ同樣有歷史包袱，他發展了那么多年，如果支持RTP和SIP改動也很大，開發周期也是非常漫長的。即然這兩種方法都不行，我們就想到新增一個中間模塊去分別適配VOIP和PSTN的差異。這個模塊我們稱之為適配層，可以放到Internet上，讓VOIP和PSTN協議互轉和碼流互轉。適配層有兩個主要功能，一個是對信令的適配，還有一個是對碼流的適配。
最終系統架構圖
最上面一部分是實時音視頻對外提供的OpenSdk，它跟QQ的音視頻內核是一樣的，只是去掉了QQ那些特殊的業務邏輯，它目前支持安卓、IOS、windows、web SDK，基本上是全終端。客戶端信令發向后臺互動直播系統，首先經過信令處理模塊App，進行機器調度分配要經過Info，由于我們整個過程都是要動態自適應調整，會有一個流控模塊。然后這個信令會轉到一個信令適配模塊，我們叫會控。而碼流的適配、編碼的轉換，有一個模塊就是混音。因為手機端不具備多路混音的能力，所以我們必須在服務端進行混音，這樣將多人的碼流混成一路發給手機端，手機端就能聽到多個人的聲音了。
下面那部分進入PSTN網絡，會控把QQ私有協議轉換成內部私有協議，通過PSTN策略進行一系列的分配策略，再通過處理信令的sip_server將內部私有協議轉換成標準的SIP協議和運營商的SIP_SERVER相通，同理將對應的碼流通過混音和proxy轉成標準rtp碼和運營商媒體Svr相通。
重點說一下混音，從QQ的私有協議轉到標準的RTP協議還算比較容易，但編碼轉換就要復雜很多。因為手機端不具備混音的能力，所以我們這部分不像VOIP客戶端可以客戶端混音，手機端必須要在服務端混好才能下發一路碼流給手機端。我們是采用服務端混音，如有多個VOIP進行互相通話的時候會同時發多路音頻流，由外網傳輸到混音后臺，首先會選路操作。選路是指在多個說話的人里面最多選幾路語音流來進行混音操作，比如說QQ語音通話最多選六路。主要原因，第一個是說話的人多了大家聽不清楚，第二人就是選擇的語音流路數越多越消耗服務器資源，這樣一臺服務器就支持不了多少人了。選路之后，就要進行解碼，解碼完再進行重采樣，然后再進行混音，之后就要編碼，然后再通過Proxy進行傳輸最后會傳輸到運營商的媒體SVR，最后到運營商網絡，就可以下發到手機端，這樣就實現了手機端也可聽到多路語音的功能。
系統優化
因為是語音通話，所以系統上線之后，在語音上面增強必不可少。手機端的語音增強手段比較有限，因為它在運營商的公共網絡相對外網質量好很多，少抖動和少丟包。在VOIP端由于直接是外網，所以要做的語音質量優化比較多。比如說語音采樣之后，會進行回音消除和降噪。為了避免抖動會引入jitterbuffer，jitterbuffer有一定緩存包它有一定大小，如果在緩存范圍外的丟包，則要通過PLC進行補包。還有為了節省帶寬我們會做VAD，如果VOIP端長期不說話的時候，我們可以不發完整的靜音包，可以會發特殊的EOS包，包大小會非常小，這樣可以節省帶寬。網絡質量是隨時動態變化的，所以我們要進行自適應調節，以2秒為一個單位來，實時統計一下當前網絡的超時率、丟包、抖動情況，綜合調節客戶端的采樣率和碼率。
因為是實時音視頻，所以低延時是重中之重。在外網傳輸，延時大部分引入很多是在媒體SVR的分配上面。如在不同運營商的延時會有10到25毫秒延時，而且不同的運營商某些城市可能會有丟包，不同的機房網絡延遲差不多是20到35毫秒，如果直接外網，易抖動、質量不穩定。對于這些問題，我們可能通過調度分配來解決，我們盡量將媒體SVR分配到同一運營商，盡量分配到同機房。對于有條件的地方可以直接專線連接。
抗網絡丟包有兩種方法，第一種是ARQ自動重傳。我們每一個媒體節點都是采用UDP來傳輸且每一個媒體節點都會緩存一定數量的音頻包，每個音頻包里面會有一個序號，接收客戶端收包時會根據包中的序列號判斷是否是連續的，如果不是則有丟包，此時會去它的前一個媒體節點問一下，緩存中有沒有這個包，有的話就直接重發一次，沒有的話，它就再向前一個節點問一下，如果所有中間節點都沒有就會一直問到發送端，發送端再把這個包再傳一次。ARQ明顯缺點是增加延遲。
第二種是FEC，發送端在發音頻包的時候，可以多發幾個冗余包。接收到如果發現音頻包丟了，而冗余包沒有丟，則會嘗試使用冗余包把音頻包恢復。增加FEC也是動態的，當網絡質量不好會多加一些冗余包，反之則會少加一些。
最后一個是提高系統可用性。只要是大規模的應用或系統，這是必不可少的要解決的問題，解決這個問題簡單來說就兩個方面，第一個是增加冗余資源，第二是實現自動切換。機器冗余可以多運營商部署、多機房部署，多地部署，自動切換則是死機時可以自動切換、IDC異常時可以自動屏蔽出問題的IDC、自動屏蔽出問題的資源等方式。
五、音視頻AI技術落地實踐
現在AI技術廣泛應用在各領域，音視頻領域就是典型。云+技術沙龍請到騰訊視頻云高級工程師孫祥學老師帶來《音視頻AI技術落地實踐》的分享。
視頻+AI碰撞的結果
視頻+AI的第一種應用是極速高清。極速高清是在不降低視頻質量的前提下壓縮視頻碼率，降帶寬，降成本。它跟AI的結合點在于智能場景的識別。傳統的編碼是不區分視頻類別的，而極速高清能借助AI識別出視頻分類和場景針對性優化。
第二種應用是云剪輯，一邊進行視頻編輯、貼片、生成字幕等處理，另一邊可實時預覽，處理完之后可以導出分發到各個平臺。
第三種應用是視頻的智能識別和分析，主要包括智能識別、智能編輯和智能審核。
智能識別是把視頻里的目標人物識別出來，把語音識別成文字，把視頻里面所有出現的文字識別出來，還有識別出來LOGO、臺標之類的物體，等等。智能審核，包括涉黃、涉政、涉暴畫面的檢測和字幕審核、語音審核。智眸：視頻智能識別和分析平臺
騰訊智眸智能媒體生產平臺。它包括基礎服務層、AI引擎層、媒體處理層、基礎應用層、基礎產品層。
智眸衍生出來三大產品線，包括智能識別、智能編輯、智能審核。我們在云官網上有相應的API接口，可以組合調用來滿足自己的實際應用場景。
智能識別系統的架構分四層，有對外接入、邏輯處理、模型識別和數據層。這個系統大概的執行流程是：首先進行用戶庫管理，包括人臉入庫、敏感詞的管理；接下來可以驗證入庫目標人物是否支持檢索；第三步是提交視頻處理任務，分別進行截圖處理、音頻處理、識別上報，策略層是基于配置和上報的數據進行整合過濾，然后返回結果。
同時要做公有云、私有云的一體化部署，因為很多的客戶希望敏感資源不要上公有云，所以有私有化的需求。
視頻處理也是系統的核心，這套多媒體處理框架，從（PPT左邊）是文件輸入（包括點播、直播、本地文件），一般的流程是解封裝、讀取壓縮數據，然后解碼分別生成視頻截圖和音頻PCM數據。因為對端ASR引擎對輸入是有要求的，所以要統一做重采樣、轉碼、分片等。完了把所有的截圖、音頻分片放到各自的線程隊列里去，然后每張圖要同時進行所有的識別，然后把所有的識別結果進行統一上報。音頻是獨立的，按固定間隔發送給ASR引擎即可。
結合實用場景，還要做一些應用場景優化。
騰訊優圖人臉識別有一個入庫的過程，即把所關注的目標人物人臉圖片通過特征提取入庫。人臉檢索處理衍生出來三種場景：建庫檢索是第一種；第二種是歷史掃描，比如要去從前面處理過的視頻中找出之前沒有入庫的目標人物；第三是無庫檢索，像監控場景中需要找到某人第一次出現到最后一次出現的時間點。
還有幾點場景優化，因為視頻是連續的，假如說現在某某出席某某會議，我如果知道這個名字在視頻語音里面出現，那他在下面視頻里出現的概率會比較高，我會進行一個ASR參考降低附近人臉相似度過濾閾值。OCR也是類似的，某個會議上有一個人截圖前面出現印有該目標人物人名文字的臺標，也可以類似處理，視頻中只看到側臉導致相似度分值比較低，我可以根據OCR人名把人臉相似度過濾值降低進行召回。再例如，一個人出席某個會議，從進入到結束不是一直看到正臉，可能是側臉，正臉、側臉，在庫里掃描的相似度分值可能是67、98、78。如果我連續時間參考序列上出現一個分值比較高，兩邊比較低的場景，我會把兩邊分值較低的時間點召回。
還有一點是無縫升級處理，人臉檢索引擎也會迭代，之前的庫提取出來人臉向量可能就用不上了，因為在新的庫里面向量維度都變了無法檢索，沒有參考意義，怎么樣讓用戶無感知做到無縫升級呢？我們把數據層做了多版本化的處理，我升級的時候用新版本庫，把之前舊版本庫提交的圖片去做一次提取，一旦兩個庫滿足一致性之后，即可支持新版本人臉庫的檢索。我先做一套類似于伴隨系統，兩庫同時跑，提取完之后做一個策略切換熱重啟即可完成升級。
語音識別也作了前置處理。對于點播視頻先做一個離線的VAD處理，把語音活動部分檢測出來，送到引擎端識別，減少靜音包識別帶來的網絡的負載，并可進行多線程識別加速。
按照固定間隔截圖，全部丟給后端引擎識別，后端引擎的壓力會很大。所以我們做一些過濾，對比多種圖片相似度檢測算法，做一個簡單的像素值的統計直方圖即可以達到過濾效果，且速度上有一定的優勢。還有指定區域處理，在引擎識別之前先裁剪我關心的那部分，縮小文字區域檢測面積，最后會快很多。
對于視頻集錦的處理，比如進球集錦，通過R-C3D模型處理后會輸出很多可選時間段，加上非極大值抑制處理，再結合VAD處理讓剪出來的片段平滑一些。
新聞拆條是把幾十分鐘視頻所有的新聞片段都拆出來做分發，方便互聯網用戶點擊。處理邏輯是把關鍵幀檢測出來，檢測視頻是否切到導播臺，再做一個人臉檢測，看導播臺現在有多少人？如果有0個的話我就認為是轉場，1個的話就可能是引入新聞。基于兩個模型的綜合，最后根據人臉檢測得到一個時間序列，這樣就自然把片斷拆出來，30分鐘的新聞當中每個新聞事件做一個拆條，從而進行短視頻的分發。
人物拆條，某個領導人出席某個會議，我只想把我自己出現的那個片段剪出來。片頭片尾拆條，我們在視頻軟件上可以看到，自動跳過片頭片尾，一般是vip特權，現在大部分是人工處理的，如果能自動識別片頭片尾會降低很多的人工成本。
應用場景
視頻+AI的應用場景有：
媒資管理，做識別之后知道哪些視頻里面有哪些明星。視頻搜索推薦，識別之后知道這個視頻屬于哪一類，是娛樂類還是搞笑類等等。直播流監控、電臺監控，就是涉黃、涉暴、涉政的檢測，如果直播流有一些敏感的東西可以直接斷掉。視頻審核。跳過片頭片尾。實時字幕。例如把主播的語音直接識別出來生成字幕加入到直播流中等。尾聲
此次現場開發者的熱情超出了我們的想象，相信這樣一個干貨滿滿的技術沙龍，一定給現場的所有參會者都帶來了新的思考。讓我們更加有理由期待，未來，音視頻及融合通信技術，一定會更加深入到我們的日常生活中來。
現場花絮
