GNOME Bugzilla – Bug 354845
setting not fully connected pipeline to PAUSED locks up
Last modified: 2006-09-15 21:19:43 UTC
I have a partial pipeline. If I set this to paused I expect a warning/error on the bus. Instead it blocks forever (see log below) Something similar seems to be to run gst-launch audioconvert ! alsasink This will preroll forever. 0:00:58.521522000 29801 0x809e360 INFO bt-core song.c:490:bt_song_play: ->PAUSED state change returned 2 0:00:58.521535000 29801 0x809e360 INFO bt-core song.c:497:bt_song_play: ->PAUSED needs async wait 0:00:58.521560000 29801 0x809e360 INFO GST_STATES gstbin.c:1282:gst_bin_get_state_func:<song> getting state 0:00:58.521575000 29801 0x809e360 INFO GST_STATES gstbin.c:1321:gst_bin_recalc_state:<song> recalc state 0:00:58.521590000 29801 0x809e360 INFO GST_STATES gstbin.c:1331:gst_bin_recalc_state:<song> checking element states 0:00:58.521608000 29801 0x809e360 DEBUG GST_STATES gstelement.c:1655:gst_element_get_state_func:<input_gain_0x8516f38> getting state 0:00:58.521624000 29801 0x809e360 DEBUG GST_STATES gstelement.c:1730:gst_element_get_state_func:<input_gain_0x8516f38> state current: PAUSED, pending: VOID_PENDING, result: 1 0:00:58.569472000 29801 0x809e360 DEBUG GST_STATES gstelement.c:1655:gst_element_get_state_func:<input_level_0x8516f38> getting state 0:00:58.569498000 29801 0x809e360 DEBUG GST_STATES gstelement.c:1730:gst_element_get_state_func:<input_level_0x8516f38> state current: PAUSED, pending: VOID_PENDING, result: 1 0:00:58.569517000 29801 0x809e360 INFO GST_STATES gstbin.c:1282:gst_bin_get_state_func:<master_0x8516f38> getting state 0:00:58.569533000 29801 0x809e360 INFO GST_STATES gstbin.c:1321:gst_bin_recalc_state:<master_0x8516f38> recalc state 0:00:58.569548000 29801 0x809e360 INFO GST_STATES gstbin.c:1331:gst_bin_recalc_state:<master_0x8516f38> checking element states 0:00:58.569563000 29801 0x809e360 INFO GST_STATES gstbin.c:1282:gst_bin_get_state_func:<player> getting state 0:00:58.569578000 29801 0x809e360 INFO GST_STATES gstbin.c:1321:gst_bin_recalc_state:<player> recalc state 0:00:58.569593000 29801 0x809e360 INFO GST_STATES gstbin.c:1331:gst_bin_recalc_state:<player> checking element states 0:00:58.569608000 29801 0x809e360 INFO GST_STATES gstbin.c:1282:gst_bin_get_state_func:<bin0> getting state 0:00:58.569623000 29801 0x809e360 INFO GST_STATES gstbin.c:1321:gst_bin_recalc_state:<bin0> recalc state 0:00:58.569637000 29801 0x809e360 INFO GST_STATES gstbin.c:1331:gst_bin_recalc_state:<bin0> checking element states 0:00:58.569652000 29801 0x809e360 DEBUG GST_STATES gstelement.c:1655:gst_element_get_state_func:<alsasink0> getting state 0:00:58.569667000 29801 0x809e360 DEBUG GST_STATES gstelement.c:1730:gst_element_get_state_func:<alsasink0> state current: READY, pending: PAUSED, result: 2 0:00:58.569701000 29801 0x809e360 INFO GST_STATES gstbin.c:1420:gst_bin_recalc_state:<bin0> bin RETURN is now 2 0:00:58.569716000 29801 0x809e360 DEBUG GST_STATES gstelement.c:1655:gst_element_get_state_func:<bin0> getting state 0:00:58.569730000 29801 0x809e360 DEBUG GST_STATES gstelement.c:1730:gst_element_get_state_func:<bin0> state current: READY, pending: PAUSED, result: 2 0:00:58.569746000 29801 0x809e360 INFO GST_STATES gstbin.c:1420:gst_bin_recalc_state:<player> bin RETURN is now 2 0:00:58.569761000 29801 0x809e360 DEBUG GST_STATES gstelement.c:1655:gst_element_get_state_func:<player> getting state 0:00:58.569776000 29801 0x809e360 DEBUG GST_STATES gstelement.c:1730:gst_element_get_state_func:<player> state current: READY, pending: PAUSED, result: 2 0:00:58.569792000 29801 0x809e360 INFO GST_STATES gstbin.c:1420:gst_bin_recalc_state:<master_0x8516f38> bin RETURN is now 2 0:00:58.569807000 29801 0x809e360 DEBUG GST_STATES gstelement.c:1655:gst_element_get_state_func:<master_0x8516f38> getting state 0:00:58.569821000 29801 0x809e360 DEBUG GST_STATES gstelement.c:1730:gst_element_get_state_func:<master_0x8516f38> state current: READY, pending: PAUSED, result: 2 0:00:58.609389000 29801 0x809e360 INFO GST_STATES gstbin.c:1420:gst_bin_recalc_state:<song> bin RETURN is now 2 0:00:58.609414000 29801 0x809e360 DEBUG GST_STATES gstelement.c:1655:gst_element_get_state_func:<song> getting state 0:00:58.609430000 29801 0x809e360 INFO GST_STATES gstelement.c:1694:gst_element_get_state_func:<song> waiting for element to commit state
This isn't a bug. gst_element_set_state() isn't blocking, and if you don't want your application to block, you shouldn't call the (blocking) gst_element_get_state(..., -1).
The let me formulate the question differently: How can the application developer ensure that the pipline will run *or* and error gets returned? This might be a lesser problem in a simple media player, but in content creation tools the user mainly plugs components together. GStreamer doe not like to have unplugged elements in a pipeline. This is not a blocker bug or something, but I think GStreamer should support the developer in handling these cases.
No a bug: - The sink is waiting to preroll which will never happen as it is not commected. This is normal behaviour, an application should not add a sink if it is not linked yet. gst-launch is simple and stupid; it also does blocking calls. - The unlinked elements might become linked at some time in the future, GStreamer cannot know this. gst-launch depends on this behaviour to handle dynamic pads. This is a way for an application to ensure that all sinks will preroll: - there are no dynmic things going on in the pipeline (dynamic pads that might link/unlink elements, timouts to add and link/unlink elements, ...) - use gst_bin_iterate_sinks() to follow the dataflow upstream, if each of the sinks reach a source element, it´ll likely preroll. Some remarks: - Even if a sink is linked, it might not preroll because it receives no data (a demuxer does not produce data on that pad). Sparse steams might help.. - before you run a pipeline, remove (or state lock) all unlinked sinks. Can we do more?
I will close the bug. I wrote a small test app: * unconnected sources can be detected via bus-message * unconnected effects dont cause any fuzz * unconnected sinks preroll forever To handle the latter case I now subscribe to the message::state-changed signal of the bus. When the pipelien reached paused, I send my tags and newsegment and switch to playing. If this returns ASYNC I start a timeout handler that aborts playback after a short while. Not very nice but works for now.