GNOME Bugzilla – Bug 784785
rtspsrc: reduce default latency from 2.0 secs to 0.5 secs
Last modified: 2018-11-03 15:20:44 UTC
Created attachment 355318 [details] [review] rtspsrc: reduce default latency from 2.0 secs to 0.5 secs By default rtspsrc uses a fairly high default latency of 2 seconds. I wonder if this really makes sense, and what this is based on. If there's no Good Reason(tm) then perhaps we should reduce that drastically to something lower, maybe 500ms or even 250ms ? People who are on very bad networks can still set this to something higher manually.
I'd also argue that there's been a shift in usage. Back in the day RTSP was something people would use to watch video on the internet (bbc news or such). I don't think that's really the case any more, this is all HLS/DASH/HTML5/Flash now. 99% of RTSP use cases are on local networks nowadays, and having such a high latency is confusing for many users, they just think our RTSP support is lousy. Of course it would be great if we could have dynamic latency adjustments etc. etc., but I don't see how that's a reason to keep the high default latency we have now.
I'd rather we keep the high default until we can make it more dynamic. An easy way to make it dynamic would be to monitor the packet drops and when it gets over a certain thresdhold, just double the latency. This is what VLC does it and seems to work quite well. And we can also add a maximum latency, and if it doesnt work even at that latency, declare the stream as failed.
I'm wary of blindly reducing the default latency setting too far in the general case because we still want arbitrary Internet streams to play properly by default. I'm not averse to reducing it somewhat though - 2 seconds is a big latency - maybe 1 second is OK? As you say, the ideal would be able to adjust on the fly - but that's not possible without glitch if we're really configured to play a live stream. You either need to drop some data to reduce the latency, or pause and rebuffer to increase it.
Out of scope, but I believe A proper dynamic jitterbuffer would start really small, and increase as needed during the preroll phase in order to avoid glitches, and would later update only if the streams is going to be late (rebuffering) or unrecoverable lost hapenned.
Watching security cameras over a tunnel over the Internet is also a pretty common use-case. Maybe we should have a different latency for UDP and TCP-interleaved.
-- 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/388.