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 764900 - controller: notification when last control point reached
controller: notification when last control point reached
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-04-11 14:34 UTC by Uli Franke
Modified: 2018-11-03 12:34 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Uli Franke 2016-04-11 14:34:13 UTC
Provide a way to get a callback, message or similar when a control automation via control source or similar reached its final value, i.e. when automation finished.

This is useful to detect when automation finished and subsequent actions can be taken or to chain automation properly.

For instance fading out before pipeline pause to avoid clicks: start fade out automation, wait for callback, pause pipeline.
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2016-10-07 12:37:44 UTC
Could you have  special property on one of your objects and have a final control event on that property and check for that using notify:<property> ?

For the fade-out example, you can register a notify:volume handler and pause when volume is 0.0.
Comment 2 Tim-Philipp Müller 2016-11-11 18:42:12 UTC
This should work for simple A to B scenarios, but question is still if we want some proper API for this, which would also be more discoverable. If not, let's close it until we run into a use case that can't be solved via notify::
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2016-11-12 17:51:56 UTC
I can understand the user-case. The current controller design so far did not had the need to send events, it merely automates changing parameters. Also controller automation does not really has a notion of an "end" (e.g. LFOs).

If we want an api supporting this, one thing to consider is that sending a bus message from the controlled element is not always the right thing, since that part of the media has not been rendered yet. This could be handled using sink-message events.

Having more use cases would be nice to come up with a good api.
Comment 4 Tim-Philipp Müller 2016-11-12 17:55:30 UTC
Would a signal on the control source make sense?

For LFOs it could just never be triggered.
Comment 5 Stefan Sauer (gstreamer, gtkdoc dev) 2016-11-12 19:40:49 UTC
We could add a signal to GstTimedValueControlSource, but like I said above, the signal would be trigged when the control source has been synced, but not when the media for the timestamp is rendered.
Maybe some control sources can 'emit' something like an EOS. Also the control-bindings could take this to optimize processing. Since the controlbindings have a link to the element, they could post an event.
Comment 6 Tim-Philipp Müller 2016-11-12 20:13:28 UTC
Ah I see, two different "reached".
Comment 7 Tim-Philipp Müller 2018-05-06 14:41:17 UTC
Is there still interest in this or shall we close it for now?
Comment 8 GStreamer system administrator 2018-11-03 12:34:10 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/167.