[gst-devel] Why downstream events should be out of order

[Benjamin Otte]

Currently, downstream events (as opposed to upstream events) are procesed in
order with buffers. I will now show you why this doesn't work. (that
sounds like my professor, but I keep it ;)

filesrc ! mad ! osssink

I do a seek to 1:00.
It works this way:
osssink creates a seek event to 1:00. mad translates it to the right file
position and passes a seek event to te filesrc.
The filesrc sets the new offset and creates a DISCONTINUOUS event, which
will be sent downstream to indicate that a seek happened. Next time mad gets
the buffer it will clear its data buffer and pass the event on, ready to
receive the data from the new position.
But: Who knows the time mad will ask for a new buffer? Maybe I specified
filesrc buffersize=filesize ! mad ! osssink With that, mad gets one buffer
at the beginning and never ask for a buffer again. There is now _no_
possibility to get an event downstream from filesrc until mad has decoded
the whole song.

That is the problem.
IMO events - unlike buffers - represent things that
need to happen asap. (see for example the seeking stuff above). Therefore it
is not good if we rely on plugins to pull the event (by explicitly calling
"_pad_pull" or exiting their chain function, but to push it directly to them
and make them handle it.
Just like we do with upstream events today.

We would need to redesign the event stuff we currently have, but I think it
is necessary.

Benjamin

PS: If you want to know why the EOS event works so well currently:
EOS is not an event technically. EOS is more of an empty buffer that
follows the stream. It's the "end of the stream", like the name says.
An event would be "EOS happening".