发起视频通话流程图如下
创建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规范之外，还可以通过它获得一个有趣的替换方案!
一、延时计算原理
1）jitter延时计算公式
JitterDelay由两部分延迟造成：传输大帧引起的延迟和网络噪声引起的延迟。计算公式如下：
JitterDelay = theta[0] * (MaxFS – AvgFS) + [noiseStdDevs * sqrt(varNoise) – noiseStdDevOffset]
该公式详细推导过程，请参见大牛的文章《WebRTC视频接收缓冲区基于KalmanFilter的延迟模型》
theta[0]：信道传输速率的倒数
MaxFS：自会话开始以来所收到的最大帧大小
AvgFS：表示平均帧大小
noiseStdDevs：表示噪声系数2.33
varNoise：表示噪声方差
noiseStdDevOffset：是噪声扣除常数30
2）jitter延时更新流程
1、配置webrtc抗丢包方法为FEC Only。
启动配置的时候，可以选NACK Only 或FEC Only 或NACK、FEC混合模式。
为了测试webrtc的X264 FEC抗丢包性能，在启动配置的时候，选择FEC Only模式。
配置方法请参考：VCMLossProtectionLogic::SetMethod
2、使用Network Emulator Client配置网络丢包模型为随机丢包，随机丢包概率为5%
1、建立X264编码视频连接，查看视频清晰度及流畅性。
2、建立VP8编码视频连接，查看视频清晰度及流畅性。
视频无长时间卡顿，至少X264编解码效果要与VP8一致。
H.264被设定为取代VP8成为WebRTC服务的视频编解码器。
微软上周在他们的Edge开发博客上宣布， Edge的ORTC开始支持H.264/AVC。
· 是的，它是ORTC而不是WebRTC
· 是的，它仅通过运行时标志就可以开启
· 是的，它只在Edge浏览器可用，IE浏览器不行
但话又说回来，这是目前唯一能够在Firefox、Chrome和Edge之间跨浏览器进行视频通话的方法。VP8和VP9至多能让你在Chrome和Firefox之间建立视频通话。
这也是我写这篇文章的原因。Edge在ORTC中对H.264的支持并不多。从更大的视角来看，这甚至谈不上有意义。相比于其他浏览器Edge几乎没有市场份额，那么为什么还要为它花费心思呢？但是这件事仍然标志着一个转折——我们应当问自己：当我们要开发一个基于WebRTC的产品时，我们应该选择什么样的视频编解码器。
去年的时候，这个答案可能是“VP8”。
几个月前，答案可能是“看情况”。
现在，答案将会是“除非必须用VP8，否则就用H.264”。
