GNOME Bugzilla – Bug 773097
bin: add disabled test documenting locked-state and base-time problems
Last modified: 2018-11-03 12:37:36 UTC
The added test describes a problem with locked-state and base-time. Currently the test fails with: '123456789' (123456789) is not equal to 'gst_element_get_base_time (identity)' (0). The consequence is that the identity element will never get a base-time even when it later is set to playing.
Created attachment 337845 [details] [review] bin: add disabled test documenting locked-state and base-time problems
I'm not sure it's a bug, the bin&element are not in playing, so it's normal that they don't have a base time. It may be a better test if you afterwards directly set the locked element to playing.
Comment on attachment 337845 [details] [review] bin: add disabled test documenting locked-state and base-time problems What Olivier said
(In reply to Olivier Crête from comment #2) > I'm not sure it's a bug, the bin&element are not in playing, so it's normal > that they don't have a base time. It may be a better test if you afterwards > directly set the locked element to playing. So the problem is that when you set it to playing it will not have a base-time set, so if it needs to interact with a clock in some ways, it will be way off. Also, the clock *will* be set on the identity-element, but not the base-time... Note that if this element is added later on, it will get base-time and clock as part of being added (gst_bin_add_func) which now starts to feel quite inconsistent, since this is unrelated to being in PLAYING or not.
This does feel very inconsistent..
Indeed. Either bin should not update the base time of locked-state children that are just added, or it should also update base time of children that are locked-state. Not sure which one :) Same goes for the start time and clock I'd say. It should be consistent at least.
Why would or should the bin not set base time + clock on the locked children, no matter what state they're in? It seems to me that the state locking should be independent of that.
-- 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/200.