[Bug 772646] rtpjitterbuffer: fix lost-event using dts instead of pts

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=772646

--- Comment #5 from Håvard Graff (hgr) <havard.graff at gmail.com> ---
(In reply to Sebastian Dröge (slomo) from comment #4)

> It will break for all cases where you get a packet with a completely
> different seqnum (and timestamp!) but ignore it as there are not enough
> consecutive seqnums following (see the gap code below your PTS calculation,
> the cases where it does not go into reset). So for example some spurious
> packet arriving here.

Sorry, I am not quite following. Why don't we write some tests to check old vs.
new behavior instead of theorizing around it?

If you can describe the behavior you want to make sure are not broken with the
new patch, I am happy to try and write it up. Steady flow of buffers
interrupted with a buffer with completely unrelated seqnum and timestamp, and
then going back to the normal stream? What is the expected behavior? Why would
we encounter such a buffer? Given that this is a stream of the same SSRC, we
would either likely be facing a faulty rtp-implementation (those exist!) or a
malicious attack (those exist too!). I can think of three scenarios:

1. The single bad packet: 1, 2, 3, 4, 60000, 5, 6, 7, 8, etc.
2. Restarting the stream: 1, 2, 3, 4, 60000, 60001, 60002, 60003, etc.
3. Interleaved madness: 1, 2, 3, 4, 60000, 5, 60001, 6, 60002, 7 etc.

Maybe we should first decide what is the desired behavior in each of those
cases, then check how that matches reality for the old and the new
implementation? Sounds good?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.