1.0 controller API
Locked
 
|
Hi developers,
right now the gst-plugins-base/tests/check/elements/volume test is failing. It is not just the test, actally using the volume element wit gst-controller is broken. One thing that is special here is that volume is checking if the mute and/or volume property is controlled and if so, it is fetching blocks of control-values to apply them in a scalar operation. This way one can have a control resolution down to sample-rate (which is rarely needed). In 0.10 the value_arrays where wrapped as a GstValueArray which was nasty for bindings. The good thing for elements written in C was that you e.g. got an plain array of doubles which was ready to be used. In 0.11/1.0 we fill a array of GValues, which is nice for bindings, but bad for e.g. the volume element. One way I can fix this is to change the API to have two entry points - one for C and one for bindings: gst_control_binding_get_value_array(GstControlBinding * self, GstClockTime timestamp, GstClockTime interval, guint n_values, gpointer values); gst_control_binding_get_g_value_array(GstControlBinding * self, GstClockTime timestamp, GstClockTime interval, guint n_values, GValue * values); (I would rename the current function and introduce a new one under the old name). Implementationwise I can require controlbindings to support it and wrap it on the control-bindings baseclass, with performance penalty for the bindings (extra conversion). Another 'issue' I'd like to get some feedback from what behavior people would expect is the following. Again, an element/application requests an array of control values from a certain starting point. What if the controller has the first defined control-value (e.g. a time-based controlpoint) after the start of the requested region? Right now interpolation control-source returns NaN for time-ranges with no control curves defined (for single values it returns false). For arrays the method returns false if it would be completely empty. If it is partially filled, one gets NaNs on the control-source array and empty GValues on the bound value-array. One alternative on the control-binding level would be to use a) the current property value, b) the default property value. a) has the advantage that setting it would be kind of neutral, but the disadvantage that it could have changed inbetween. b) sounds like a worse choise to me. We could also assume that if the first defined control-value is at ts>0 that the same value applies to earlier timestamps. This would be symmetric with keeping that last value of later timestamps. That would only leave the error case where no single control-point is set and thats imho just an error. Stefan _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
On 04/19/2012 09:43 PM, Stefan Sauer wrote:
> Hi developers, ping? Stefan > right now the gst-plugins-base/tests/check/elements/volume test is > failing. It is not just the test, actally using the volume element wit > gst-controller is broken. One thing that is special here is that volume is > checking if the mute and/or volume property is controlled and if so, it > is fetching blocks of control-values to apply them in a scalar > operation. This way one can have a control resolution down to > sample-rate (which is rarely needed). > > In 0.10 the value_arrays where wrapped as a GstValueArray which was > nasty for bindings. The good thing for elements written in C was that > you e.g. got an plain array of doubles which was ready to be used. > > In 0.11/1.0 we fill a array of GValues, which is nice for bindings, but > bad for e.g. the volume element. > One way I can fix this is to change the API to have two entry points - > one for C and one for bindings: > > gst_control_binding_get_value_array(GstControlBinding * self, > GstClockTime timestamp, GstClockTime interval, guint n_values, > gpointer values); > gst_control_binding_get_g_value_array(GstControlBinding * self, > GstClockTime timestamp, GstClockTime interval, guint n_values, > GValue * values); > > (I would rename the current function and introduce a new one under the > old name). Implementationwise I can require controlbindings to support > it and wrap it on the control-bindings baseclass, with performance > penalty for the bindings (extra conversion). > > > Another 'issue' I'd like to get some feedback from what behavior people > would expect is the following. Again, an element/application requests an > array of control values from a certain starting point. What if the > controller has the first defined control-value (e.g. a time-based > controlpoint) after the start of the requested region? Right now > interpolation control-source returns NaN for time-ranges with no control > curves defined (for single values it returns false). For arrays the > method returns false if it would be completely empty. If it is partially > filled, one gets NaNs on the control-source array and empty GValues on > the bound value-array. One alternative on the control-binding level > would be to use a) the current property value, b) the default property > value. a) has the advantage that setting it would be kind of neutral, > but the disadvantage that it could have changed inbetween. b) sounds > like a worse choise to me. > We could also assume that if the first defined control-value is at ts>0 > that the same value applies to earlier timestamps. This would be > symmetric with keeping that last value of later timestamps. > That would only leave the error case where no single control-point is > set and thats imho just an error. > > Stefan > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
On 04/23/2012 09:46 PM, Stefan Sauer wrote:
> On 04/19/2012 09:43 PM, Stefan Sauer wrote: >> Hi developers, > ping? > > Stefan - make 2 apis - the controller returns the value of the first control point Wim >> right now the gst-plugins-base/tests/check/elements/volume test is >> failing. It is not just the test, actally using the volume element wit >> gst-controller is broken. One thing that is special here is that volume is >> checking if the mute and/or volume property is controlled and if so, it >> is fetching blocks of control-values to apply them in a scalar >> operation. This way one can have a control resolution down to >> sample-rate (which is rarely needed). >> >> In 0.10 the value_arrays where wrapped as a GstValueArray which was >> nasty for bindings. The good thing for elements written in C was that >> you e.g. got an plain array of doubles which was ready to be used. >> >> In 0.11/1.0 we fill a array of GValues, which is nice for bindings, but >> bad for e.g. the volume element. >> One way I can fix this is to change the API to have two entry points - >> one for C and one for bindings: >> >> gst_control_binding_get_value_array(GstControlBinding * self, >> GstClockTime timestamp, GstClockTime interval, guint n_values, >> gpointer values); >> gst_control_binding_get_g_value_array(GstControlBinding * self, >> GstClockTime timestamp, GstClockTime interval, guint n_values, >> GValue * values); >> >> (I would rename the current function and introduce a new one under the >> old name). Implementationwise I can require controlbindings to support >> it and wrap it on the control-bindings baseclass, with performance >> penalty for the bindings (extra conversion). >> >> >> Another 'issue' I'd like to get some feedback from what behavior people >> would expect is the following. Again, an element/application requests an >> array of control values from a certain starting point. What if the >> controller has the first defined control-value (e.g. a time-based >> controlpoint) after the start of the requested region? Right now >> interpolation control-source returns NaN for time-ranges with no control >> curves defined (for single values it returns false). For arrays the >> method returns false if it would be completely empty. If it is partially >> filled, one gets NaNs on the control-source array and empty GValues on >> the bound value-array. One alternative on the control-binding level >> would be to use a) the current property value, b) the default property >> value. a) has the advantage that setting it would be kind of neutral, >> but the disadvantage that it could have changed inbetween. b) sounds >> like a worse choise to me. >> We could also assume that if the first defined control-value is at ts>0 >> that the same value applies to earlier timestamps. This would be >> symmetric with keeping that last value of later timestamps. >> That would only leave the error case where no single control-point is >> set and thats imho just an error. >> >> Stefan >> >> _______________________________________________ >> gstreamer-devel mailing list >> [hidden email] >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
On Di, 2012-04-24 at 08:55 +0200, Wim Taymans wrote:
> On 04/23/2012 09:46 PM, Stefan Sauer wrote: > > On 04/19/2012 09:43 PM, Stefan Sauer wrote: > >> Hi developers, > > ping? > > > > Stefan > - make 2 apis And make helpers for conversion from the C array variant to the GValueArray variant that can be used by lazy subclasses for the conversion of some common types. > - the controller returns the value of the first control point Agreed, I thought this was the old behaviour already? _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
signature.asc (205 bytes)
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |