After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 784785 - rtspsrc: reduce default latency from 2.0 secs to 0.5 secs
rtspsrc: reduce default latency from 2.0 secs to 0.5 secs
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-07-11 10:13 UTC by Tim-Philipp Müller
Modified: 2018-11-03 15:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
rtspsrc: reduce default latency from 2.0 secs to 0.5 secs (892 bytes, patch)
2017-07-11 10:13 UTC, Tim-Philipp Müller
none Details | Review

Description Tim-Philipp Müller 2017-07-11 10:13:51 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.
Comment 1 Tim-Philipp Müller 2017-07-11 10:40:13 UTC
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.
Comment 2 Olivier Crête 2017-07-11 13:28:54 UTC
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.
Comment 3 Jan Schmidt 2017-07-14 05:15:00 UTC
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.
Comment 4 Nicolas Dufresne (ndufresne) 2017-07-14 12:48:00 UTC
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.
Comment 5 Olivier Crête 2017-07-14 14:26:05 UTC
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.
Comment 6 GStreamer system administrator 2018-11-03 15:20:44 UTC
-- 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.