[gst-devel] dparams roadmap (AKA dparams are dead, long live control pads)
ensonic at hora-obscura.de
Tue Feb 22 02:15:13 CET 2005
> Now that 0.9 is opening I should give my thoughts on where I think dparams
> should go.
I would loved to read your thoughts any earlier ...
> DParams were created to overcome a limitation in GStreamer at
> the time (ie having lots of sink pads on an element). Also it seemed like
> a good idea at the time...
> My understanding is that 0.9 should fix the scheduling issues that make
> lots of sink pads hard so here is what I think we should do in 0.9:
> 1. remove all trace of dparams libraries and usage in 0.9. Make existing
> dparams based elements use only gobject properties (for now)
That just requires removing the dparams code, then they use gobject properties
> 2. stop referring to dparams and start talking about control pads. These
> are element pads just like any other whose buffer values contain
> timestamped parameter control information
I belive we need a test case before, that asserts, that it is no problem of
feeding about 10 to 50 control pads into an audio generator.
Another confusing aspect of using control pads is imho, that source elements
like sinesrc are not sources than anymore, because they have input.
So e.g. in the registry would they still be registered as a source.
An application needs some wahy to distinguish as source (from the audio view
point) from a source that produces control data.
If we use controlpads, what will we use for the mime type?
> 3. change some existing elements to expose their parameters as control pads
Some elements should be sinesrc and volume.
> 4. based on the experience of 3. write a little helper library which makes
> adding control pads as easy as possible, doing things like:
> - making it easy to expose a parameter as a gobject property and/or a
> contrl pad
> - using the control value with the desired timestamp when processing a
> stream buffer
> - optimised convenience routines to interpolate values over the duration
> of an audio buffer
That would be the new libcontrol
> 5. write a bunch of elements which produce control data. In order of
> complexity these could include things like:
> - an element with a gobject property which passes that value to its src pad
and hold the value as long as there is no new value
- an element with a gobject property which passes that value to its src pad
once and resets the value to a default value (needed for triggers)
> - an element with a bunch of gobject properties which define some kind
> of control curve (LFO)
> - an element which is passed a GstStructure as a gobject property which
> contains timelined data points. Src pad produces interpolated control
Again we need version that interpolate, versions that do not and version
that handle trigger data.
> - elements which listen to some kind of external data source (midi, gui,
> network control protocol) and produce non-blocking control data
So here we need a concept that generally handle interpolation and trigger data.
Overlaying data should work. I just describe the scenario here, becuase it took
we a little thinking wheter this would work or not:
Imagine you have your sequencer running in a loop. It feeds recorded control
values into the elements. Additionally there is a control GUI open, when the
user can move sliders etc.
In this case both sources will need to modify the same control-object.
> 6. These control data elements could have an agreed behaviour of never
> blocking. If the source of the control data blocks, the element just
> returns the previous value (or a placeholder event). I don't know if this
> is required in 0.9
Maybe the can have a behaviour property that decides wheter the return:
- the default value : trigger
- the last value : continuos control data
> Doing 1. and a minimal amount of 3. and 5. will get us to where we are now
> with the current dparams implementation, so I think doing this much would
> be feasible for 0.9
> I can't say that I will have time to do any of this. However it would be
> good to get some consensus so that if someone wants to do it then we all
> know exactly what needs to be done.
We already agreed that Eduard and me will take this over, as we just need it.
Anyway we would welcome, if you could help fleshing out the concept.
> Let the lively discourse begin.
Here you are ;)
More information about the gstreamer-devel