[gst-devel] non-blocking gst_pad_pull()
dez at ti.com
Mon Feb 28 16:59:12 CET 2005
Benjamin Otte wrote:
> I'm not sure I get what you want here exactly, but calling
> 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
> > mechanism into a GStreamer plugin, but this mechanism runs
> > asynchronously to GStreamer. Thus this mechanism might have zero
> > buffers ready for gst_pad_push() after processing a gst_pad_pull()
> > 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
> bad idea. you can do the other way around: have pull/push operate in
> element context and create a separate thread for your own
> 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
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
* 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! --
More information about the gstreamer-devel