[gst-devel] Stuff that needs doing...

Thomas Nyberg thomas at codefactory.se
Tue Mar 6 01:19:14 CET 2001


On Mon, 5 Mar 2001, Erik Walthinsen wrote:

> 4) Event system
> The solution is some kind of event system that encompasses EOS, empty,
> flush, seeking, new-file notification, and everything else.  This system
> would have to be carefully constructed to follow the dataflow left to
> right, and have the "right" behavoir when going right to left (seek).
> Some have suggested attaching these events to the buffers, but that
> introduces the overhead of checking each and every buffer at every point
> in the pipeline, which we've intentionally avoided so far.
>
> In general, a plugin would have a standard handler that would simply pass
> events through.  Various plugins would either override that handler or use
> some other mechanism to register for interesting events, and handle them
> that way.
>

When reading this, one simple approach comes to my mind. It is easy to
store function-pointers representing these events in the appropriate
class-structure. For the discussion, let us imagine using the GstObject as
basis for this.
struct _GstObjectClass {
	...
	gint (*eos)(...);
	gint (*new_file)(...);
	and so on...
	...
};

It is easy for any plugin, filter, whatever to set these handlers in their
class-init functions. Since every object always stores a pointer to the
parent-object's class, there are no problems calling the parents handlers
either. It is a simple approach, but it works.

Then you can always discuss more on what parameters should be passed with
each function/event. But I do not see a need for some high-tech sollution
here. It would be possible to send different paramaters with each event
in "plain text" so to say.

-- 
Thomas Nyberg                    thomas.nyberg at codefactory.se
CodeFactory AB                   http://www.codefactory.se/
Office: +46 (0)90 71 86 10       Cell: +46 (0)70 335 61 64






More information about the gstreamer-devel mailing list