Bug 105013 - [regression] GLX+VA-API+clutter-gst video playback is corrupt with Mesa 17.3 (but is fine with 17.2)
Summary: [regression] GLX+VA-API+clutter-gst video playback is corrupt with Mesa 17.3 ...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: GLX (show other bugs)
Version: 17.3
Hardware: Other All
: medium normal
Assignee: Thomas Hellström
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-08 07:18 UTC by Daniel van Vugt
Modified: 2018-02-26 03:44 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Suggested fix (5.13 KB, patch)
2018-02-08 10:27 UTC, Thomas Hellström
Details | Splinter Review

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.