mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-18 15:51:11 +00:00
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: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2932>
This commit is contained in:
parent
65b15f72b5
commit
404b646b6e
1 changed files with 10 additions and 3 deletions
|
@ -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;
|
||||
}
|
||||
|
|
Loading…
Reference in a new issue