Created attachment 339947 [details] [review]
nlecomposition: Start task and initialize the stack after chaining up to parent's change state function

Otherwise we could set the state of the children to PAUSED already (i.e.
start dataflow) from the composition's task, while the composition
itself is currently chaining up to the parent class' change state
function and did not activate the pads yet. This causes buffers and
events to be discarded, and everything to stop with a not-negotiated
error.

The other change state functions in nle/ges should also be reviewed. E.g.: should commit/prepare in nleobject be called *before* the parent's change state function as they are now, or rather afterwards?

Created attachment 340026 [details] [review]
nlecomposition: Start task and initialize the stack after chaining up to parent's change state function

Otherwise we could set the state of the children to PAUSED already (i.e.
start dataflow) from the composition's task, while the composition
itself is currently chaining up to the parent class' change state
function and did not activate the pads yet. This causes buffers and
events to be discarded, and everything to stop with a not-negotiated
error.

Created attachment 340027 [details] [review]
nleobject: Start up in NULL->READY->PAUSED after the parent class did

This keeps everything in a more consistent order and makes sure that the
base class is already set up completely before we start doing anything.
It also prevents from doing any setup if the base class fails, and
possibly not shutting things down again then.

Bug can be reproduced by existing unit tests, when just adding a e.g. 1s sleep after the _initialize_stack_func action is scheduled. Then it will execute first before chaining up to the parent class' change_state func.

Attachment 340026 [details] pushed as 57d40be - nlecomposition: Start task and initialize the stack after chaining up to parent's change state function
Attachment 340027 [details] pushed as 5f7943c - nleobject: Start up in NULL->READY->PAUSED after the parent class did

https://ci.gstreamer.net/job/GStreamer-master-meson-validate/218/testReport/junit/ges.playback.scrub_backward_seeking.test_mixing/audio_video/flac_jpeg_mkv/

Actually: https://ci.gstreamer.net/job/GStreamer-master-meson-validate/218/#showFailuresLink

Problem here seems to be that for some reason elements are in PAUSED but not moving to PLAYING. Unclear where this comes from with the above patches.

My guess is that the child state handling needs a proper review and cleanup. Will check what happens if I can reproduce it somehow (the tests did not fail for me, let's try gst-validate later).

Any idea about that one? I can't figure out what happened here in the end :-)

The commits were reverted and the problem still exists.

-- 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/gst-editing-services/issues/32.