Pipeline blocking main thread

[Brown, James 2]

Hello I am currently using the gstreamer api to display video for my application but it is causing blocking of 100-200ms on the main thread of my application after setting gst_element_set_state(pipeline, GST_STATE_PLAYING). Once the video has actually started playing there are no more hiccups.

 

My pipeline is of type xvoverlay  and uses v4l2src, queue2, and xvimagesink. Currently I am calling gst_element_factory_make, gst_bin_add, gst_element_link, and gst_element_set_state from an application background thread to remove most of the latency as these operations can take up to 2 seconds to complete (is this actually thread safe?), but I cannot remove the remaining 100-200ms of blocking after making all the gstreamer calls in the background.

 

It is essential that the main thread is not blocked as it is a pseudo real time application. What is causing the blocking? Is there some asynchronous setting I am missing?

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

[Nicolas Dufresne-5]

Le jeudi 13 juillet 2017 à 00:07 +0000, Brown, James 2 a écrit :

> Hello I am currently using the gstreamer api to display video for my
> application but it is causing blocking of 100-200ms on the main
> thread of my application after setting
> gst_element_set_state(pipeline, GST_STATE_PLAYING). Once the video
> has actually started playing there are no more hiccups.
>  
> My pipeline is of type xvoverlay  and uses v4l2src, queue2, and
> xvimagesink. Currently I am calling gst_element_factory_make,
> gst_bin_add, gst_element_link, and gst_element_set_state from an
> application background thread to remove most of the latency as these
> operations can take up to 2 seconds to complete (is this actually
> thread safe?), but I cannot remove the remaining 100-200ms of
> blocking after making all the gstreamer calls in the background.
>  
> It is essential that the main thread is not blocked as it is a pseudo
> real time application. What is causing the blocking? Is there some
> asynchronous setting I am missing?

We try has hard has possible to not block the main thread, this
indicate a bug. If you could measure calls in GStreamer and find which
calls blocks for that long it would be nice.

The only call that normally blocks at the moment is gst_init(),
depending on the number of plugins you have, if your registry is
already cached or not, and the speed of your HD.

If you can collect this information, please file a bug at
bugs.gnome.org. Indicate which GStreamer version this is (maybe it's
something already fixed, who knows).

regards,
Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel