如何提升實時音視頻質量

客戶端常見指標和應對策略

客戶端實時音視頻質量提升目前主要有以下幾個方面

音視頻連通率和連通速度

$常見指標$

1. 連通率：音視頻通話雙方或者多方同時看到畫面或者聽到聲音的成功率
2. 連通速度：音視頻從呼出開始到對端用戶出現畫面或者聲音的時間

$應對策略$

1. 音視頻的連通率主要和控制信令有關，減少信令的交互次數以及提高信令的到達率就能達到提高連通率的指標，實時音視頻應該儘量減少信令造成的音視頻互通問題。比較好的辦法爲長短連接的方式配合使用，長連接主要解決呼入信令問題，短連接主要解決音視頻的功能接入。
2. 連通速度目前主要通過減少信令交互時間、UDP 通道建立時間、編碼發送時間來完成，常見方法有信令服務支持 http keepalive 或者 http 2.0、降低起始碼率的大小等

音頻通話質量

$常見指標$

1. 普通音頻通話場景：保證通話聲音的清晰度，具體表現爲 2000 Hz 以下的聲音波形的還原度
2. 高品質音頻互動場景：增加對除了人聲之外的聲音場景支持，提高頻率覆蓋範圍，允許部分嘯叫的產生
3. 外圍聲源的支持：可以在 RTC 中接入非 microphone 之外的聲源，提供多種音效的支持

$應對策略$

1. 針對普通通話場景可以引入嘯叫抑制和噪音抑制邏輯，抑制分級機制適配不同場景的用戶需求，噪音抑制使用 WebRTC 內置引擎，嘯叫抑制可以引入陷波器相關算法
2. 高品質音頻需要對聲音波形有很高的還原度，WebRTC 底層的很多聲音處理算法會破壞聲音形狀，導致在音樂場景下不滿足需求，短期內可以通過關閉聲音處理功能再配合相關控制信令達到音樂場景使用的目的，長期需要對聲音信號做專業化分析，例如引進人工耳和人工嘴，構建近似真實環境的沉浸式噪音場景，通過對端到端延遲指標、回聲抑制指標、響度指標等進行測試，對不同場景區分適配不同參數，上層通過參數設置到達不同場景需求的目的。
3. 增加混音 API 的支持，接入層可以通過很簡單的方式使用混音功能，增加多種音效互動模式，提升客戶體驗

視頻通話質量

$常見指標$

視頻通話質量目前主要爲視頻畫面清晰度，多種分辨率視頻支持， simulcast 大小流視頻支持，兼容在網絡抖動的情況下保障視頻畫面的流暢性

$應對策略$

目前視頻通話的指標主要在畫面清晰度和流暢性上，測試標準也比較統一。

1. 清晰度上目前主要在發送增加多種碼率視頻的發送，接收端根據需求選擇不同碼率的視頻數據。目前主流的 H264 硬編性能都比較強，同時編碼兩種或多種碼率的視頻不會造成瓶頸，同時也可以選用 H264-SVC 或者 VP9-SVC 方案，另外數據丟包對清晰度有很大的影響，此時需要權衡流暢性和清晰度，重視清晰度的話流暢性會受影響
2. 流暢性主要從包順序進行考慮，如果比較重視流暢性的話會允許一部分的包丟失，這個問題可以從使用場景進行區分

SDK 日誌埋點

$常見指標$

音視頻需要有客觀的數據統計平臺，能針對每一個音視頻頻道做到數據可視化，此時需要客戶端做日誌埋點

$應對策略$

1. 每一個和媒體服務器之間的數據請求都應該做到可視化，分析其中的錯誤碼和錯誤產生的原因，針對每一種錯誤都標識出類型（成功也是一種錯誤碼）
2. 針對呼入信令和呼出信令做數據統計，通過大數據分析呼入和呼出的信令成功率
3. 針對音視頻統計接通率，將音視頻數據是否接收到作爲統計標準
4. 定時統計 WebRTC 底層各項參數，例如丟包率、CPU、內存、帶寬等各項指標
5. 花屏統計，通過機器學習統計花屏，檢測到花屏時上報當前客戶端編解碼信息以及發送端編解碼信息

