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

在使用RTP协议时，如果需要网络对抗，保障QoS（Quality of Service，服务质量），我们需要通过序列号以及时间戳的比较，进行丢包判断。但是有个问题，比如一个RTP包，序列号为number1:5000，另一个RTP包序列号为number2:60000，可以说60000一定比5000大，是个更新的RTP包吗？ 当然不是了，首先我们先重温下RTP数据包的结构。 在RFC3550中RTP固定报头结构按如下定义： [crayon-647ca736ecaec910590940/] 可以看到，RTP序列号sequ…

WebRTC采用UDP传输流媒体数据，不可避免存在丢包情况。WebRTC主要采用FEC（Forward Error Correction，前向纠错）以及NACK（negative-acknowledge character，否定应答）对抗网络丢包。对于NACK，遇到丢包了才通知发送端重传对应数据包，但不是所有情况下某个包丢了就一定重传该包，有些场景下，重传该包会带来其它问题，例如增大延时，缓存过大，同时也可能发送端没有该数据包缓存，导致无法重传，此时会放弃重传该包。由于关键帧可以单独解码出图像，不参考前后视频帧，所…

在音视频领域，想深入研究的话，必定会接触WebRTC。WebRTC是一个庞大的工程，就像是音视频领域的百科全书，音视频采集，编解码，传输，渲染等一条龙在WebRTC里都有，而且WebRTC还有很多先进的音视频处理算法。由于WebRTC代码过于庞大，所以最好单步调试跟踪代码运行，这样才可以更好地学习WebRTC，否则很难有头绪。工欲善其事必先利其器，作为调试神器，宇宙第一IDE Visual Studio必不可少。所以本篇文章主要讲下如何在Windows上编译WebRTC，同时得到VS工程，然后调试。 本文内容截止2…