"GStreamer" (GNOME Bugzilla)
2017-03-16 06:29:52 UTC
https://bugzilla.gnome.org/show_bug.cgi?id=780128
Bug ID: 780128
Summary: vaapi: playbin3 doesn't work with vaapi elements on
X11
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gstreamer-vaapi
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@igalia.com
QA Contact: gstreamer-***@lists.freedesktop.org
CC: ***@gmail.com, ***@igalia.com
GNOME version: ---
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.
Bug ID: 780128
Summary: vaapi: playbin3 doesn't work with vaapi elements on
X11
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gstreamer-vaapi
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@igalia.com
QA Contact: gstreamer-***@lists.freedesktop.org
CC: ***@gmail.com, ***@igalia.com
GNOME version: ---
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.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.