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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #6 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Håvard Graff (hgr) from comment #5)

> 1. The single bad packet: 1, 2, 3, 4, 60000, 5, 6, 7, 8, etc.

That packet is queued up, but as the following ones are not a continuation it
is dropped again. (we wait for iirc 5 consecutive packets)

> 2. Restarting the stream: 1, 2, 3, 4, 60000, 60001, 60002, 60003, etc.

We queue up the new packets, and after 5 consecutive ones they are all output
after resetting the jitterbuffer

> 3. Interleaved madness: 1, 2, 3, 4, 60000, 5, 60001, 6, 60002, 7 etc.

Chaos :) We would output the 1, 2, 3... stream and queue up the 6000x packets
just to drop them again on the next packet. What comes first wins until there
are 5 consecutive packets of something new

If this is the desired behaviour, I don't know. It seems sensible though and
that was is currently implemented.


The problem here now is that with your patch, case 1) and case 3) are updating
jitterbuffer state for the 6000x packets although they are thrown away. As the
jitterbuffer stores the ext timestamp, recvtimes, sendtimes, this seems
undesirable.

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