WebRTC源码架构浅析
2015-11-25 14:03
381 查看
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. 语音和视频引擎, 这部分才是原来 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 提供的源码支持了几乎所有常见平台.
还有一个技术难点, 是视频会议中的混音技术(mixer). WebRTC 的源码中提供相关的功能, 但似乎是非常简陋的一个实现. 混音技术一般要在服务器中进行, 但发给说话人的数据中, 该说话人的语音必须不在混音中. 因为用户不希望在自己的喇叭中再听到自己说过的话, 这效果和回声差不多.
其次是视频技术. 在编码方案的选择上, 有开源的 VP8 和专利的 H.264. 前者是 Google 收购和开源的技术, 而后者虽然有专利和收费, 但更成熟, 而且有资料表明H.264的技术稍微领先VP8. 最重要的是, H.264 有广泛的硬件设备支持, 例如 iPhone 上就集成 H.264 硬件编解码器(Apple 就是 H.264的专利拥有者之一). 在有硬件支持的设备上使用 H.264, 可以减少耗电量和 CPU 资源, 因为视频编解码需要的运算量非常大.
转自:http://www.ideawu.net/blog/archives/726.html
GIPS 主要是提供视频和语音引擎技术和开发包, 而 WebRTC 却要提供一揽子的多媒体聊天解决方案, 特别是嵌入到浏览器中, 使用 Web 相关技术(如 JavaScript, HTML5). 所以, WebRTC 的源码结构非常庞大,
单单是从 trunk 中获取的代码和数据就达到1.2G还多.
不过, 如果明白了 WebRTC 的架构, 就可以从这份开源代码中摘出我们想要的部分. WebRTC 包含下面几个部分:
1. 应用层, 即 WebRTC 技术. 此部分的技术主要是浏览器开发者需要, 但因为其是太过于顶层的应用技术, 过于偏向某一方面, 所以可取可不取.
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 提供的源码支持了几乎所有常见平台.
还有一个技术难点, 是视频会议中的混音技术(mixer). WebRTC 的源码中提供相关的功能, 但似乎是非常简陋的一个实现. 混音技术一般要在服务器中进行, 但发给说话人的数据中, 该说话人的语音必须不在混音中. 因为用户不希望在自己的喇叭中再听到自己说过的话, 这效果和回声差不多.
其次是视频技术. 在编码方案的选择上, 有开源的 VP8 和专利的 H.264. 前者是 Google 收购和开源的技术, 而后者虽然有专利和收费, 但更成熟, 而且有资料表明H.264的技术稍微领先VP8. 最重要的是, H.264 有广泛的硬件设备支持, 例如 iPhone 上就集成 H.264 硬件编解码器(Apple 就是 H.264的专利拥有者之一). 在有硬件支持的设备上使用 H.264, 可以减少耗电量和 CPU 资源, 因为视频编解码需要的运算量非常大.
转自:http://www.ideawu.net/blog/archives/726.html
相关文章推荐
- 几种常见Android代码架构分析
- 游戏服务器架构设计
- mysql数据迁移后,打开网站提示500----一次由ip addr引发的血案
- 网站优化应注意的事项
- ARM 架构常用浮点函数
- Yate架构分析概要
- 2001-使用Hive+MR统计分析网站指标
- 移动开发应该常去的网站
- 好的icon图标网站
- 揭秘Facebook 的系统架构
- PHPCMS网站更换域名怎么办?
- jeecms网站内容页,获取固定的二级栏目
- (转)前端:将网站打造成单页面应用SPA
- .net实现网站用户登录认证
- MVP社区巡讲-云端基础架构:12月5日北京站 12月12日上海站
- 国家哀悼日将网站全部变成灰色的代码
- Swift 2.0学习笔记(Day 2)——使用Web网站编写Swift代码
- .net实现网站用户登录认证
- 发布LightSwitch网站时,报404错误的原因
- 教中小企业从建站的各个环节进行网站优化