前面文章WebRTC研究：包组时间差计算-InterArrival讲到了相关包组时间差计算，输出包组发送时间差，到达时间差等参数。本篇文章主要介绍下这些参数在判断网络拥塞情况方面的应用。
到达时间模型
在WebRTC研究：包组时间差计算-InterArrival说到了到达时间模型，主要包含几个包组时间差计算的概念：到达时间差：t(i) - t(i-1)
发送时间差：T(i) ....
Read More > 
在GCC（Google Congestion Control）中，包含两种拥塞控制算法。一种是基于丢包的，一种是基于延迟的。GCC最后综合这两种算法得到一个目标码率。基于延迟的拥塞控制算法主要由四部分组成：预处理（pre-filtering）, 到达时间滤波器（arrival-time filter）, 过载检测器（over-use detector），码率控制器（and a rate c....
Read More > 在WebRTC GCC(Google Congestion Control)中，有一个叫做AlrDetector（应用受限区域探测器，Application limited region detector）的模块。该模块利用某段时间值，以及这段时间发送的字节数判断当前输出网络流量是否受限。这些限制主要跟应用程序本身输出网络流量的能力有关，例如编码器性能，不能编码出设置的目标码率。下面举个简单例子说明下。假设我们经过带宽预测后，获取到一个目标码流target_bitrate_bps，此时我....
Read More > 
根据W3C的WebRTC 1.0: Real-time Communication Between Browsers规范，WebRTC的源码中定义了两套主要的C++接口，分别是MediaStream与PeerConnection相关的API。本篇文章主要介绍下MediaStream API中一些概念，方便理解内部代码如何处理。MediaStream 相关API定义在源码src\api\me....
Read More > 使用RTP协议封装数据时，我们可以通过RTP头部的序列号连续性判断是否丢包。但由于RTP头部序列号只有两字节表示，值范围[0,65535]，存在回绕问题（参考之前文章：WebRTC研究：RTP中的序列号以及时间戳比较，建议先阅读一遍此文章）。所以判断序列号连续性时得考虑回绕问题。下面我们就结合WebRTC这相关源码，讲下如何有效地根据序列号进行丢包判断。首先看下这块代码，代码位于src\modules\video_coding中的jitter_buffer.cc中：
[crayon-5....
Read More > 
在使用RTP协议时，如果需要网络对抗，保障QoS（Quality of Service，服务质量），我们需要通过序列号以及时间戳的比较，以进行丢包、乱序等处理。但是有个问题，比如一个RTP包，序列号为number1:5000，另一个RTP包序列号为number2:60000，可以说60000一定比5000大，是个更新的RTP包吗？当然不是了，首先我们先重温下RTP数据包的结构。....
Read More > WebRTC采用UDP传输流媒体数据，不可避免存在丢包情况。WebRTC主要采用FEC（Forward Error Correction，前向纠错）以及NACK（negative-acknowledge character，否定应答）对抗网络丢包。对于NACK，遇到丢包了才通知发送端重传对应数据包，但不是所有情况下某个包丢了就一定重传该包，有些场景下，重传该包会带来其它问题，例如增大延时，缓存过大，同时也可能发送端没有该数据包缓存，导致无法重传，此时会放弃重传该包。由于关键帧可以单独解码出图像，....
Read More > 
在音视频领域，想深入研究的话，必定会接触WebRTC。WebRTC是一个庞大的工程，就像是音视频领域的百科全书，音视频采集，编解码，传输，渲染等一条龙在WebRTC里都有，而且WebRTC还有很多先进的音视频处理算法。由于WebRTC代码过于庞大，所以最好单步调试跟踪代码运行，这样才可以更好地学习WebRTC，否则很难有头绪。工欲善其事必先利其器，作为调试神器，宇宙第一IDE Visual Stu....
Read More >