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 773097 - bin: add disabled test documenting locked-state and base-time problems
bin: add disabled test documenting locked-state and base-time problems
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-10-17 12:40 UTC by Stian Selnes (stianse)
Modified: 2018-11-03 12:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
bin: add disabled test documenting locked-state and base-time problems (3.28 KB, patch)
2016-10-17 12:40 UTC, Stian Selnes (stianse)
needs-work Details | Review

Description Stian Selnes (stianse) 2016-10-17 12:40:42 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.
Comment 1 Stian Selnes (stianse) 2016-10-17 12:40:47 UTC
Created attachment 337845 [details] [review]
bin: add disabled test documenting locked-state and base-time problems
Comment 2 Olivier Crête 2016-10-18 19:18:00 UTC
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 3 Sebastian Dröge (slomo) 2016-10-20 11:27:37 UTC
Comment on attachment 337845 [details] [review]
bin: add disabled test documenting locked-state and base-time problems

What Olivier said
Comment 4 Håvard Graff (hgr) 2016-10-20 18:41:30 UTC
(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.
Comment 5 Olivier Crête 2016-10-20 20:32:12 UTC
This does feel very inconsistent..
Comment 6 Sebastian Dröge (slomo) 2016-10-21 11:41:58 UTC
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.
Comment 7 Tim-Philipp Müller 2017-11-21 08:53:36 UTC
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.
Comment 8 GStreamer system administrator 2018-11-03 12:37:36 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/200.