[Bug 780442] gtreamer-vaapi render multi video in single pipeline causing videos not killed with vaapisink in wayland

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=780442

Hyunjun Ko <zzoon at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #349344|reviewed                    |none
             status|                            |
 Attachment #349344|0                           |1
        is obsolete|                            |

--- Comment #12 from Hyunjun Ko <zzoon at igalia.com> ---
Created attachment 349933
  --> https://bugzilla.gnome.org/attachment.cgi?id=349933&action=edit
libs: window: wayland: refactor event-handling

Seperates handling-event loop to new thread, which includes:
 - Using mutex to protect each frame information.
 - Dropping frame if there's pending frame.
 - Fixing counting pending frames.

Problem description as the following:
1\ Racy condition in case that same wl_display/fd is being used in different
threads.
In this case, if a thread swallows other's events, another thread could be
stuck on poll forever. The problem usually happens during destruction of
GstVaapiWindow in case that multiple piplelines running on a process.
At this time, it calls gst_vaapi_window_wayland_sync sequentially when
destruction
from one vaapisink to another vaapisink, which leads that the first
gst_vaapi_window_wayland_sync is likely to swallow other's events.
If it happens, another vaapisink got stuck and can't be finished.

2\ Wrong counting pending frames and leads to leakage.
This is another main problem on GstVaapiWindowWayland, which is described on
#774029.
It needs to send null buffer while destruction, so that it assures all wl
buffers are 
released. Otherwise, usually the last buffer's callback is not called,
which leads to leak of GstVaapiDisplay. This is motivated by gstwaylandsink.
Note that, when the last buffer's callback is called,
relevant frame's callback is usually not called.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.