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 764948 - decodebin: use-buffering property ignored on non-muxed streams
decodebin: use-buffering property ignored on non-muxed streams
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: 1.9.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 767102
Reported: 2016-04-12 12:34 UTC by Vivia Nikolaidou
Modified: 2016-06-01 11:44 UTC
See Also:
GNOME target: ---
GNOME version: ---

0001-decodebin-Rename-misleading-variable-is_parser_conve.patch (1.57 KB, patch)
2016-04-12 13:36 UTC, Vivia Nikolaidou
committed Details | Review
0002-decodebin-Always-add-a-multiqueue-in-single-stream-u.patch (1.95 KB, patch)
2016-04-12 13:36 UTC, Vivia Nikolaidou
none Details | Review
0003-fdmemory-rtpbasedepayload-Ran-gst-indent.patch (1.46 KB, patch)
2016-04-12 13:37 UTC, Vivia Nikolaidou
committed Details | Review
0001-decodebin-Always-add-a-multiqueue-in-single-stream-u.patch (2.09 KB, patch)
2016-04-18 14:13 UTC, Vivia Nikolaidou
committed Details | Review

Description Vivia Nikolaidou 2016-04-12 12:34:45 UTC
gst-launch-1.0 -m filesrc location=/home/vivia/song.mp3 ! decodebin use-buffering=true ! fakesink |grep -i ufferi

[No buffering messages received]

That is because no multiqueue is added to decodebin if the stream is not muxed, so the use-buffering property isn't applied anywhere.
Comment 1 Sebastian Dröge (slomo) 2016-04-12 12:56:49 UTC
This is probably a one-liner. You could modify the case that adds a multiqueue after a parser (instead of just after demuxers) when the group starts with an adaptive demuxer. Extend it to also add a multiqueue if the group does not even start with a demuxer.
Comment 2 Vivia Nikolaidou 2016-04-12 13:36:34 UTC
Created attachment 325801 [details] [review]
Comment 3 Vivia Nikolaidou 2016-04-12 13:36:51 UTC
Created attachment 325802 [details] [review]
Comment 4 Vivia Nikolaidou 2016-04-12 13:37:10 UTC
Created attachment 325803 [details] [review]
Comment 5 Vivia Nikolaidou 2016-04-12 13:37:56 UTC
This seems to work, except I bumped into two files where gst-indent hadn't been run, so I indented those too. Please let me know your feedback.
Comment 6 Sebastian Dröge (slomo) 2016-04-13 06:48:53 UTC
Review of attachment 325802 [details] [review]:

::: gst/playback/gstdecodebin2.c
@@ +2403,3 @@
+     */
+    is_decoder = strstr (gst_element_factory_get_metadata (factory,
+            GST_ELEMENT_METADATA_KLASS), "Decoder") != NULL;

For decoders this might not be correct. The uridecodebin property says "Perform buffering on demuxed/parsed media", and for decoded data at least the buffer-size property doesn't make too much sense.

Should probably print a warning in the debug output if the decoder case happens. It's better than not doing any buffering messages at all probably, but far from ideal. Fortunately we have parsers for about every codec that can exist outside containers.

@@ +2405,3 @@
+            GST_ELEMENT_METADATA_KLASS), "Decoder") != NULL;
+    if (!chain->parent && (is_parser || is_decoder) && dbin->use_buffering)

There is a problem here if use_buffering is set to TRUE afterwards. We wouldn't dynamically insert a multiqueue then. But that shouldn't be much of a problem
Comment 7 Vivia Nikolaidou 2016-04-18 14:13:23 UTC
Created attachment 326261 [details] [review]

Thanks for the review. Added a warning message for the decoder case. Please review again.
Comment 8 Sebastian Dröge (slomo) 2016-04-19 07:20:15 UTC
commit 2b536467154ed672be8b49a9681693607723cc60
Author: Vivia Nikolaidou <>
Date:   Tue Apr 12 16:32:20 2016 +0300

    decodebin: Always add a multiqueue in single-stream use-buffering pipelines
    If we are configured to use buffering and there is no demuxer in the chain, we
    still want a multiqueue, otherwise we will ignore the use-buffering property.
    In that case, we will insert a multiqueue after the parser or decoder - not
    elsewhere, otherwise we won't have timestamps.