對外 SDK 的標準化

$常見指標$

1. 定製性較強的 SDK：針對使用比較頻繁的場景出具一套定製性的 SDK，包含基本的 UI 組件，方便開發者或者第三方廠商快速集成使用，可以修改部分 UI 邏輯
2. 非定製性的 SDK：包含一些基本的 UI 控件，用戶自行搭配使用，可控性比較強
3. 粒度級別較細的 SDK（原子性 SDK）：比較偏向底層的 API 接口，可以滿足所有音視頻場景需求
4. API 標準化：針對各個端出具一套統一的 API 接口，方便各個不同端的開發者進行對接
5. 音視頻特效 API：隨着網絡的快速發展，基於實時音頻和視頻上的定製性開發需求特別多，例如音效和視頻特效的開發需求
6. 單元測試體系：單元測試目前是軟件行業的標準，覆蓋全面的單元測試體系能夠快速定位問題和提高軟件質量

$應對策略$

1. 很多客戶需要快速功能接入而不太重視技術細節，可以使用定製性比較強的 SDK，客戶微小修改就能直接使用，針對此類需求， API 設計需要儘可能簡單易懂、包含詳細的開發者文檔、快速集成 Demo 以及儘可能少的 API 調用。
2. 非定製性的 SDK 主要提供多種組件，用戶根據需求動態調整組件使用邏輯，
3. 粒度級別較細的 SDK 主要提供通訊能力，不對其他業務邏輯有過多涉及，減輕通訊能力層的負擔。
4. 針對以上四種 SDK，所有端都需要有一套統一的 API 調用以及詳細的開發者文檔、快速集成示例 Demo、以及相應的技術支持。
5. 針對音頻和視頻提供一些特效支持，例如音頻混響、變聲、均衡器等支持；視頻美顏、水印、人像跟蹤、物體跟蹤、畫面特效。人像跟蹤和物體跟蹤可以通過插件的方式進行支持，使用現成的 M-RCNN 方案
6. 針對客戶端和服務端都應該引入單元測試標準，達到覆蓋率指標和執行成功率指標，引入 mock 系統等

服務端常見指標和應對策略

由於 Media Server 是音視頻的核心，所以音視頻很大一部分問題都會集中體現在 Media Server 中

媒體服務器

1. 是否瞭解項目源碼
   作爲服務端的音視頻技術開發，必須全部瞭解 WebRTC 協議棧，例如 ICE (STUN/TURN)、RTP、RTCP 以及詳細的 GCC、REMP、PLI、FIR 邏輯層。保障客戶端的數據傳輸，將主要精力放在數據傳輸問題排查上，因爲客戶端主要接觸的首先是業務層的開發，其次纔是協議層的開發，所以數據收發問題定位服務端開發人員需要有很深入的瞭解。

2. 項目文檔
   無論是開源媒體服務器還是自行開發的媒體服務器都應該有詳細的 API 文檔，既方便定位和排查問題，也方便後續維護和開發人員持續開發，文檔上可以參考使用用戶比較多的開源媒體器的 API 文檔

3. 它是否是可調試的
   一款媒體服務器的成功與排查問題和定位問題的速度有很大關係，只有方便排查問題的媒體服務器才能快速成長起來，可以從幾個維度來考慮，第一：ICE 連通率相關日誌埋點統計，ICE 連接候選以及發包策略統計；第二：音視頻 RTP RTCP 數據統計，包含丟包、帶寬預估、GOP 緩存計算等數據統計；第三：提供數據查詢 API，支持客戶端動態獲取其上行和下行碼率以及丟包等相關信息；第四：和客戶端信令交互數據統計，包含統計出成功和失敗的數據，通過請求 ID 的方式實時彙報每一次信令交互的結果；第五：媒體服務器之間每次發佈和訂閱也需要進行標識

