[gst-devel] GValue event networks in GStreamer

[Steve Baker]

> Control types
> -------------
> There are a couple of different kinds of controls. Value controls, which
> have a specific value that can be queried at any time (a GUI spin button
> for example), and event controls which emit/receive events but don't
> have a specific "set" value (a MIDI sink or source for example).

If we're talking about control pads there is no real distinction between
value controls and event controls - both emit data when something happens.
complimentary
> Caps and value conversion
> -------------------------
> A pad's capabilities could be described by a GParamSpec. For this
> purpose a couple of callbacks could be added to a pad for getting or
> setting a GParamSpec to allow for a pad to provide its own storage (or
> is there a cleaner solution in GStreamer - Caps?). In Swami once a
> GParamSpec is set it must always remain of the same type (to make things
> easier, and alleviate some locking). If a pad does not have a GParamSpec
> assigned to it, then all events are passed as is. If a pad does have a
> GParamSpec then any event received is converted to the GParamSpec value
> type using g_value_transform.
>
> Capability Flags
> ----------------
> There are a couple of flags that could also be useful in the Caps of a
> GstValueEvent pad. A "no convert" flag to indicate that even though
> there is a set GParamSpec, incoming events should not be converted; a
> "native" flag to indicate that no conversion should be done but all
> incoming events should be of the GParamSpec value type; a "GParamSpec
> connect" flag that will cause a sink pad to use the GParamSpec of its
> linked source pad; and a "GParamSpec no convert" flag to indicate that
> when setting a pad's GParamSpec it should not be converted to the pad's
> current GParamSpec type.

I think you should stay away from putting GParamSpec in caps since
GstStructure can already represent anything that GParamSpec can plus
anything else that might be useful for GValue event caps.

See my previous dparams email about mapping between GstStructure and
GParamSpecs - maybe we could put a convenience function in core to convert
a GstStructure with the required data to a GParamSpec.

At first glance it looks like dparams and control pads are duplicated
effort trying to solve the same problems. I actually think they are
complimentry. To make them work together the following would be needed:
- an element which takes a dparam and sends out control data on a pad
- a way for a dparam enabled element to get its GValue from the sink pad
instead of the usual place (such as element property).

I think in many cases creating an element and building a network just to
send around some control values will be too heavy-weight for many
situations. In other cases it would be the right thing.

cheers