[gst-devel] GValue event networks in GStreamer

[Andy Wingo]

Hey Josh,

As I read your mail, I'm realizing that you won't get any really good
comments until people start to make apps based on such a framework. For
that reason, it's not appropriate for GStreamer core IMO (but I'm not
the one to talk to). At some point, I think you should set up a
repository somewhere (use arch :-) so that people can include the code
into their source trees, pound on it a bit, then maybe if it stabilizes
put it in core.

That is, unless Benjamin thinks it's useful for any nefarious plan he
might have. Until then, no plugin using this framework would be in
gst-plugins. It would be just for connections internal to an app. (It
would be interesting to see if it is feasible to have a library common
to DSP apps, though.)

On Thu, 2004-07-22 at 11:08 -0600, Josh Green wrote:
> struct _GstValueEvent {
>   GValue                *value; /* the GValue of this value event */

Just wondering: Why not have the GValue inline in the event, instead of
as a pointer? The benefit is it would be only one allocation. But
perhaps many events could share one GValue, so that wouldn't make sense.
Dunno, thoughts?

>   /* the origin event (NULL if is origin or origin of event chain) */
>   GstValueEvent         *origin;
>  
>   /* active event propagation count */
>   guint                  active_count;

I read your explanation, but I still don't understand this. Can you give
some use cases?

> The next stage is integrating this new GstData type with GstPad and
> GstCaps. This is where I'm still a bit ignorant in regards to the
> workings of GStreamer.

You need to say that it's a GstValueEvent, the type of the GValue, and
some type-specific constraints. The first will certainly be encoded in
the MIME type. Then the other things go as structure properties.

application/x-gvalue, type=gint, max=4, min=2, default=3

`type' could be a number as well; implementation would have to flesh out
which is best. (In this case, you'd have to call g_type_from_name to get
the type.)

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

I think the GUI needs to be separated from the processing. Thus it
doesn't make sense to have an element that has a GUI. Perhaps a better
solution would be that, instead of querying a graphical element, that
the graphical element _pushes_ a value to the processing network.

That is, have a "plug" element that has an object property plug::value,
and the GUI updates the property. The plug element is the one that
generates the GstValueEvent.

Consider also the idea of having a default value. For example, the phase
offset input of an oscillator may be left unconnected, in which case the
offset would be 0. Or it might be set to a constant value (which
shouldn't require an extra element: this implies that pads have values).
Or it might be varied at control rate (via GstValueEvents). Or maybe it
can be varied at audio rate (in the modular synth style, whereby another
oscillator can be hooked to the phase-offset control).

This is what I would want, anyway.

> Event I/O
> ---------
> A GstPad needs to be able to send and receive these events. I assume
> gst_pad_push and gst_pad_pull could be used with this new GstData type.
> Therefore there also needs to be a couple callbacks in a GstPad to
> retrieve a value from a pad or send a value to a pad

Why? Have you actually coded this? I think the standard get / chain /
loop functions are powerful enough. (Of course, you access them via
gst_pad_pull/push.) The only thing they don't do is allow for a pad to
have a value; that has to be implemented in a subclass of GstRealPad.

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

Use case?

That's all my thoughts for now :) My attention span is spotty, so I
can't promise to be on the ball with comments. Good luck, though!

Cheers,
-- 
Andy Wingo <wingo at pobox.com>
http://ambient.2y.net/wingo/