[gst-devel] GValue event networks in GStreamer

[Josh Green]

On Thu, 2004-07-22 at 15:49, Steve Baker wrote:
> > 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

Actually I was referring to the architecture in Swami that I'm basing
some of this on. But it sounds like its the same in GStreamer, so thats
good.

> 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.
> 

Cool, I just had a look at GstStructure (I'm learning as I go :) Looks
pretty nice. I'll get myself up to speed with how caps work for defining
capabilities of a pad and how this would work for GValue events.

> 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.
> 

I had a look at libs/gst/control/dparam.[ch] but I'm still somewhat
clueless as to what these are for. "Dynamic parameter functionality"
helps a little bit. Any pointers where I can find out more about
dparams?

> At first glance it looks like dparams and control pads are duplicated
> effort trying to solve the same problems.

When you say "control pads" are you referring to the GValue event
network stuff that is the topic of this thread or are you referring to
some other existing sub system in GStreamer?

> 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).
> 

Perhaps I'll understand this more once I have a better idea of what a
dparam is used for.

> 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.
> 

Heavy weight as in data allocation overhead? Essentially I'm just trying
to help create a way for routing arbitrary GValue data (values and
events) which could then encapsulate boxed structures such as a MIDI
event union, etc. I would love to leverage off of any existing GStreamer
subsystems that make sense for this task.

I have yet to hear any objections for a new GValue GstData type, so
perhaps its a good idea? :)

> cheers
> 
> 

Cheers
	Josh Green