GIPS 主要是提供视频和语音引擎技术和开发包, 而 WebRTC 却要提供一揽子的多媒体聊天解决方案, 特别是嵌入到浏览器中, 使用 Web 相关技术(如 JavaScript, HTML5). 所以, WebRTC 的源码结构非常庞大, 单单是从 trunk 中获取的代码和数据就达到1.2G还多.
不过, 如果明白了 WebRTC 的架构, 就可以从这份开源代码中摘出我们想要的部分. WebRTC 包含下面几个部分:
下面很多程序的安装之后都会要加入到环境变量中，先解释 一下什么叫环境变量。
当我们在cmd下输入命令的时候，例如cp，dir等命令，可以直接运行，而想执行一个打开chrome浏览器的chrome.exe命令时候,就会提示chrome.exe找不到等类似的错误，那是因为chrome.exe并没有被加入到环境变量中。你必须形如这样的方式"C:\Program Files\Google\Chrome\Application\chrome.exe",在cmd下才可以将chrome浏览器打开。
对于cmd下，会解析用户的输入，对于用户输入的命令，它会向系统变量和环境变量中的一个path参数下去寻找，有没有相应的可执行文件，于是如果你想执行svn命令，而svn.exe所在目录却并没有加入到环境变量的path路径中，那么cmd下就会报“命令不存在”的错误。加入命令到环境变量有这样的一个好处，对于一个命令不需要输入它的完整路径，而仅仅需要输入命令的名字就可以了，这可以给我们在cmd下执行命令提供相当大的方便。于是乎当下面安装的某一个程序提示需要加入到环境变量的时候，实际上就是说你在cmd下可以直接输入命令的名字就可以执行目录下的命令。
编译WebRTC之Android版本（AppRTC工程编译）
前言
准备工作
下载源码
编译依赖库
总结
前言
最近有项目需要用到android与web互通音视频，甚至与原生windows互通，很久没编译过了，所以今天亲自编译一下，并记录下来。
发起视频通话流程图如下
创建dsp描述符,CreateOffer在流程中位于 OnSignalingMessage(offer)
void CConductor::ConnectToPeer(int peer_id) {
if (peer_connection_.get()) {
LOG(LS_ERROR) <<
"We only support connecting to one peer at a time";
return;
}
if (InitializePeerConnection()) {
peer_connection_->CreateOffer(this, NULL);
}
else {
LOG(LS_ERROR) << "Failed to initialize PeerConnection";
}
}
说明：此系类的内容都是本人自己对libjingle native API代码的学习总结。其中可能存在不准确甚至是错误的内容。欢迎大家帮忙指出错误。
此文是个人根据WebRTC项目中的libjingle部分总结出来。只代表WebRTC中的libjingle部分的结构，不代表原始的libjingle项目。
国内现在很多语音聊天工具都是基于TURN方式实现的，包括YY、AK等等，这种方式对于服务器的性能要求很高，而且在用户量增大的时候，服务器压力也会越来越大，用户的语音质量也会受到很大影响。而基于P2P方式实现的语聊服务器，就可以极大的避免这种情况的发生，而且用户的语音体验也会非常好。
通过上文(P2P的原理和常见的实现方式(为libjingle开路))我们知道，因为NAT设备没有固定标准的原因，导致并不能100%的实现P2P，但是根据现在通用的ICE&STUN的方式，P2P的成功率可以达到90%多。前段时间在找使用这种方法实现的成熟库，最后猛然发现libjingle就在那里。
通过一个多星期的研究，在此记录一下libjingle库的大致情况，如有不妥，希望朋友们可以留言或者邮件(peakflys@gmail.com)指正。
在视频通信的技术领域WebRTC已成为主流的技术标准，WebRTC包涵了诸多优秀的技术，譬如：音频数字信号处理技术（AEC, NS, AGC）、编解码技术、实时传输技术、P2P技术等，这些技术目的都是为了实现更好实时音视频方案。但是在高分辨率视频通信过程中，通信时延、图像质量下降和丢包卡顿是经常发生的事，甚至在WiFi环境下，一次视频重发的网络风暴可以引起WiFi网络间歇性中断，通信延迟和图像质量之间存在的排斥关系是实时视频过程中的主要矛盾。分析WebRTC是如何解决这个矛盾之前，先来看看我们在在线教育互动的生产环境统计到的视频延迟和人感官的关系，大致如下：
延迟 感官描述
0 ~ 400毫秒 人感觉不到视频在通信过程中的延迟
400 ~ 800毫秒 人能感觉到轻微延迟，但不影响通信互动
800毫秒以上 人能感觉到延迟而且影响通信互动。
也就是说，通信过程中最好将视频延迟控制在800毫秒以内。除了延迟，视频图像质量也是个对人感官产生差异的关键因素，我们以640x480分辨率每秒24帧的H264编码情况下视频码率和人感官之间的关系（这组数据是我们通过小范围线上用户投票打分的数据）：
码率 感官描述
800kbps以上 人对视频清晰度满意,感觉不到视频图像中的信息丢失
Phone 人对视频清晰度基本满意，有时能感觉到视频图像中的信息丢失
Pipe 人对视频清晰度不满意，大部分时候无法辨认图像中的细节信息
从上面的描述可以知道视频质量保持在一个可让人接受的质量范围是需要比较大的带宽码率支持的，如果加上控制延迟，则更需要网络有很好速度和稳定性。但是很不幸，我们现阶段的移动网络和家用WiFi并不是我们想象中的那么好，很难做到在实时视频通信中一个让人非常满意的程度。为了解决以上几个问题，WebRTC设计了一套基于延迟和丢包反馈的拥塞机制（GCC）和带宽调节策略来保证延迟、质量和网路速度之间平衡，这是一个持续循环过程，如下图：
自WebRTC编解码器战争以缓和告终以来，已经有几年时间了。H.264也已经存在了超过15年，因此很容易掩盖运用中的多种复杂问题。
|pipe| CTO Tim Panton正在研究一个无人机项目，他需要为WebRTC提供一个轻量级H.264堆栈，而他决定自己构建一个。这当然不是我推荐给大多数人的一个运用，但Tim表示，如果不是一个简单的运用，那么这可能是一种启发性的体验。在这篇文章中，Tim一步步地向我们展示了他在努力让视频播放时的发现。除了阅读H.264介绍的RFCs规范之外，还可以通过它获得一个有趣的替换方案!
