[gst-devel] Re: dparams roadmap (AKA dparams are dead, long live control pads)

[Edward Hervey]

Whooops, was too quick in sending the mail, I sent it to steve only :)
So here is the mail for everybody.


Hi all,

  So after this weekend's talks and more talks earlier this week with
thomas and wim, we came up with a new solution that should fit most
use-cases and be more lightweight and easier to use than the current
solution.

  Here follows a proposition and a sample header file. All comments welcome.

  The idea is to have a GObject (that we'll call GstEnvelope here)
that allows applications and plugins to easily handle "dynamic
parameters", or to put it another way "timed values" for any element
properties.

  This allows with minor modifications to plugins (one function call)
to allow any plugin to have any of their properties modified through
time.

** Application point of view

  The application decides what properties of what element it wishes to
control (either ahead of time or in real-time).
  => gst_element_envelope_properties(element, property names...)

  It can also decide how it wants the interpolation of each properties
of that envelope (default being no interpolation).
  => gst_envelope_set_interpolation_mode(envelope, property, interpolationmode)

  The application can then give ahead of processing some timed values,
to create a volume envelope for exemple, or give them at any given
time.
  => gst_envelope_set(envelope, property, time, value)
  => gst_envelope_set_many(envelope, property, list of timed values)

  One of the advantage of this solution is that the envelope will
record all the modifications made to the given properties through
time, so that if you play again the handled element it will
automatically use those values (i.e. for ardour-like applications).

  The other advantage is that it avoids the double-recording of values
and modifications (in the application and in the element), and allows
the application a range of values through time that are EXACTLY the
same as the ones being used by the element. This is useful, for
example, in non-linear editors to graphically represent the property
changes through time.
  => gst_envelope_get_value_array[s] ()

** plugins point of view

  The minimal requirement for plugins is to use a function, just
before processing data, that sets the properties handled by the
envelope to their correct values, given a timestamp.
  => gst_element_sink_values(element, timestamp)
  => gst_envelope_sink_values(envelope, object, timestamp)

  If the plugin also needs to have property values at a sample level
(and not buffer) for some properties, it calls a function that will
fill up an array of values depending on a timestamp, a number of
samples, and a sample duration.
  => gst_element_get_value_array[s] ()

  All the functions are of course threadsafe since the object can be
handled by the application and by the element.

  The header file is attached, If there's anything not clear, please
do comment on the mailing-list.

    Edward
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gst_envelope.h
Type: text/x-chdr
Size: 5915 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20050223/8741a1f4/attachment.h>