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 706985 - gst_base_sink_is_too_late will report late buffers as ready for rendering every second unconditionally
gst_base_sink_is_too_late will report late buffers as ready for rendering eve...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other All
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-08-28 14:36 UTC by Julien MOUTTE
Modified: 2018-11-03 12:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Julien MOUTTE 2013-08-28 14:36:21 UTC 
In some cases it can be a problem as buffers are very late, though in segment, and rendering them is not desirable.

The emergency procedure to render buffers every second makes sense for a video sink but not really for fakesink and should at least be configurable for appsink. Indeed when rendering subtitles in a newly created decoding branch some formats will start pushing buffers from beginning of segment and the expected behavior would be that they get dropped until we catch up. That's not currently possible with any basesink based element.
Comment 1 Sebastian Dröge (slomo) 2013-08-29 10:09:01 UTC 
I think this should be new basesink API that allows to set this to a different value than 1 second, and also allows to disable it (by setting to -1 or something). Additionally some threshold would be nice to set after which a buffer is considered far too late and is not even emergency rendered.

Want to provide a patch for that?
Comment 2 GStreamer system administrator 2018-11-03 12:18:51 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/gstreamer/issues/43.