Bug 105013

Summary:	[regression] GLX+VA-API+clutter-gst video playback is corrupt with Mesa 17.3 (but is fine with 17.2)
Product:	Mesa	Reporter:	Daniel van Vugt <daniel.van.vugt>
Component:	GLX	Assignee:	Thomas Hellström <thellstrom>
Status:	RESOLVED FIXED	QA Contact:	mesa-dev
Severity:	normal
Priority:	medium	CC:	david.regev, piotrdrag, thellstrom, tjaalton
Version:	17.3
Hardware:	Other
OS:	All
See Also:	https://launchpad.net/bugs/1747744 https://bugzilla.gnome.org/show_bug.cgi?id=792227
Whiteboard:
i915 platform:		i915 features:
Attachments:	Suggested fix

Description Daniel van Vugt 2018-02-08 07:18:45 UTC

[regression] Video playback is corrupt with Mesa 17.3 (but is fine with 17.2)

THESE STILL WORK:

gst-play-1.0 --videosink glimagesink bbb_sunflower_1080p_60fps_normal.mp4
gst-play-1.0 --videosink xvimagesink bbb_sunflower_1080p_60fps_normal.mp4
gst-play-1.0 --videosink ximagesink bbb_sunflower_1080p_60fps_normal.mp4

THESE DON'T WORK:

gst-play-1.0 --videosink clutterautovideosink bbb_sunflower_1080p_60fps_normal.mp4
totem bbb_sunflower_1080p_60fps_normal.mp4

Specifically the corruption only occurs under the combination of:

Xorg +
VA-API (gstreamer1.0-vaapi) +
clutterautovideosink (libclutter-gst-3.0-0) +
Mesa 17.3.3

So that's includes the default video player (totem) in Ubuntu 18.04's default session :(

We first noticed the regression when Ubuntu 18.04 upgraded Mesa
from: 17.2.4-0ubuntu2 (WORKING)
to: 17.3.3-0ubuntu1 (FAILS)

One workaround that works is to downgrade to these specific packages:

https://launchpad.net/ubuntu/+source/mesa/17.2.4-0ubuntu2/+build/13697262/+files/libgl1-mesa-glx_17.2.4-0ubuntu2_amd64.deb
https://launchpad.net/ubuntu/+source/mesa/17.2.4-0ubuntu2/+build/13697262/+files/libglapi-mesa_17.2.4-0ubuntu2_amd64.deb

More information: https://launchpad.net/bugs/1747744

Comment 1 Timo Aaltonen 2018-02-08 07:58:50 UTC

broken on 18.0.0-rc2 as well

Comment 2 Daniel van Vugt 2018-02-08 08:57:31 UTC

Bisected.

5198e48a0d9a991d897cf4c71fdb82ac0e43b025 is the first bad commit
commit 5198e48a0d9a991d897cf4c71fdb82ac0e43b025
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Fri Aug 11 09:57:51 2017 +0200

    loader_dri3/glx/egl: Remove the loader_dri3_vtable get_dri_screen callback
    
    It's not very usable since in the rare, but definitely existing case that
    we don't have a current context, it will return NULL.
    
    Presumably it will always be safe to use the dri screen the drawable was
    created with for operations on that drawable.
    
    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

:040000 040000 16f02799b47aefb1cac40343c1ae0c7dd6d1b63a ca0b60d0abef87f31c0b0052de72b67e6d1f9311 M	src

Comment 3 Thomas Hellström 2018-02-08 10:00:25 UTC

Hm,

This is really a cleanup commit assuming that it's illegal to pass drawables around different screens. 

But I see now that the @draw argument to get_dri_screen() is not used in the implementations, so the correct cleanup appears to be to remove that argument,
and indeed let the function return the screen of the currently bound context.

From what I can tell, reverting that commit should be safe.

But I'll put together a proper patch.

Comment 4 Thomas Hellström 2018-02-08 10:27:07 UTC

Created attachment 137229 [details] [review]
Suggested fix

Daniel, could you try the attached patch to verify that it fixes the problem.

Comment 5 Timo Aaltonen 2018-02-08 16:50:12 UTC

Thanks, tested on top of 18.0.0-rc2 and it works now.

Comment 6 Daniel van Vugt 2018-02-09 02:38:00 UTC

Verified (with git master): attachment 137229 [details] [review] does fix the problem. Thanks.

Comment 7 Thomas Hellström 2018-02-09 08:29:01 UTC

Thanks. Sent the patch for review. If anyone wants a Tested-by: tag, please respond to the PATCH email on mesa-dev.

/Thomas

Comment 8 Thomas Hellström 2018-02-20 09:39:48 UTC

Fixed in mesa master with backport requests.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.