After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 743719 - Changing bin state to NULL fails when there is a locked child which is locked
Changing bin state to NULL fails when there is a locked child which is locked
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-01-29 23:30 UTC by Olivier Crête
Modified: 2018-11-03 12:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
bin: Ignore failures from state locked elements when going to NULL (4.58 KB, patch)
2015-01-29 23:31 UTC, Olivier Crête
reviewed Details | Review

Description Olivier Crête 2015-01-29 23:30:35 UTC
If a pipeline (or any bin) has a child which has it's state locked and it's last transition was a failure, then the pipeline/bin transition to the NULL state will fail. But it is my understanding that gst_element_set_state(GST_STATE_NULL) should never fail.

I'm attaching a patch that just transforms failure into success in the locked case if the target is READY or NULL.

Python test program:

import sys

Gst.init(sys.argv)

p = Gst.Pipeline()
p.set_state(Gst.State.PLAYING)
s = Gst.ElementFactory.make("filesrc", None)
p.add(s)
s.set_locked_state(True)
s.set_state(Gst.State.PLAYING)

print p.set_state(Gst.State.NULL)
Comment 1 Olivier Crête 2015-01-29 23:31:01 UTC
Created attachment 295784 [details] [review]
bin: Ignore failures from state locked elements when going to NULL

Also add a small unit test for locked state behavior
Comment 2 Sebastian Dröge (slomo) 2015-01-30 17:31:04 UTC
Comment on attachment 295784 [details] [review]
bin: Ignore failures from state locked elements when going to NULL

Makes sense but shouldn't locked elements be ignored completely (even when going to PAUSED or PLAYING, not only when going to NULL or READY)? Even if they failed some state change, they shouldn't influence any new state change of the parent because they're locked IMHO.
Comment 3 Olivier Crête 2015-01-30 17:44:17 UTC
I think that code  is there because they should return NO_PREROLL or ASYNC when going to PAUSED or PLAYING if that was cached, maybe the condition should be

if (! ((ret == NO_PREROLL || ret == ASYNC) && (newstate == PLAYING || newstate == PAUSED)) ) {
  ret = SUCCESS;
}
Comment 4 GStreamer system administrator 2018-11-03 12:25:08 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/90.