Category Archives: WebRTC

在GCC（Google Congestion Control）中，有两种拥塞控制算法。一种是基于丢包的，一种是基于延迟的。GCC最后综合这两种算法得到一个目标码率。基于延迟的拥塞控制算法主要由四部分组成：预处理（pre-filtering）, 到达时间滤波器（arriva....Read More >

在WebRTC GCC(Google Congestion Control)中，有一个叫做AlrDetector（Application limited region detector）的模块。该模块利用某段时间值，以及这段时间发送的字节数判断当前输出网络流量是否受限。这些限制主要跟应用程序本身输出网络流量的能力有关，例如编码器性能，不能编码出设置的目标码率。下面举个简单例子说....Read More >

根据W3C的WebRTC 1.0: Real-time Communication Between Browsers规范，WebRTC的源码中定义了两套主要的C++接口，分别是MediaStream与PeerConnection相关的API。本篇文章主要介绍下MediaStrea....Read More >

使用RTP协议封装数据时，我们可以通过RTP头部的序列号连续性判断是否丢包。但由于RTP头部序列号只有两字节表示，值范围[0,65535]，存在回绕问题（参考之前文章：WebRTC研究：RTP中的序列号以及时间戳比较，建议先阅读一遍此文章）。所以判断序列号连续性时得考虑回绕问题。下面我们就结合WebRTC这相关源码，讲下如何有效地根据序列号进行丢包判断。首先看下这块代码....Read More >

在使用RTP协议时，如果需要网络对抗，保障QoS（Quality of Service，服务质量），我们需要通过序列号以及时间戳的比较，以进行丢包、乱序等处理。但是有个问题，比如一个RTP包，序列号为number1:5000，另一个RTP包序列号为number2:60000，可以....Read More >

WebRTC采用UDP传输流媒体数据，不可避免存在丢包情况。WebRTC主要采用FEC（Forward Error Correction，前向纠错）以及NACK（negative-acknowledge character，否定应答）对抗网络丢包。对于NACK，遇到丢包了才通知发送端重传对应数据包，但不是所有情况下某个包丢了就一定重传该包，有些场景下，重传该包会带来其它问题，例....Read More >

在音视频领域，想深入研究的话，必定会接触WebRTC。WebRTC是一个庞大的工程，就像是音视频领域的百科全书，音视频采集，编解码，传输，渲染等一条龙在WebRTC里都有，而且WebRTC还有很多先进的音视频处理算法。由于WebRTC代码过于庞大，所以最好单步调试跟踪代码运行，这....Read More >