GNOME Bugzilla – Bug 608136
multiqueue handles UNEXPECTED flowreturn wrongly
Last modified: 2010-01-26 16:08:25 UTC
when multiqueue receives an UNEXPECTED flowreturn from downstream (like when mp3parse clips) it shuts down the pushing thread on the srcpad. This causes a subsequent EOS event to remain in the queue and makes the pipeline fail to go EOS. This was discovered when configuring a stop position on avidemux.
Created attachment 152294 [details] [review] proposed patch Possible simple and sufficient patch. A more complicated patch (like how queue handles UNEXPECTED) would be more ideal but needs some more work.
Comment on attachment 152294 [details] [review] proposed patch Looks good to me, please push.
Created attachment 152303 [details] [review] updated patch There was a problem with the previous patch, in the case we realy send an EOS downstream we do need to shut down the task and the current code has no way of passing on what case we are in. This patch is a quick fix to make things somewhat work better but we should really do what queue does.
Ok.
ok, multiqueue needs to rethink its locking to make this work correctly. Going to commit the lazy fix.
commit fbdf4dcedad8692f1e3d8838551188987e462e74 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Tue Jan 26 12:43:09 2010 +0100 multiqueue: handle UNEXPECTED flowreturn better When we receive an UNEXPECTED flowreturn from downstream, we must not shutdown the pushing thread because upstream will at some point push an EOS that we still need to push further downstream. To achieve this, convert the UNEXPECTED return value to OK. Add a fixme so that we implement the right logic to propagate the flowreturn upstream at some point. Also clean up the unit test a little. Fixes #608136