light-rtc: 理念與實踐

時間 2021-01-05

標籤 git github web 算法架構 ide 函數性能優化阿里雲欄目 Git 简体版

原文原文鏈接

在與同行交流過程當中，發現不少同行對 WebRTC 改動太多，致使沒法升級 WebRTC 版本。而 WebRTC 開源社區的快速迭代，讓他們感到欣喜又焦慮：開源社區的迭代效果，是否是超過了他們對 WebRTC 的優化效果？咱們針對特定場景優化 WebRTC 時，怎麼緊跟 WebRTC 開源社區通用的優化？git

做者：阿里雲智能技術專家熊金水github

理念

簡言之，把 WebRTC 做爲 Framework 使用，而不是 Library，即：WebRTC 倉庫輕量化，核心模塊插件化。web

詳細的，WebRTC 做爲 Framework 串聯核心模塊；核心模塊既能夠以插件形式使用咱們的實現，也能夠 Fallback 到 WebRTC 的默認實現。目的是減小 WebRTC 衝突的可能性，提升升級 WebRTC 的敏捷性。算法

目標：一年升級一次 WebRTC，一次花費一我的月。架構

架構

模塊拆解

WebRTC 的核心模塊，包括：ide

音頻

ADM 採集、APM、ACM 編碼；
NetEQ 與解碼、AM、ADM 渲染；

視頻

採集、編碼；
JB、解碼、渲染；

通用

RTP 打包與解包、FEC 生成與恢復、CC 與 Pacer、ICE、SDP 信令等。

WebRTC 在長期的演進中，API 已經具有了做爲 Framework 的大部分能力。紅色的核心模塊，已經基本能夠插件化，以下面的 API：
函數

倉庫管理

light-rtc 做爲 WebRTC 倉庫，咱們須要保留兩個 Remote，一個是 Alibaba，一個是 Google。升級 WebRTC 時，咱們從 Google 上 Pull 最新代碼，解決衝突，而後 Push 到 Alibaba。性能

對插件化的模塊，咱們須要放到單獨的倉庫 lrtc-plugin 裏，這樣有兩個好處：優化

對 light-rtc 倉庫改動少，減小與 Google 衝突的可能性；
更重要的，讓每一個開發同窗，在每次改動前，更主動、更有意識的思考，放到哪一個倉庫更合適，不然容易慣性思惟，直接改動 light-rtc。

對 lrtc-plugin 依賴的第三方庫，也應該以單獨的倉庫存在，並保留兩個 Remote，好比 Opus，這樣，即便修改了 Opus 源碼，仍然能夠像升級 light-rtc 同樣，方便的單獨升級 Opus 版本。阿里雲

模塊

Codec

音頻編解碼器、視頻編解碼器，是咱們最常優化的部分之一：

新的編碼工（AV1/SCC/ROI 等）優化視頻質量和帶寬；
分辨率自適應，使不一樣能力（編碼能力、發送帶寬等）的發送端，發送不一樣分辨率的碼流；
Simulcast，爲不一樣能力（解碼能力、顯示能力、接收帶寬等）的接收端，提供不一樣分辨率碼流；
SVC，提供時域/空域分層；
新的視頻解碼實現，規避 Mac 硬解卡死等問題；
新的音頻編碼器，適配商用接收端；
……

這部分插件化是相對簡單的，只須要實現本身的[Video|Audio][Encoder|Decoder]Factory 便可。以 Simulcast爲例，在本身實現的 VideoEncoderFactory 裏，先用 WebRTC 原始的 VideoEncoderFactory，建立多個 Encoder 對象，而後封裝到一個 Simulcast Encoder 裏。

ADM

很惋惜，ADM(Audio Device Module)沒有提供檢測設備插拔的功能，須要增長 Callback 接口。

另外，雖然 WebRTC 支持樣本數量的監控，可是當前只用於打印日誌，若是想在此基礎上作更多事情（如：發現採集樣本爲 0 時，重啓採集），則單獨作一個 AudioSampleMoniter 的類，比較有利於擴展。

ADM 是一個適配難點，相信是困擾 RTC 同行的共同難題。不一樣操做系統、不一樣機型，均可能有不同的問題。例如：

Mac 3.5mm 耳機插拔時，偶爾崩潰；
Mac 獲取的設備 ID 在插拔後發生變化，不能作持久化；
聯想 X1 電腦，屢次插拔後，整個 Audio 後臺服務失效；
某些 Windows 機型採集不到聲音；
某些手機採音權限問題；
……

這些修改大部分屬於 Bugfix，參考「Bugfix」章節。

APM

