音視頻融合通信技術的最佳實踐，全在這裡了

| 導語視頻全面數字化時代的到來，讓越來越多的開發者逐漸關注音視頻技術。隨著音視頻技術的應用越來越廣泛，對於音視頻技術的要求也越來越高，既要簡單易接入，又要滿足高並發、低延遲、高清明眸，少流量……除此之外，與時俱進不斷優化技術能力，應對 5G、出海等熱點需求。騰訊視頻雲是如何滿足多場景的應用，賦能行業，引領視頻技術的發展呢？

6 月 29 日，雲 社區主辦的技術沙龍 -「音視頻及融合通信技術」在北京成功舉辦，騰訊雲經過多年的技術沉澱，並結合自身的最佳實踐，引領了現場近 300 位開發者關於「音視頻」技術的不一樣的思考。

以下為本次沙龍的現場演講摘要：

1

移動直播連麥技術實踐

首先聚焦在直播場景下，在當前這個全民直播的時代，連麥逐漸成長為直播領域非常重要的業務場景之一，但是網路往往是不穩定的，那麼如何在網路不可控及弱網的情況下來保證高質量的連麥通訊服務呢？騰訊高級工程師蔣磊現場為大家闡述了騰訊在這方面的最佳實踐。

連麥直播概述

連麥直播與普通直播的區別在於，後者類似單口相聲，一個直播表演很多觀眾看；連麥直播是對口相聲和群口相聲，有大主播和小主播，普通觀眾看大主播和小主播的畫面。

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

延時

普通直播的延時主要來自於轉碼處理過程中產生的百毫秒級別的延時，以及 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 毫秒以內。

2

騰訊雲直播 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 可能回歸最初的夢想，在互聯網上產生出徹底去中心化的服務模式。

3

騰訊視頻雲海外直播系統架構設計與最佳實踐

近幾年國內視頻直播市場逐漸疲軟，越來越多的廠商開始涉足海外直播。雲 社區技術沙龍請到騰訊高級技術專家，海外直播技術負責人胡仁成老師分享《騰訊視頻雲海外直播系統架構設計與最佳實踐》。

海外直播系統在應用軟體層面跟國內沒有太大的區別。直播系統架構包含三大塊，一是公有雲和網路基礎設施的建設；第二是在此基礎設施上架設軟體系統，實現直播流媒體的分發；第三，在已完成的系統上更深入化優化。

海外網路與機房建設

當前騰訊雲在全球的網路布局從地域分為三大區，北美、亞太（香港、新加坡）、歐洲（德國）。海外大概接近 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%。

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

4

實時音視頻與 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、自動屏蔽出問題的資源等方式。

5

音視頻 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 的應用場景有：

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

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

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

視頻審核。

跳過片頭片尾。

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

尾聲

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

現場花絮

關注云加社區，回復3加讀者群

點在看，讓更多人看到

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！