[Bug 760532] bin, pipeline, sink: state change / async-done propagation issue with repeated rtspsrc seeks

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=760532

--- Comment #7 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
So the main problem here is that the async-start that happens because of the
lost-state in fakesink is ignored:
gstbin.c:3181:bin_handle_async_start:<pipeline0> state change busy

And it is ignored because GstBin currently continues to do the state change
from PAUSED to PLAYING from the previous time when fakesink lost its state (the
previous seek). To confuse more in the logs, based on the seek event rtspsrc
also changes states of its rtpbin interleaved with everything else but I think
that can be ignored for this bug. Now at some point the state change to PLAYING
finishes, a bit later fakesink does async-done (so we actually have the
pipeline go to PLAYING although fakesink is not prerolled!) but the async-done
is ignored because we have no pending state anymore (we went to PLAYING
successfully already and GstBin did not notice that fakesink lost the state in
the meantime).

So inside handle_async_start() we should probably do something else than just
ignoring when a new async-start arrives.


Additional to all that, there are many places in gstbin.c and gstelement.c that
say they must be called with the GST_STATE_LOCK but they are not. Or that they
are always called with it the GST_STATE_LOCK, but they are not. For which I
have a patch but that doesn't help with this specific problem and it also seems
like it could introduce deadlocks.

I think the locking for state changes has to be generally reviewed again. The
biggest issue here is now that state changes can be triggered from the top
(gst_element_set_state) and from the bottom (lost_state), which just calls from
lock order problems if we use the GST_STATE_LOCK of each bin to protect things
here.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.