This fixes a possible deadlock between gst_v4l2_video_dec_change_state
and gst_v4l2_video_dec_loop on the buffer pool.
When stopping capture, the flushing state of the v4l2 capture buffer
pool gets reverted in the processing loop after it was set via
gst_v4l2_object_unlock (self->v4l2capture) (in
gst_v4l2_video_dec_change_state). As a result, gst_v4l2_video_dec_loop
does not return and consequently, gst_pad_stop_task gets stuck waiting
for the GST_PAD_STREAM_LOCK. To circumvent this, skip acquiring the
buffer pool if stopping capture.
Suggested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7987>
GST_VIDEO_DECODER_STREAM_UNLOCK (decoder);
goto beach;
}
+
+ /*
+ * In case we are flushing or stopping the element, ensure the active
+ * state is reflected onto the newly create pool.
+ */
+ if (!g_atomic_int_get (&self->active))
+ gst_v4l2_object_unlock (self->v4l2capture);
}
/* just a safety, as introducing mistakes in negotiation seems rather