GNOME Bugzilla – Bug 597689
decodebin: too much buffering for audio stream, multipartdemux doesn't signal no-more-pads
Last modified: 2018-05-05 15:06:12 UTC
I use playbin2 with souphttpsrc to play audio over http. The problem I found is that decodebin2 adds a multiqueue element with the max-size-bytes property set to 2MB. This is done in gstdecodebin2.c, gst_decode_group_new(). This may be fine for video, but for audio it corresponds to several minutes of data. The result is that the pipeline is 'buffering' for several minutes before the first audio sample is pushed to the audio decoder.
That's only a problem if demuxers or other "dynamic pad" elements are used, that fail to emit the no-more-pads signal at the correct time. Which stream or what kind of stream are you using? If it's FLV then this a duplicate of bug #597091.
Sebastian: are you sure? We deliberately buffer when doing things over HTTP, and the reporter's description sounds like how it should work given the current design. The proper approach to this would be to put parsers in before the buffering queue, so that we can buffer N seconds of data, rather than M bytes. I haven't thought about the implementation details of this though.
The demuxer used was multipartdemux.
(In reply to comment #2) > Sebastian: are you sure? We deliberately buffer when doing things over HTTP, > and the reporter's description sounds like how it should work given the current > design. > > The proper approach to this would be to put parsers in before the buffering > queue, so that we can buffer N seconds of data, rather than M bytes. I haven't > thought about the implementation details of this though. Yes, that's exactly the problem with multipartdemux. decodebin2 must wait until all decoded pads are available before it starts exposing them... and it does this either by waiting for no-more-pads or by waiting for that queue (with 2MB limit) to overrun. Because multipartdemux *never* signals no-more-pads (and can't in a sane way) this is a big problem here :) The buffering you're talking about is separate from this (and working correctly). Not sure what we can do about this bug
We've added a "single-stream" property now to make it emit no-more-pads, see bug #616686 . Not sure what else can be done here.
This doesn't happen anymore with decodebin3 and playbin3. Closing as obsolete.