[gst-devel] virtfunc dispatching

[Wim Taymans]

On Sat, 2004-11-27 at 18:14 +0100, Ronald S. Bultje wrote:
> Hi,
> 
> can someone explain me how queries, events and everything are
> dispatched? I always assumed something simple and that's apparently not
> the case.

The event function of a pad does the following:

1) inspect the event
  a) it knows how to handle it
    I) it can handle the event itself.
      - it handles the event
         A seek for example updates the internal structures of the
         element so that it can perform the seek later on. (for example 
         a filesrc can do this).
      - unrefs the event.
      - it returns TRUE
    II) it cannot handle the event itself
      - creates a new event with aditional info
        A navigation event for example that passes through a scaler,
        will be updated so that it reflects the updated positions
        before scaling. 
      - unrefs the old event.
      - forwards the new event to the internally linked peers.
      - returns the result of the forward.
    III) it knows the event but cannot handle it currently.
      For example: a seek on a non seekable stream. 
      - it unrefs the event
      - returns FALSE 
  b) it does not know how to handle it
     - forwards the event to the internally linked peer(s)
     - returns the result of the forward.

The rationale being that a return value of FALSE means that the event
definatly failed or just did nothing. TRUE meaning that it was
successfully handled by some element. This currently does not mean that
more complicated events, like seeking, will be executed successfully,
but chances are big. 

If you do not forward the event to a peer, you should unref it since you
act as a sink for the event.

A lot of elements do not follow this algorithm closely though. 

Query/convert is similar. You either perform the conversion yourself or
forward the conversion to some other element. This mostly depends on the
characteristics of the element, for same-in-same-out elements,
forwarding is a good idea, if you mangle the input data in such a way
that the conversion does not make sense on the other end, you need to do
the conversion yourself (samples->time in an audio decoder for example,
is most likely not converted in a plugin that handles the compressed
data).

> 
> I'd assume that you send events, queries and everything to the sink of a
> pipeline () or to the pipeline bin. The pipeline bin will forward it
> appropriately to whatever element handles it and return a value for the
> whole stream. The sink will forward it and return a value for this
> elementary stream.
> However, from code, it appears it just sends stuff to the first element
> in the world that implements a handler and returns that. Bins do nothing
> at all. That doesn't sound right.

There is not automatic element/pad selection when you send an event to
an arbitrary bin. An possible algorithm for the gst_element_send_event()
method on gstbin would be to send the event to all sinks of that bin,
but that is currently not implemented.

A custom bin is able to implement the send_event/query/... virtual
functions if it wants, though. This is what playbin does and it forwards
the events to the sinks. 

> 
> Now what I'd like to do in practice, is do a gst_element_query (playbin,
> _POSITION, "chapter", &val);. Obviously, the query never arrives at my
> DVD source because mpegdemux already returned FALSE. Same seems to be
> true for events, too. How's this supposed to work?

This looks like a bug in mpegdemux, I suppose it does not know about the
chapters format, so it should just forward the event instead of deciding
that it cannot seek to this format.

Wim

> 
> Thanks,
> 
> Ronald
> 
-- 
Wim Taymans <wim at fluendo.com>