[gstreamer-bugs] [Bug 597689] [decodebin2] Too much buffering for audio streams when demuxers don't signal no-more-pads

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=597689
  GStreamer | gst-plugins-base | git

Sebastian Dröge <slomo> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |NEW
            Summary|To much buffering in        |[decodebin2] Too much
                   |decodebin2 for audio with   |buffering for audio streams
                   |no time stamps.             |when demuxers don't signal
                   |                            |no-more-pads
     Ever Confirmed|0                           |1

--- Comment #4 from Sebastian Dröge <slomo at circular-chaos.org> 2009-10-08 11:11:43 UTC ---
(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

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.