APM(Audio Processing Module)多是 light-rtc 相對難處理的部分。

APM 與 NetEQ 一塊兒，多是 WebRTC 核心模塊中，開源價值最大的部分。在我對 APM 有限的認知裏，對 APM 常見的優化可能有：

混音後的遠端信號，作濾波/均衡處理。這是業界很多音頻算法的必要條件；
利用 Android 手機特性，優化 AECM，尤爲是 Double Talk 時的效果；
嘯叫檢測與抑制；
利用機型特性，優化 AGC，提升語音音量;
……

下圖是 WebRTC APM 內部模塊的數據流程圖：

從圖中能夠看出，APM 其實也爲插件化作了準備，可是隻在近端信號的尾部、遠端信號的頭部。從 APM 構造函數上也能夠看出來：

濾波/均衡，能夠方便的實現一個 CustomProcessing 的 render_pre_processor。

其餘的優化，遵循輕量化/插件化的理念，沒有現成的插件接口，咱們能夠創造新的插件接口，如嘯叫抑制，以及 AECM 優化的部分算法。

但 APM 仍然會有不少沒辦法插件化的，只能修改 light-rtc 倉庫，如 AECM Double Talk 優化等。

AM

AM(Audio Mixer)的插件化，能夠在不修改 light-rtc 的基礎上，玩出不少花樣：

播放本地文件；
藉助語音檢測算法，優化語音排序，從而選出更準確的語音作混音；
Mono 變成 Stereo，藉助 HRTF，能夠在多方同時說話時提升說話人辨識度和可懂度；
對 RTP 方案的回放，倍速回放時變速不變調；
……

FEC

FEC(Forward Error Correction)，常見的修改：

調參，如冗餘度、MaxFrames、Table 類型，包括固定參數和動態自適應調參兩類，已有的插件接口 WebRTC::FecControllerFactoryInterface 便可知足;
RSFEC，須要創造新的插件接口；
Opus Inband FEC。WebRTC 動態配置的 Opus FEC 參數，不能很好的解決弱網時聲音卡頓問題。這時，一個辦法是把 Opus 獨立成倉庫，直接修改 Opus 編碼器。

CC

CC(Congestion Control)，包含兩個方面，一個是 CC 算法自己，一個是 CC 關聯模塊。

算法自己，能夠用不一樣的算法實現，如 WebRTC 默認的 goog_cc，也能夠是 BBR，甚至是知足 WebRTC::NetworkControllerFactoryInterface 接口的外部插件。

關聯模塊：

帶寬分配：不一樣場景可能不同，如視頻會議裏，須要「保音頻、保屏幕」。能夠經過 rtc::BitrateAllocationStrategy 實現插件化。

Pacer 調優：對於屏幕內容，I幀每每很是大，WebRTC 的 2.5 倍的發送帶寬，會致使巨大的首幀時間。具體解法見仁見智。
……

VideoRender

Android、iOS、Mac，WebRTC 都提供了默認的實現，雖然有少許 Bug，可是基本知足需求。

Windows 平臺，早期 WebRTC 提供了 D3D 的實現，最新版已經剔除，咱們能夠在 lrtc-plugin 倉庫實現本身的 D3D，或者其餘的渲染，如 QT OpenGL。

VideoProcess

WebRTC 並無提供視頻前處理（如：美顏）、後處理（如：超分辨率）的接口，可是咱們徹底能夠像 rtc::BitrateAllocationStrategy 同樣，創造 VideoProcessInterface 接口, 並在 lrtc-plugin 倉庫裏實現。

讓 VideoProcessInterface 同時繼承 Sink 和 Source 接口，能夠方便的把多個對象串聯起來。

其餘 & Bugfix

其餘核心模塊，如 JitterBuffer、ICE 等，目前接觸的主要是 Bugfix，尚未發現本身定製重寫的必要。

Bugfix，每每只能修改 light-rtc 倉庫。一方面，是儘可能把 Bugfix 內聚成函數，減小對已有代碼的修改；另外一方面，儘可能把 Bugfix 貢獻到開源社區(Issue Tracker)，既爲開源社區作了貢獻，也完全避免了升級的衝突。

貢獻到開源社區，每每比想象的要複雜，但也更能鍛鍊人。在特定場景，每每只用了 WebRTC 一部分能力，如視頻 JitterBuffer，一個 Bugfix 可能只考慮到了 H264，貢獻到開源社區時，則須要同時兼顧 VP8/VP9，甚至是未來的 AV1。在這個過程當中，Google 工程師會在 Code Review 中與你親密切磋，實際上是很是好的鍛鍊機會，進一步提升對 WebRTC 的認識。