[gst-devel] non-blocking gst_pad_pull()
dez at ti.com
Thu Feb 17 18:05:19 CET 2005
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.
-- Mark Dezelon / dez at ti.com / Don't Panic! --
More information about the gstreamer-devel