bin: Don't propagate state change errors of elements in locked state
authorSebastian Dröge <sebastian@centricular.com>
Tue, 23 Aug 2022 16:40:54 +0000 (19:40 +0300)
committerGStreamer Marge Bot <gitlab-merge-bot@gstreamer-foundation.org>
Thu, 25 Aug 2022 15:33:07 +0000 (15:33 +0000)
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: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2932>

subprojects/gstreamer/gst/gstbin.c

index f1d8f5b..116bd0f 100644 (file)
@@ -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;
   }