Fix old buffer items cleanup in RTC::RateCalculator

[dsdolzhenko]

This is the fix for the issue described in #818 and the infinite loop found in #819 (the first attempt to fix #818)

[dsdolzhenko]

@rtctt Do you have a chance to verify the fix in the setup you've described in #819?

[ibc]

Thanks. Could you please tell the differences between this PR and the previous one? Specifically to see how this solves the infinite loop.

[dsdolzhenko]

The commit adds a unit test and fixes the case @rtctt described in the previous PR.

Basically, when we receive a packet with timestamp greater or equal than current newestItemStartTime + windowSizeMs we reset the buffer.

I believe the case isn't properly handled in the current version either; even though it doesn't gets into an infinite loop, it calculates bitrate wrong.

[gnauhtt]

@dsdolzhenko I have checked this PR and there is no problem. I understand what you mean, reset the buffer instead of removing the last item to avoid getting stuck in a loop. 👍

[jmillan]

I believe the case isn't properly handled in the current version either; even though it doesn't gets into an infinite loop, it calculates bitrate wrong.

What's wrong?

[dsdolzhenko]

What's wrong?

I suppose, in the edge case, when the next packet timestamp is exactly windowSizeMs away from newestItemStartTime already accumulated stats must be discarded. So, for example, if we receive 5 bits every 1000ms, the bitrate must be 40 rather than 80.

[jmillan]

👍

[jmillan]

Thanks @dsdolzhenko

[ibc]

Thanks a lot, merged and released in 3.9.17.