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 780128 - vaapi: playbin3 doesn't work with vaapi elements on X11
vaapi: playbin3 doesn't work with vaapi elements on X11
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer-vaapi
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
P2
Depends on:
Blocks:
 
 
Reported: 2017-03-16 06:29 UTC by Hyunjun Ko
Modified: 2018-11-03 15:49 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Hyunjun Ko 2017-03-16 06:29:52 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.
Comment 1 Hyunjun Ko 2017-03-16 06:31:28 UTC
Oh, this is not deadlock, but it's infinite loop in wait_event.
Comment 2 Hyunjun Ko 2017-03-16 06:47:50 UTC
(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?
Comment 3 GStreamer system administrator 2018-11-03 15:49:43 UTC
-- 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.