1.0 controller API

[Stefan Sauer]

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