[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