Non-blocking pull of buffers in appsink
erik at slagter.name
Sat Jul 30 03:19:00 PDT 2011
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...
Size: 3729 bytes
Desc: S/MIME Cryptographic Signature
More information about the gstreamer-devel