[gst-devel] GValue event networks in GStreamer

[Josh Green]

I'm starting to work on a GValue based GstData type, but would like to
get some more input from other GStreamer developers before I start
spending a lot of time on it. I'm working on this to help facilitate the
addition of MIDI and generic value control routing in GStreamer. I've
attached an initial header file for a new GstData type that is currently
named GstValueEvent. Here is the structure definition:

struct _GstValueEvent {
  GstData                data_type;
  GValue                *value; /* the GValue of this value event */
                                                                                
  /* the origin event (NULL if is origin or origin of event chain) */
  GstValueEvent         *origin;
 
  GstClockTime           timestamp;   /* timestamp */
 
  /* active event propagation count */
  guint                  active_count;
 
  gpointer _gst_reserved[GST_PADDING];
};

The data payload is the GValue, so any GValue supported data type can be
sent in this event.
The origin and active_count fields are used for preventing event loops.
The origin field is set if an event is created related to the reception
of another event (so its basically the head of a chain of events). The
active_count field is a "reference" like counter that counts active
emissions for an event. This will be used by the loop prevention logic
to determine when an event is no longer active, and so can be removed
from a pad's active list.

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. I'll describe what is currently implemented in
Swami, to try and get an idea of how this should be ported into
GStreamer.

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

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 (are there existing
callbacks that could be used for this?) Prototypes for these callbacks
would look like:

/* for pulling a value from a pad */
typedef void (*GstPadGetValueEventFunc)(GstPad *pad, GValue *value);

/* for pushing a value to a pad, @value is possibly converted,
   @event is the original received event */
typedef void (*GstPadSetValueEventFunc)(GstPad *pad,
					GstValueEvent *event,
					const GValue *value);

Event loop prevention
---------------------
In order to prevent event loops, a GstPad needs to have a list of
current active events to check if incoming events have already been
processed (a loop - therefore ignored). In Swami this check is done
whenever an event is pushed from a pad. For this reason it might make
sense to add some additional functions for sending/getting
GstValueEvents.

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.


Thus concludes my current thoughts on integrating GValue event streaming
in GStreamer. I would really appreciate some feedback/assistance on
this. If its something that sounds like it would be good to add in
GStreamer, then great. If it seems like something thats not meant for
GStreamer, I would like to know this before I spend too much time on it.
This task could probably use some individuals with GStreamer expertise
since its fairly new to me. Cheers!
	Josh Green

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gstvalueevent.h
Type: text/x-chdr
Size: 3949 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20040722/daa910e9/attachment.h>