GNOME Bugzilla – Bug 780128
vaapi: playbin3 doesn't work with vaapi elements on X11
Last modified: 2018-11-03 15:49:43 UTC
On the master, the following pipeline leads to deadlock with vaapi elements: USE_PLAYBIN3=1 gst-play-1.0 xxx.mp4 though this is working: gst-launch-1.0 filesrc location=xxx.mp4 ! decodebin3 ! vaapisink This issue includes a couple of issues. 1. About sharing vaapidisplay between vaapi elements. When we're using playbin(2) or decodebin2/3, vaapisink creates its own vaapidisplay first, then shares it with other elements vaapidecoder and vpp. But with playbin3, it's different. vpp creates vaapidisplay and shares with vaapidecoder, not vaapisink since it's not linked at this moment. Besides, playbin3 doesn't implement auto-query yet, IIRC. So vaapisink creates its own vaapidisplay. Finally, vaapisink get context query, share and use the vaapidisplay of vpp/vaapidecoder. Meanwhile, the shared vaapidisplay is vaapidisplayglx with glx context and XDisplay from gst-gl. 2. XDisplay from gst-gl should be handeld by xcb probably. Since the commit(https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/gst-libs/gst/gl?id=4f6c226bd24ae3ef66bd8f4c17b001444c9b0bf1) landed, This XDisplay can't work in our vaapiwindow_x11. Eventually this causes this deadlock. In wait_event in vaapiwindow_x11.c, it couldn't get the event MapNotify by this foreign XDisplay.
Oh, this is not deadlock, but it's infinite loop in wait_event.
(In reply to Hyunjun Ko from comment #0) > But with playbin3, it's different. > vpp creates vaapidisplay and shares with vaapidecoder, not vaapisink since > it's not linked at this moment. Besides, playbin3 doesn't implement > auto-query yet, IIRC. > So vaapisink creates its own vaapidisplay. Finally, vaapisink get context > query, share and use the vaapidisplay of vpp/vaapidecoder. > > Meanwhile, the shared vaapidisplay is vaapidisplayglx with glx context and > XDisplay from gst-gl. Regarding this, I would suggest new envirnment variable just like GST_VAAPI_ENABLE_CREATE_GL_CONTEXT or something. There are some cases that it creates (wrong) vaapidisplay with gl context even though it's not necessary. > > 2. XDisplay from gst-gl should be handeld by xcb probably. > Since the > commit(https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/gst- > libs/gst/gl?id=4f6c226bd24ae3ef66bd8f4c17b001444c9b0bf1) landed, This > XDisplay can't work in our vaapiwindow_x11. > > Eventually this causes this deadlock. In wait_event in vaapiwindow_x11.c, > it couldn't get the event MapNotify by this foreign XDisplay. Should we implement xcb stuff?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/53.