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.


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[ak.ashwini]

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 <[hidden email]> 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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Erik Slagter]

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

We have a special case here were we extract subtitles out of the
pipeline into an appsink and then overlay the subs using OSD instead of
video overlay. It appears that gstreamer tends to send subs way ahead of
the current playing video to the appsink, so they need to be queued (you
cannot inspect the subs before it is pulled). Especially during seeks it
appears that gst's internal queue can get out of sync with our own
"queued subs" counter which is incremented on new-buffer signal and so
the pull gets blocked, stopping the application.

I have made a workaround now, using a seperate thread for pulling, which
works really wel, but shouldn't be necessary.


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel