[gst-devel] State of DParams

[Steve Baker]

David said:
> When a property is 'taken over' by a DParam, it makes sense to just
> ignore any changes attempted by set_property().
>
> My two cents:  In the ideal case, I'd like to see dparams seamlessly
> add a request pad to the element, and when the pad is connected, pull
> control information from the pad, else use the property information.
> I'm indifferent to having a third state which uses automatic
> generators/interpolaters (like the existing DParams), although this
> might be a good compromise if the core isn't up to handling *lots*
> of control information being passed around.

I think that using elements/pads/scheduler to produce control values is
way too heavyweight for what is essentially a unit function which returns
a single value for a given timestamp.

I want to make it easy for DParams to be fed by properties *or* pads. But
I think the main feature of DParams is to be able to define a control
curve for an entire timeline before the pipeline is even started. Then an
app can choose whether to define that curve or take the values from some
real-time/external input.

Having said that, GStreamer core isn't too good at the moment at handling
lots of sink pads receiving data at different rates. If the core redesign
addresses this issue then a pad-based approach to DParams would be more
practical.

cheers