Non-blocking pull of buffers in appsink

[Erik Slagter]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3729 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20110730/c0757f10/attachment.bin>