GNOME Bugzilla – Bug 768715
rtpjitterbuffer: Considers packets too late due to wraparound
Last modified: 2018-11-03 15:10:28 UTC
https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtpmanager/gstrtpjitterbuffer.c?id=5328378132c7c100b8a17818862a3124affef1f8#n2829 This check will also trigger if more than 2**15 packets are queued up in the jitterbuffer, as the latest packet we received will then be considered as a wraparound close to the latest packet we popped. The check will have to be made more correct somehow, or removed completely (why is it there at all?). It was added in commit eaa23fd4 in 2008 :) We could probably just add the number of queued up packets to the last popped sequence number, and use that for comparison. It's not going to be 100% correct (there might be missing packets), but it should be far less than 2**15 (otherwise we would've reset already). Any better ideas?
Another option would be to track extended seqnums everywhere, which will probably be required for the jitterbuffer to not explode anyway (we could have multiple packets with the same 16 bit seqnum otherwise).
Can we reasonably have more than 2^15 packets in the queue? If you do, maybe we should add something to limit the size of the queue inside the jitterbuffer instead?
If you have a latency of 2 seconds, a packet size of 1400 bytes and a stream with 22MB/s (megabyte, not bit) then you end up with this situation :) With raw video you can easily get there.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/286.