[gst-devel] event system

[David I. Lehn]

* Thomas Vander Stichele <thomas at urgent.rug.ac.be> [20010614 17:14]:
> > I feel speed and qos are the same. changing the speed would require to 
> > change the global clockspeed of the pipeline.
> 
> Hmmm... I'd rather combine speed and seek; with speed I didn't mean "send
> buffers faster", but I meant "send the same amount of data but
> time-compress it".  So it would work as a speed-based seek.  Also, if you
> would set speed to -1, you'd just reverse the data.
> 


> > > 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... 
> 
> hmmm... what I mean in this regard is that it would be better to agree on
> events than, for example, in the case of plugins, have a plugin with has a
> "silent" argument and another which has a "mute" argument.
> 

Quick! Register igna.org... the Intergalactic GStreamer Naming
Authority!  ;)

I think a few core events are in order but custom events should be
possible using the same machinery.  Signals vs events... they are good
for different things.  It may be more appropriate for a cdsrc (for
example) to send a "new track" event in addition to a similar signal to
keep it in order with buffers... or something like that.

Ok, maybe a better example. ;)   How user interface actions for a dvd
player?  This can arguably be all at the application level, but perhaps
it should be part of GStreamer core.  Have a custom videosink that sends
back user button press info via an event.  Somewhere back in the
pipeline it will hit the dvd vm code that knows how to handle it and
convert to a seek event for the raw src.

-dave
-- 
David I. Lehn <dlehn at vt.edu>  | http://www.lehn.org/~dlehn/
Computer Engineering Graduate @ Virginia Tech in sunny Blacksburg, VA