WebRTC源碼架構淺析（轉）

時間 2019-11-30

原文原文鏈接

Google 在2010年花了6千8百萬美圓收購了大名鼎鼎的 Global IP Sound/Solutions (GIPS) 公司, 獲得了它的 VoIP 相關技術的專利和軟件. 第二年, Google就把這些軟件開源了, 不過, 不是做爲獨立的軟件, 並且也和原來的軟件功能大不同, 而是做爲所謂的 WebRTC 方案的一部分.javascript

GIPS 主要是提供視頻和語音引擎技術和開發包, 而 WebRTC 卻要提供一攬子的多媒體聊天解決方案, 特別是嵌入到瀏覽器中, 使用 Web 相關技術(如 JavaScript, HTML5). 因此, WebRTC 的源碼結構很是龐大, 單單是從 trunk 中獲取的代碼和數據就達到1.2G還多.html

不過, 若是明白了 WebRTC 的架構, 就能夠從這份開源代碼中摘出咱們想要的部分. WebRTC 包含下面幾個部分:java

1. 應用層, 即 WebRTC 技術. 此部分的技術主要是瀏覽器開發者須要, 但由於其是太過於頂層的應用技術, 過於偏向某一方面, 因此可取可不取.web

2. 網絡層, 主要是 libjingle. libjingle 就是 Google Talk 所使用的網絡框架. 但 libjingle 並沒開源服務器端的代碼和技術, 再者, 網絡層的可替換性很強, 各家公司老是設計本身的私有網絡協議和架構, 因此, libjingle 的做用就是做爲一個學習的對象.瀏覽器

3. 語音和視頻引擎, 這部分纔是原來 GIPS 公司的專利和核心技術! 因此, 要詳細解讀一番.服務器

首先是語音技術, 能夠先看這篇入門文章」淺談網絡語音技術「.網絡

音頻處理(audio processing)包含最主要的兩個模塊是: 迴音消除(AEC, Acoustic Echo Cancellation), 靜音檢測(VAD, Voice Activity Detection). 沒有前者, 用戶只能頭戴耳機聊天, 並且要很是當心, 不然會出現回聲和嘯音. 沒有後者, 就要浪費大量的網絡流量, 增長服務器混聲負擔. 其它的技術主要是爲了提升單質.架構

音頻編解碼(audio coding)的目的是爲了壓縮, 減小流量. 雖然 GIPS 開發的 iLBC 和 iSAC 兩種編解碼器很是出名, 還有各類開放格式如 G.xxx, 但較多的資料顯示, 開源的 Opus 方案彷佛更勝一籌.框架

音頻設備抽象層, 爲不一樣的操做系統提供統一的錄音和放音接口. 雖然有開源的 PortAudio 能夠支持 Windows/Mac/Linux多個平臺, 但彷佛並不支持 iOS 和 Andoid. WebRTC 提供的源碼支持了幾乎全部常見平臺.less

還有一個技術難點, 是視頻會議中的混音技術(mixer). WebRTC 的源碼中提供相關的功能, 但彷佛是很是簡陋的一個實現. 混音技術通常要在服務器中進行, 但發給說話人的數據中, 該說話人的語音必須不在混音中. 由於用戶不但願在本身的喇叭中再聽到本身說過的話, 這效果和回聲差很少.

其次是視頻技術. 在編碼方案的選擇上, 有開源的 VP8 和專利的 H.264. 前者是 Google 收購和開源的技術, 然後者雖然有專利和收費, 但更成熟, 並且有資料代表H.264的技術稍微領先VP8. 最重要的是, H.264 有普遍的硬件設備支持, 例如 iPhone 上就集成 H.264 硬件編解碼器(Apple 就是 H.264的專利擁有者之一). 在有硬件支持的設備上使用 H.264, 能夠減小耗電量和 CPU 資源, 由於視頻編解碼須要的運算量很是大.