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 610338 - [0.11] [controller] Triggers should be moved into their own control source
[0.11] [controller] Triggers should be moved into their own control source
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: 0.11.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-02-18 08:19 UTC by Sebastian Dröge (slomo)
Modified: 2011-12-19 22:32 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastian Dröge (slomo) 2010-02-18 08:19:17 UTC
Hi,
currently triggers are part of the interpolation control source. This has some limitations. For 0.11 we should move it to its own control source, which has additional parameters like a tolerance interval. Currently triggers are only triggered if the timestamp matches the trigger timestamp to the nanosecond, which is quite problematic for various sampling rates and the rounding errors some elements introduce.
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2010-02-19 22:34:48 UTC
I don't think we have to wait for 0.11. We can always add a new source and deprecate the trigger variant in the interpolation cs.
Comment 2 Sebastian Dröge (slomo) 2010-02-22 19:59:05 UTC
Yes, could be added before 0.11 too... but should definitely be done in 0.11 ;)
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2011-12-15 17:45:56 UTC
do we want to keep these in 0.11?
    GList *gst_interpolation_control_source_get_all (GstInterpolationControlSource * self)
    gboolean gst_interpolation_control_source_set_from_list (GstInterpolationControlSource *self, const GSList * timedvalues)

- the application most probably maintains a collection of the control points for editing purposes anyway
- this collections is unlikely going to be a GSList of GstTimedValue
- in the optimistic case it contains GstTimedValues and the app needs to create a GSList and throw it away afterwards
- then we can also loop outself and call gst_interpolation_control_source_set()
- this would help us to hide GstTimedValue from the api in 0.11

I am working on a GstTriggerControlSource, but would basically need to copy:
gst_trigger_control_source_set
gst_trigger_control_source_set_from_list
gst_trigger_control_source_unset
gst_trigger_control_source_unset_all
gst_trigger_control_source_get_all
gst_trigger_control_source_get_count

Another option would be to have a GstTimedValueControlSource abstract base class as a root for GstTriggerControlSource and GstInterpolationControlSource. Not sure if modifying the class hierarchy is an ABI break though?
Comment 4 Sebastian Dröge (slomo) 2011-12-15 18:01:45 UTC
I'd get rid of _get_all() and _set_from_list() from the interpolation control source in 0.11 and I'm all for a TimedValueControlSource base class. This will break ABI (most probably unless you're really really careful) but we're talking about 0.11 here anyway.
Comment 5 Stefan Sauer (gstreamer, gtkdoc dev) 2011-12-15 21:56:35 UTC
My plan was to do the GstTriggerControlSource for 0.10 still to ease the transitions ... Not sure if it is worth the pain though.
Comment 6 Sebastian Dröge (slomo) 2011-12-16 08:02:59 UTC
I don't think it is, there might not even be a 0.10 release after 0.10.36.
Comment 7 Stefan Sauer (gstreamer, gtkdoc dev) 2011-12-19 22:32:11 UTC
commit 2c7a8b924a7be5c92ce9347f37283a09239296ae
Author: Stefan Sauer <ensonic@users.sf.net>
Date:   Mon Dec 19 11:13:45 2011 +0100

    controlsources: refactor interpolation control source
    
    Move most of the code to a GstTimedValueControlSource. Split out the trigger
    'interpolation mode' to a new control source class. Move tests and examples to
    new api. Update docs.