Non-blocking pull of buffers in appsink

Ashwini Sharma ak.ashwini at
Mon Aug 1 00:01:05 PDT 2011

I dont think there should be case that you get new-buffer signal, but have
no buffer to pull actually.

On Sat, Jul 30, 2011 at 3:49 PM, Erik Slagter <erik at> wrote:

> Hi,
> I am trying to get the processing of subs working (always, not
> "most-of-the-time" like it is now) in a stb-player called enigma2.
> It uses an appsink to pull text subs from a media sink (not DVB, other
> media) and display the subs using OSD instead of video overlay (which can't
> work as video decoding takes place in hardware).
> At the moment the approach is used as suggested in the documentation. A
> signal handler for "new-buffer" is connected and subs are collected upon
> receipt of the signal.
> I appears, though, that sometimes, especially during seeking, the number of
> times the callback is called, does not correspond to the number of buffers
> actually available. As subs don't come around that often, more subs get
> pulled than available, making gst_app_sink_pull_buffer block, which makes
> the corresponding thread block. The design of the code is that this thread
> never can block, so the complete ui stops responding.
> I've been thinking of various approaches to resolve this, I'd like to have
> your input on this.
> - Is it possible to make the number of buffers available to the
> application, so it can decide wether to pull or skip? The api doesn't seem
> to make this information available though.
> - Is it possible to call gst_app_sink_pull_buffer without blocking. Again
> the api doesn't seem to support this.
> - Is there another trick maybe to woraround this issue? The only thing I
> can come up with is to add another thread that does nothing other than
> pulling subs, a bit of a waste and unnecessary complexity imho.
> Thank you for your help.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the gstreamer-devel mailing list