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 774480 - nlecomposition: Start task and initialize the stack after chaining up to parent's change state function
nlecomposition: Start task and initialize the stack after chaining up to pare...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-editing-services
unspecified
Other All
: Normal normal
: 1.11.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-11-15 15:57 UTC by Sebastian Dröge (slomo)
Modified: 2018-11-03 12:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
nlecomposition: Start task and initialize the stack after chaining up to parent's change state function (2.72 KB, patch)
2016-11-15 15:57 UTC, Sebastian Dröge (slomo)
none Details | Review
nlecomposition: Start task and initialize the stack after chaining up to parent's change state function (2.72 KB, patch)
2016-11-16 16:12 UTC, Sebastian Dröge (slomo)
committed Details | Review
nleobject: Start up in NULL->READY->PAUSED after the parent class did (2.30 KB, patch)
2016-11-16 16:12 UTC, Sebastian Dröge (slomo)
committed Details | Review

Description Sebastian Dröge (slomo) 2016-11-15 15:57:48 UTC
See commit message
Comment 1 Sebastian Dröge (slomo) 2016-11-15 15:57:52 UTC
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.
Comment 2 Sebastian Dröge (slomo) 2016-11-15 15:58:48 UTC
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?
Comment 3 Sebastian Dröge (slomo) 2016-11-16 16:12:19 UTC
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.
Comment 4 Sebastian Dröge (slomo) 2016-11-16 16:12:25 UTC
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.
Comment 5 Sebastian Dröge (slomo) 2016-11-16 16:48:14 UTC
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.
Comment 6 Sebastian Dröge (slomo) 2016-11-16 18:00:56 UTC
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
Comment 9 Sebastian Dröge (slomo) 2016-11-18 10:47:31 UTC
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).
Comment 10 Thibault Saunier 2018-05-13 18:54:13 UTC
Any idea about that one? I can't figure out what happened here in the end :-)
Comment 11 Sebastian Dröge (slomo) 2018-05-14 06:39:04 UTC
The commits were reverted and the problem still exists.
Comment 12 GStreamer system administrator 2018-11-03 12:53:47 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/gst-editing-services/issues/32.