GNOME Bugzilla – Bug 772455
vaapisink: possible race in wayland_sync
Last modified: 2018-04-18 12:56:54 UTC
If you have a second thread that registers a second queue on the wayland display and that will call wl_display_flush, it can happen that the frame callbacks are already triggered by the while loop in https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi/tree/gst-libs/gst/vaapi/gstvaapiwindow_wayland.c#n174. So it can happen that after https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi/tree/gst-libs/gst/vaapi/gstvaapiwindow_wayland.c#n178 the priv->num_frames_pending is already 0 and we will be stuck in gst_poll_wait forever.
Created attachment 337232 [details] [review] sink: wayland: bail out if no pending frames Don't poll the display fd if there are not pending frames. This could happen if there's another thread flushing.
Hi Jens, I'm not sure if I'm grasping correctly your issue. Can you test the proposed patch and let me know if that works for you?
I have to check next week, I think we broke out before the wl_display_flush
Sorry, got distracted. Works!
The problem with this patch is that it doesn't assure the blocking at gst_poll_wai() won't happen. A more realistic approach would be to flush the poll when the pending frames are zero. But that would mean to nest polls flushes, since we are already flushing the poll if the user closes the display. We would distinct which flush are we stopping. Another approach would be the application to block the thread where wl_display_flush() is called while the sink is rendering a frame, by using the "handoff" signal of vaapisink.
In our case, the second thread is handling user input - that's probably not something you'd want to block.
*** This bug has been marked as a duplicate of bug 795224 ***