[gst-devel] non-blocking gst_pad_pull()

[Dezelon, Mark]

Benjamin Otte wrote:
> I'm not sure I get what you want here exactly, but calling
gst_pad_pull
> from a different thread than the element's is certainly a bad idea.

If it's any consolation, I've decided not to try a forked
gst_pad_pull().  Rather I'm using the mikmod-like approach (as you
mentioned) where one input buffer may lead to many output buffers.
Thanks for your advice.

Ronald S. Bultje wrote:
> > My problem is that I'm trying to incorporate an existing
buffer-passing
> > mechanism into a GStreamer plugin, but this mechanism runs
> > asynchronously to GStreamer.  Thus this mechanism might have zero
output
> > buffers ready for gst_pad_push() after processing a gst_pad_pull()
input
> > buffer, or it might have many output buffers ready before an input
> > buffer can arrive.
> 
> You'll want to explain a bit more about how this works. It sounds like
a
> bad idea. you can do the other way around: have pull/push operate in
the
> element context and create a separate thread for your own
API/whatever.
> That's (so I learned today. :) ) what BeOS does.

For a bit more explanation, we'll call the two frameworks GStreamer (of
course) and MyFramework (which bad idea or not, I'm integrating into
GStreamer :) ).  MyFramework lives in a separate thread (part of its
design) and sends messages to my GST plugin via a pipe.  Messages
include "Here's a buffer to fill with data" and "Here's a buffer full of
processed data".

Very rough overview of steps in chain():

  * GStreamer gives Plugin a data buffer.
  * Plugin loops while (GST data is unused) or (MyFramework pipe is not
empty).
      * Next MyFramework pipe message is read.
      * If it's a buffer to fill, fill it with the GST data buffer.
          * If data is already used up, save buffer for later.
      * If it's a buffer full of processed data, call gst_pad_push().
  * Exit chain().

When one GST buffer is available, zero or more gst_pad_push()'s are
called depending on the speed of MyFramework in the other thread.  The
pipe ensures that no buffers are lost, and an actual implementation of
this works quite nicely.

-- Mark Dezelon / Don't Panic! --