From 404b646b6ecff6db17836f8eab3efb208989f2a1 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Sebastian=20Dr=C3=B6ge?= Date: Tue, 23 Aug 2022 19:40:54 +0300 Subject: [PATCH] bin: Don't propagate state change errors of elements in locked state Theoretically having elements in locked state should not have any effect at all when the surrounding bin is doing state changes. However previously a state change error of a locked element would cause the bin's state change to also fail, which is clearly not intended. State change failures of locked elements are to be handled by whoever set the element to locked state. By always returning them here it is impossible for the owner of the element to handle state change failures gracefully without potentially affecting the whole pipeline's state changes. Non-failure returns are still returned as-is as the distinction between ASYNC/NO_PREROLL/SUCCESS has big consequences on the state changes of the bin and overall pipeline. Theoretically SUCCESS should also be returned in all cases but I can't estimate the effects this would have on the overall pipeline. Part-of: --- subprojects/gstreamer/gst/gstbin.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/subprojects/gstreamer/gst/gstbin.c b/subprojects/gstreamer/gst/gstbin.c index f1d8f5b..116bd0f 100644 --- a/subprojects/gstreamer/gst/gstbin.c +++ b/subprojects/gstreamer/gst/gstbin.c @@ -2586,9 +2586,16 @@ no_preroll: locked: { - GST_DEBUG_OBJECT (element, - "element is locked, return previous return %s", - gst_element_state_change_return_get_name (ret)); + if (ret == GST_STATE_CHANGE_FAILURE) { + GST_DEBUG_OBJECT (element, + "element is locked, and previous state change failed, return %s", + gst_element_state_change_return_get_name (GST_STATE_CHANGE_SUCCESS)); + ret = GST_STATE_CHANGE_SUCCESS; + } else { + GST_DEBUG_OBJECT (element, + "element is locked, return previous return %s", + gst_element_state_change_return_get_name (ret)); + } GST_STATE_UNLOCK (element); return ret; } -- 2.7.4