WebRTC源碼架構淺析

標籤：

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

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

不過, 如果明白了 WebRTC 的架構, 就可以從這份開原始碼中摘出我們想要的部分. WebRTC 包含下面幾個部分:

1. 應用程式層, 即 WebRTC 技術. 此部分的技術主要是瀏覽器開發人員需要, 但因為其是太過於頂層的應用技術, 過於偏向某一方面, 所以可取可不取.

2. 網路層, 主要是 libjingle. libjingle 就是 Google Talk 所使用的網路架構. 但 libjingle 並沒開原始伺服器端的代碼和技術, 再者, 網路層的可替換性很強, 各家公司總是設計自己的私人網路通訊協定和架構, 所以, libjingle 的作用就是作為一個學習的對象.

3. 語音和視頻引擎, 這部分才是原來 GIP小型股份有限公司的專利和核心技術! 所以, 要詳細解讀一番.

首先是語音技術, 可以先看這篇入門文章”淺談網路語音技術“.

音頻處理(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 提供的源碼支援了幾乎所有常見平台.

還有一個技術痛點, 是視頻會議中的混音技術(mixer). WebRTC 的源碼中提供相關的功能, 但似乎是非常簡陋的一個實現. 混音技術一般要在伺服器中進行, 但發給說話人的資料中, 該說話人的語音必須不在混音中. 因為使用者不希望在自己的喇叭中再聽到自己說過的話, 這效果和回聲差不多.

其次是視頻技術. 在編碼方案的選擇上, 有開源的 VP8 和專利的 H.264. 前者是 Google 收購和開源的技術, 而後者雖然有專利和收費, 但更成熟, 而且有資料表明H.264的技術稍微領先VP8. 最重要的是, H.264 有廣泛的硬體裝置支援, 例如 iPhone 上就整合 H.264 硬體轉碼器(Apple 就是 H.264的專利擁有者之一). 在有硬體支援的裝置上使用 H.264, 可以減少耗電量和 CPU 資源, 因為視頻編解碼需要的運算量非常大.

Related posts:

1. WebRTC C/C++ API 範例程式碼 – 播放和錄音(23.687)
2. Google Talk Developer Home 中文翻譯(12.18)
3. SSDB – 支援 zset 的 LevelDB 伺服器(4.904)
4. 安裝和使用Google Earth – Linux(4.743)
5. endlessssh – SSH 代理工具(4.384)

Tags: GIPS, VoIP, WebRTC, 視訊交談, 語音引擎, 語音交談  原文轉自 http://www.oschina.net/question/35855_121850

WebRTC源碼架構淺析（轉）