neteq的RELATIVE_ARRIVAL_DELAY，INTER_ARRIVAL_TIME的抖动计算区别

正文
neteq两种模式: RELATIVE_ARRIVAL_DELAY，INTER_ARRIVAL_TIME，两者计算抖动方式的存在区别

如上图所示:
RELATIVE_ARRIVAL_DELAY(简称relative_delay)的计算相邻两个点的iat_ms，然后从区间头进行累加到当前(数学展开的话，可以发现是每个包和第一个包求传输延时different)
INTER_ARRIVAL_TIME(简称iinter_delay)就只是单纯的计算当前包和前一个到达包的传输时延different
上图是一个拥塞发生的场景，随着拥塞上涨，rtt持续上涨，就不能单纯的用相邻的包间传输延时差去估计抖动了，需要综合整段区间的信息，所以relative_delay在该场景就更为准确，更能反应这段拥塞区间下的实际抖动 (在webrtc中这个区间大小被设置为100个样本点，webrtc opus 20ms为的话，大概就是2s)

而如果单纯的通过包间抖动去计算的话，如上图中的interval_delay, 算出来的抖动较小，取点4为例，relative_delay算出来的是100， 而interval_delay算出来的只有60
为什么点4的抖动100ms被认为更合理呢？
如果是60ms, 在第260ms减去多存的这60ms, 260ms - 60ms = 200ms，在200ms这个点是没有帧可以播的；
但如果是100ms， 260ms-100ms = 160ms，缓存的前三帧恰好能支撑到160ms，所以对于点4认为是100ms的抖动是合理的；总而言之，100ms是相对于区间的第一个点1计算出来的，充分的考虑到了拥塞+乱序带来的抖动；

relative_delay在上下波动的场景表现如何呢？

如上所示，对于抖动的点，relative_delay计算出来的抖动是10 是合理的；

relative_delay在第一个点就已经抖动的场景表现如何呢？

可以看到第一个点发生抖动后，jitter是从第50ms才开始播放的，这额外播空的10ms相当于撑大了jitter，所以在后续播放的时候计算出来的抖动为0,