adaptivedemux: release manifest lock before sending flush stop event

https://bugzilla.gnome.org/show_bug.cgi?id=757337
This commit is contained in:
Florin Apostol 2015-10-30 00:04:12 +00:00 committed by Vincent Penquerc'h
parent e29514ea3d
commit e0ef335426

View file

@ -2302,13 +2302,22 @@ gst_adaptive_demux_stream_download_uri (GstAdaptiveDemux * demux,
/* flush the proxypads so that the EOS state is reset */
gst_pad_push_event (stream->src_srcpad, gst_event_new_flush_start ());
gst_pad_push_event (stream->src_srcpad, gst_event_new_flush_stop (TRUE));
/* changing source state will join the streaming thread. That thread can
* try to get the manifest_lock, so we must release it here.
/* sending flush stop event will serialiase on stream->src_srcpad.
* But the _src_chain function will first get the pad lock and then the
* manifest lock, so we cannot hold the manifest lock here while
* we will try to get the pad lock (taking locks in reversing order
* will lead to deadlock)
*
* In conclusion, we need to release the manifest lock before flushing
*/
GST_MANIFEST_UNLOCK (demux);
gst_pad_push_event (stream->src_srcpad, gst_event_new_flush_stop (TRUE));
/* changing src element state might try to join the streaming thread, so
* we must not hold the manifest lock.
*/
gst_element_set_state (stream->src, GST_STATE_READY);
GST_MANIFEST_LOCK (demux);