[gst-devel] proposal for implementing dynamic parameters

[Owen Fraser-Green]

Hi,

I have a couple of doubts concerning GstDynamicParams. I had envisaged
this functionality being implemented as though it were an analogue
data flow using the existing pads mechanism. Also, I disagree with the
most of the disadvantages of that approach stated in the wiki page:

> the chain/loop functions become more complicated because most
> plugins will now have at least 2 sink pads instead of one (one for
> data and one for control)

Yes, that's true. But maybe a solution would be to give the option of
allowing the control data pads to have no input arc but instead to be
set to a constant whereupon the chain functions don't need to
coninuously sample the input. This will cater for the most common
case.

> the scheduler will have to make sure that a plugin has always been
> fed enough control buffers so that the plugin knows how to
> manipulate the >data buffers. This added complexity might be hard to
> maintain.

But surely if we treat the data flow as an audio stream with a very
low sample rate then there is hardly anything to add to the
scheduler. I would have thought that it would take far more work for
the scheduler to deal with paremeterized control data.

Granted the interpolation is a really nice feature but surely it would
be better implemented as a set of filter plugins which take a set of
parameters and create an analogue data control signal.

> when using user interfaces to create graphs, the graph can get
> unmaintainable very quickly if control data and media data are
> represented in the same graph. Most situations wouldn't require such
> a level of sophistication to represent the flow of dparam data.

Surely things will get far more complicated if there isn't a graphical
means to represent how control data will be attached to elements. Will
the control data form the properties of the element it acts upon? If
so what about the situation where one dataset is to be applied accross
more than one plugin?

> a dparams stream will generally be very low bandwidth and data is
>generated in sporadic bursts. The GStreamer infrastructure is really
>optimized for streams that produce a mostly-constant stream of data.

In batch situations this is true but not in real-time usage where
although changes in the control input are sporadic, the application
can have no way of telling when changes are going to occur so the data
has to be sampled continuously.


I'm also don't see the need for giving the control data
dimensions. Suppose I have a low-frequency oscillator, why should I
have to say it's specifically for controlling frequency, time,
magnitude, colour? Even if I could say it was all of these things,
what about when new dimensions are introduced. I'm concerned that this
will blow up into another caps negotiation scenario.

I see the need for applying parametized envelopes but I believe that
is at most 1/4 of the control data picture. Generating control data
from oscillators, external real time data and the ability to filter
control are also essential for many of gstreamer's potential
applications and I don't feel those issues have been addressed yet. I
think a better solution is to just treat control data like a
low-bandwidth audio stream and then build the envelope, oscillator and
filter elements which operate on those streams.

Regards,
Owen

---------------------------------------------------------------------------
     Owen  Fraser-Green             "Hard work never killed anyone,
     owen at discobabe.net              but why give it a chance?"
---------------------------------------------------------------------------