4. 是否易於服務橫向擴展
   受限於單臺服務器的性能瓶頸，所以媒體器需要支持橫向擴展

5. 核心業務層開發語言確定
   很多專業的實時音視頻類庫均使用 C 或者 C++ 語言開發，使用文檔也比較多（例如：WebRTC、libnice、libsrtp），所以媒體服務器的核心邏輯層建議使用 C 或者 C++ 進行開發，方便核心能力層快速迭代，以及問題排查

6. 簡化信令交互
   客戶端和媒體服務器信令交互的次數越多，越容易導致問題的出現，網絡請求失敗、網絡斷開、網絡切換等都會造成音視頻接入的失敗。交互信令越少越容易提高音視頻的質量

7. 媒體服務器的角色
   媒體服務器的主要角色是保障數據傳輸、定製性業務邏輯層的功能可以放到客戶端來實現，雙邊互補才能提高音視頻的體驗

數據可視化

客戶端的埋點日誌輸出、服務端的埋點日誌可以彙總到大數據管理平臺，目前以下指標需要精確定位出來

1. 信令交互成功率
   由於客戶端和服務端都統計請求 ID 對應的結果，所以可以通過請求 ID 標識出每一次音視頻信令的結果，在方便定位問題的同時也可以實時統計信令成功率，通過對應 ID 調出對應的日誌信息方便客戶端排查問題

2. 音視頻接通率
   統計客戶端每一次的音視頻接通率，例如音頻接通率和視頻接通率

3. 音視頻斷開統計及數據分析
   針對客戶端音視頻斷開連接時的原因統計，主要分爲網絡斷開、弱網導致的 ICE 斷開

4. WebRTC 各項參數統計
   例如丟包率、RTT 延遲、視頻編碼器、當前發送和接收碼率等

5. 客戶端崩潰統計
   針對客戶端，統計所有異常問題，引入 bugly 或者通過第三方開源項目進行統計。使客戶端符號化分析之後排查和定位問題。

6. 開發者技術反饋
   引入開發者技術評價體系，定時分析開發者需求轉化爲產品需求，優化產品質量和使用便捷性

QA 測試標準化

常規測試

主觀測試目前本文涉及不多，對項目本身而言主要還是一些基本流程準確性的測試、問題修復驗證測試和服務端業務邏輯測試等，另外對於音頻和視頻的測試需要引入主觀測試流程，提供測試評價標準

客觀測試

目前影響音視頻質量的因素主要有以下幾個

1. 網絡方面：丟包、延時、抖動
2. 設備因素：聲學設計、設備的計算能力
3. 物理環境因素：密閉環境、噪聲、嘯叫等

針對上述問題我們需要和競爭對手做數據上的對比，列出對比指標，例如不同使用場景下聲學曲線相似性指標、網損相同時丟包率指標、延遲指標、接通率指標等，另外還需要執行符合3GPP，ETSI等通信標準的客觀測試

1. 專業設計的消聲室：我們需要足夠安靜且反射路徑最小化的聲學環境來避免周圍的環境音來影響測試。
2. 人工耳和人工嘴：我們需要可重複又高保真的發聲和收音裝置來覆蓋人的正常說話和聽力動態範圍。
3. 網損設備：爲了覆蓋更多的真實場景，我們需要網損設備來模擬和控制丟包。
4. 近似真實環境的沉浸式噪音場景：我們需要在人工頭的四周佈置高保真的音箱來製造噪聲聲場。

自動化測試

自動化測試目前主要爲：

1. 客戶端接通率測試
   分爲雙人接通率測試標準和多人接通率測試標準
2. 服務端壓力測試
   服務端壓力測試要測試服務端支持的量級，以及容量超過限制時自動擴容或者橫向擴容相關的邏輯驗證
3. AI 測試
   客戶端引入深度學習測試，給出標準的音頻和視頻信息，通過深度學習的方式驗證音視頻通話過程中的聲音質量度量和視頻質量度量