GNOME Bugzilla – Bug 769972
rtpbin: remove arbitrary cutoff to not update ts-offset
Last modified: 2018-11-03 15:10:49 UTC
Created attachment 333402 [details] [review] rtpbin: remove arbitrary cutoff to not update ts-offset rtpbin: remove arbitrary cutoff to not update ts-offset
This is really to ask for feedback from someone who knows RTP. I received a log from a client where this limit would trigger, and A/V would keep out of sync. Looking at the logs, we have a jitterbuffer log a bit before where the skew is set, with a bit more than 3 seconds: rtpjitterbuffer rtpjitterbuffer.c:487:calculate_skew:<unknown> delta - skew: 0:00:03.097799643 too big, reset skew rtpjitterbuffer rtpjitterbuffer.c:487:calculate_skew:<unknown> delta - skew: 0:00:03.089132521 too big, reset skew In turn, this will cause rtpbin to not update ts-offset. Looking at git history, this cutoff seems totally arbitrary (introduced in 93228ccd525f318fa1ad633ed28c5a728b5740ef). I just don't know much about RTP and whether this limit needs to exist at all to prevent some other undesirable behavior (I don't understand what these deltas are in the first place either). Alternatively, I could add a property for this, defaulting to 3 seconds.
Adding Wim in CC as he initially wrote this. I wonder if very large offsets are not ignored to ignore somewhat buggy senders... As it makes little sense for the sender to send audio and video with such a large offset and expect the recipient to correct that.
It's added for buggy servers, yes. And similar for the cutoff that is controlled by the max-rtcp-rtp-time-diff property, which I added for similar purposes to get around a hardcoded value.
The issue I've seen is that a single stream can get horribly out of order (packet reordering/retransmits) by a number of seconds, so that the base time is wrong by seconds. The tsoffset then ends up being just over the limit (3s), but it can never be corrected due to the clamping. Perhaps the more reasonable approach is to not allow the tsoffset to expand by more than 3s, but allow it to reduce?
pcap capture of rtp/rtcp packets of a video source when the client has a bad connection causing packet reordering and large skew. https://drive.google.com/open?id=0B12AhxvnYHrAWmxwSnZWUXcwMTA
The code already only prevents the offset to "increase" to over 3s. The problem is that the initial state is wrong and we have no way to know that we need to increase the correction to fix it. So maybe we should instead just increase the 3s to a larger number, like 5s or 10s. Or maybe just make it configurable.
-- 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/290.