Handle late packets

[ruangustavo]

Hey, Jech! How are you?

The original code did not handle late packets explicitly. It processed all incoming packets, even those with timestamps that were significantly behind the current "origin" timestamp, which is the starting point of the media stream. So, the modified code introduced a check to handle late packets more gracefully. If a packet arrives with a timestamp that is too far behind the current origin timestamp, the code simply drops that packet. Dropping late packets avoids processing and recording outdated media samples, which could otherwise lead to incorrect playback or unnecessary resource consumption.

[jech]

Could you please explain why this is necessary. Will the late packet not be dropped by the samplebuilder?

[ruangustavo]

In certain situations, the samplebuilder faces difficulties maintaining the accuracy of recorded media data. It struggles with timestamp wraparound, causing confusion in timestamp calculations and affecting media continuity. Additionally, if there is excessive consecutive packet loss, it may create gaps in the recorded media that go beyond the jitter buffer's capability to handle.

[jech]

So there's a bug in the samplebuilder? If so, then let's fix it there instead.

https://github.com/jech/samplebuilder