[Bug 600648] [multiqueue] Queues up too much data

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #21 from Sebastian Dröge <slomo at circular-chaos.org> 2012-05-11 12:03:13 UTC ---
FWIW the problem (IIRC) here is that after switching streams input-selector
will return OK on all pads until the newly selected pad pushed the first
buffer. If the scheduler is unhappy this will cause lots of buffers going lost
on the now unconnected pads, multiqueue believing the buffers were accepted
correctly (and not triggering its NOT_LINKED logic to synchronize streams)...

Another problem is that if a stream switch happens at a bad time, multiqueue
could wait for input-selector to accept new buffers to advance the stream time
and push a new buffer on the newly selected pad... and input-selector waits for
multiqueue to push a buffer on the newly activated pad before accepting
anything on the other pads.


These two problems also combine with each other making it even more annoying :)



I think for 0.11 we could solve this by explicitely notifying about enabled and
disabled streams (but that might be used very soon, different to completely
unlinked pads that will never be used). This could be done with the help of the
reconfigure event and by adding an optional timestamp field to the reconfigure
event to make sure that playback continues from that position if possible. This
would also require demuxers and/or decoders to handle that.

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