GNOME Bugzilla – Bug 580121
race condition in GStreamer state changes causes problems in id3v2mux tests
Last modified: 2009-04-24 17:34:01 UTC
I'm not sure if this is a regression or not. I suspect it is, or at least a pre-existing race exacerbated by the async message handling changes. It causes problems when a pipeline containing no async elements is set to playing, and then inserts an async element on the way - such as the test for id3v2mux, which adds fakesinks to each pad exposed by an id3demux element. The fix is really simple, and Wim and I both think it should go in this release: http://cgit.freedesktop.org/~thaytan/gstreamer/commit/?h=work&id=c7f8fed3844b7e72cec85c8ee312752193671a80
Or even something like this: diff --git a/gst/gstbin.c b/gst/gstbin.c index 39da827..1d8deaf 100644 --- a/gst/gstbin.c +++ b/gst/gstbin.c @@ -2523,6 +2523,7 @@ gst_bin_continue_func (BinContinueData * data) transition = (GstStateChange) GST_STATE_TRANSITION (current, next); GST_STATE_NEXT (bin) = next; + GST_STATE_PENDING (bin) = pending; /* mark busy */ GST_STATE_RETURN (bin) = GST_STATE_CHANGE_ASYNC; GST_OBJECT_UNLOCK (bin);
That also fixes the problem for me - please commit :)
commit 81cadeecd27ad39fcda3be0c2771ff03276dcab8 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Fri Apr 24 19:36:22 2009 +0200 GstBin: set PENDING_STATE correctly Set the pending state correctly when we are going to perform an async state_continue on the bin. Fixes #580121