[gst-devel] event system

[Wim Taymans]

On 14 Jun 2001 15:09:17 +0200, Thomas Vander Stichele wrote:
> I've been thinking about a possible event system based on some of the
> things omega and wtay told me yesterday, and I would like to spark some
> discussion as I have some ideas on how to do it, though I'm not sure if
> they're all good of course.
> 
> So here's a rundown of the general issues and my ideas on them.
> 
> 1) first of all, events can travel two ways : from left to right, ie
> following the data stream, or right to left, ie downstream.
> Here's the some events that could/should be possible :
>       - eos : end of stream, travels downstream
>       - qos : quality of service, upstream, downstream plugin can ask to
>               send data faster or slower
>       - flush : sent downstream; eg. a src plugin could ask an mp3
>               encoder to flush out a full frame and clear it's
>               sample memlory and maybe even change encoding parameters
>       - clear : could be bidirectional; for example a plugin could ask
>                 to clear all the queues of data
>       - seek : sent upstream; plugin asks upstream plugin to go to a
>                specific place
>         - speed : upstream; downstream plugin asks upstream plugins to
>                send data at a different speed, allowing fast-forward or
>                reverse

what's the  difference between flush and clear? none IMHO, I would think
that a flush event would suffice.

I feel speed and qos are the same. changing the speed would require to
change the global clockspeed of the pipeline.

seek should be bidirectional: consider the case where an AVI muxer has
encoded a stream and has to rewrite the header (to fill in the number of
frames etc). It would send a seek event downstream, followed by the
buffer.

I'm not sure we need a buffer_size event... it would be sent downstream
(maybe upstream) and intercepted by the queues to adjust their buffer
size... I believe mpeg1 system streams have knowledge of suggested
buffer sizes.


> 
> 2) Most events will need to send a little, but not much, extra data.  I
> think all of them could use only one variable, and work in the same way as
> the current gtk arguments.  If not, they could work with a simple struct.

I was thinking about a union with a field for the event type and then a
set of extra values.

> 
> 3) These events shouldn't be user-definable IMO; if there is need for new
> types of events, they should be tied to the gstreamer core as to ensure a
> well-defined set of events.

not sure about that... 

> 
> 4) IMO, for downstream events, a plugin should either only send an event
> *or* a data buffer, but not both at the same time, as to make it easier on
> plugin writers.  I'm not sure this really should be a requirement, but it
> seems like a good rule of thumb unless there are counterexamples.  In any
> case, I would let a plugin send only one event at a time.

events and buffers have nothing in common. It must be perfectly possible
to send a seek event followed by a buffer push.

> 
> 5) As to how events should be passed on :
> * for downstream events : I would tie a new variable to the src pad, which
> would be a struct with an enum for the type of data that's passed through
> in it's iteration.
> The enum would be { DATA, EVENT_NODATA, EVENT_EOS, EVENT_FLUSH, ... }
> The enum would be checked by the next plugin; if it's DATA, then it works
> as it is now, but the buffer pointer would be in the event struct.
> if it's another, and it also has a parameter, that parameter would be in
> the struct as well, probably in the same way as gtk arguments are handled
> now.  
> 
I don't agree with events sending out data. Sending data is a separate
functionality that involves a scheduler and such. People could abuse the
event system to pass data, which is not good IMO.

> 
> 6) plugins should proxy all of these events by default automatically.
> Only plugins that specifically know the event has a meaning for them
> should install event handlers.

proxying the events would be a core feature similar to how the eos/qos
events are proxied now.

<snip>

A little example of a possible API to send events:

  GstEvent *ev = gst_event_new (GST_EVENT_SEEK);
  GST_EVENT_SEEK_TYPE (ev) = GST_EVENT_SEEK_OFFSET; 
  GST_EVENT_SEEK_POSITION (ev) = 1000; 

  gint res = gst_pad_send_event (sinkpad, ev);
  gst_event_unref (ev);
  if (res) {
   // event succeeded
   buf = gst_pad_pull (sinkpad);
   // we now have a buffer with the requested offset...
  }
  
A possible event_handler in disksrc:

gint
gst_disksrc_handle_event (GstPad *pad, GstEvent *ev)
{
  if (GST_EVENT_TYPE (ev) == GST_EVENT_SEEK) {
    disksrc->offset = GST_EVENT_POSITION (ev);
    return true; // we handled the event
  }
  return false; // we did not handle the event.
}

Another problems we need to think about is how events will cross threads.

 
> thomas

Wim
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>