After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 772455 - vaapisink: possible race in wayland_sync
vaapisink: possible race in wayland_sync
Status: RESOLVED DUPLICATE of bug 795224
Product: GStreamer
Classification: Platform
Component: gstreamer-vaapi
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
P2
Depends on:
Blocks: 748634
 
 
Reported: 2016-10-05 14:32 UTC by Jens Georg
Modified: 2018-04-18 12:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
sink: wayland: bail out if no pending frames (1.13 KB, patch)
2016-10-08 15:22 UTC, Víctor Manuel Jáquez Leal
none Details | Review

Description Jens Georg 2016-10-05 14:32:08 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.
Comment 1 Víctor Manuel Jáquez Leal 2016-10-08 15:22:18 UTC
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.
Comment 2 Víctor Manuel Jáquez Leal 2016-10-08 15:23:16 UTC
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?
Comment 3 Jens Georg 2016-10-09 08:55:17 UTC
I have to check next week, I think we broke out before the wl_display_flush
Comment 4 Jens Georg 2016-10-18 19:32:59 UTC
Sorry, got distracted. Works!
Comment 5 Víctor Manuel Jáquez Leal 2016-10-19 13:29:01 UTC
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.
Comment 6 Jens Georg 2016-10-19 15:19:36 UTC
In our case, the second thread is handling user input - that's probably not something you'd want to block.
Comment 7 Víctor Manuel Jáquez Leal 2018-04-18 11:53:39 UTC

*** This bug has been marked as a duplicate of bug 795224 ***