[Bug 707156] decodebin deadlocks multiqueue

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=707156
  GStreamer | gstreamer (core) | git

--- Comment #3 from Sebastian Dröge (slomo) <slomo at circular-chaos.org> 2013-09-02 11:09:55 UTC ---
<slomo> wtay: https://bugzilla.gnome.org/show_bug.cgi?id=707156  do you have an
opinion on that? :)
<wtay> slomo, yes, I agree to not set the size smaller than current size
<slomo> wtay: alright, i will do that then :) thanks

<slomo> wtay: and the limits from the settings should be set in READY->PAUSED
again?
<wtay> slomo, limits from settings?
<slomo> wtay: the ones from the properties
<slomo> wtay: talking about multiqueue still :)
<wtay> slomo, but that's in decodebin2, no, which recreates the multiqueue when
it goes to READY, so how does it matter?
<slomo> wtay: i'm thinking of fixing this in multiqueue... for decodebin it's
not a problem, right
<wtay> slomo, how would you do that?
<slomo> wtay: in set_property() only update the singlequeue values if >=
current, in READY->PAUSED reset all values in the singlequeues
<wtay> slomo, I understood that during discovery we set very few limits on the
multiqueue and then after discovery of the streams, we add some more
constraints, but that's all in decodebin2
<wtay> oh really
<wtay> that's unusual
<slomo> that was my idea how to fix it in multique, not how it is currently btw
;)
<slomo> so the problem is that multiqueue grows the singlqueues automatically
in some cases, and if we set the limits in decodebin again we will ignore this
automatic growth and set it back to a fixed value
<slomo> which will break stuff
<wtay> yes, so my idea was to get the current levels and then only update those
that are larger
<slomo> but decodebin does not know about the singlequeue levels, shouldn't
that also all be done inside multiqueue instead?
<wtay> that's true
<wtay> whay change the levels at all, anyway?
<slomo> to keep memory usage and the amount of buffering lower i guess
<slomo> during pre-rolling we just allow more to have enough time to find all
the streams
<slomo> but then... if we lower the levels because of overrun nothing will
usually happen anyway
<wtay> but multiqueue already does that by itself now
<slomo> because current >= limit , otherwise it would not overrun
<slomo> does what by itself?
<wtay> ah, in the case of no no-more-pads
<wtay> it keeps the levels as low as possible but still have data in all queues
<wtay> by bumping the max-size-buffers if a queue is empty and another overruns
<wtay> so you end up with the lowest possible amount of data while still having
enough to demux the file
<slomo> yes
<wtay> yes, there are also time and bytes levels but those are normally never
hit
<wtay> and if they are, it's because a really badly muxed file or because of
no-more-pads
<slomo> so you say we should just not have this preroll levels in decodebin?
<wtay> the only possible reason would be for the demuxers without no-more-pads
<wtay> so, have a high queue level to find the streams, then let it drain to
something smaller why streaming
<wtay> while
<wtay> the problem is really finding what smaller limit is acceptable
<wtay> when no-more-pads is signalled, this is exactly what multiqueue is using
now, so there is no reason to change it
<wtay> in the case no-more-pads is not signaled, we don't know..
<wtay> so, don't change the queue sizes if no-more-pads was signaled sounds
better
<slomo> sounds like a plan :)
<slomo> or not
<slomo> during prerolling we allow higher levels, but during prerolling we
don't know if the demuxer emits no-more-pads or not
<slomo> so we would always use the high levels for no-more-pads demuxers
<wtay> yes, but that's all right
<wtay> they won't just be hit, it'll use the max-size-buffers that has been
found automatically
<wtay> (this code is all from when we didn't try to find the optimal
max-size-buffers)
<slomo> hmm
<slomo> i'm convinced
<slomo> let's do that then :)
<slomo> after a coffee
<wtay> I guess you could also look at the current bytes and time levels and use
the alternative levels only if they are smaller

-- 
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.