[gst-devel] non-blocking gst_pad_pull()

[Dezelon, Mark]

Hello, folks.  A question of blocking within a GStreamer plugin:

I know that gst_pad_pull() blocks until data is available.  In fact,
after Googling a bit, I read that input to a plugin simply doesn't exist
until gst_pad_pull() is called, meaning that even if I was able to query
gst_pad_pull() data status, it would be undefined.

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.

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.

Any thoughts?

-- Mark Dezelon / dez at ti.com / Don't Panic! --