GNOME Bugzilla – Bug 621833
Setting a pipeline to NULL can sometimes fail due to core state changes going in the wrong direction
Last modified: 2012-05-22 00:59:06 UTC
Created attachment 163876 [details] [review] Add test to core testsuite that this works (currently fails) It should always be possible to set a pipeline to NULL - this must not fail, otherwise it's impossible to safely unref the pipeline. Because upwards state changes CAN (and do) fail - for example, a filesink getting an error because the destination is read-only - it's imperative that a downwards state change on a pipeline never cause upwards state changes of elements inside it. This is not currently the case - sometimes core will attempt to move an element to a higher state as part of a downwards state change, and if that fails the downwards state change will then fail. I thought this was handled in bug #368536, but that change does not fix the problem entirely. The attached test case fails on current git. I'll also attach the (hacky) workaround I'm currently using - I don't know if this is the right approach, though something similar was rejected previously, so I guess Wim doesn't like this.
Created attachment 163877 [details] [review] Simple patch to fix test. I don't know if this handles all important cases, however.
Any news on this? Wim?
commit 554b81ed243c27385e11b925722b91c2fafdcfb4 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Fri May 18 15:04:35 2012 +0200 bin: try harder to avoid state changes in wrong direction When the bin does an upward state change, try to avoid doing a downward state change on the child and vice versa. Add some more unit tests for this fix. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=621833
gstreamer can't build now, due to use 'gst_pad_set_blocked_async'. :)