[gst-devel] non-blocking gst_pad_pull()

[Benjamin Otte]

On Thu, 17 Feb 2005, Dezelon, Mark wrote:

> That said, is there harm in placing gst_pad_pull() in a separate thread
> and having that thread communicate with the plugin via a pipe?  I was
> thinking that if a plugin was called from a loopfunc() rather than a
> chainfunc(), then it could check the pipe for new data in a non-blocking
> way.  On the other hand, I'm curious of the potential for destroying
> GStreamer by doing this.
>
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
.
> 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.
>
It is not a problem at all. You can call gst_pad_pull and gst_pad_push in
any order you like. Plugins like mikmod pull in all data before they push
out the first buffer, plugins like mad push out multiple buffers after
receiving a buffer almost every time.

Benjamin