diff options
author | Philip Langdale <philipl@overt.org> | 2022-10-14 11:45:04 -0700 |
---|---|---|
committer | Philip Langdale <github.philipl@overt.org> | 2022-10-15 09:30:46 -0700 |
commit | 345342f50ab533f08ff9b1603279b5580acfefe1 (patch) | |
tree | f8329eb94bc1c0684d166232f12d0179e0677c7a /osdep/windows_utils.c | |
parent | 6f7506b660b83a44535eceb12a8b9c4de6c0eb36 (diff) | |
download | mpv-345342f50ab533f08ff9b1603279b5580acfefe1.tar.bz2 mpv-345342f50ab533f08ff9b1603279b5580acfefe1.tar.xz |
hwdec/dmabuf_interop_gl: work-around implicit rgba swizzling
This has been a long standing problem that I think was the root cause
for wm4's vaapi shitlist. As DRM explicit supports all possible rgba
orderings, but OpenGL only guarantees support for 'rgba8', something
has to happen to support import of dmabufs with non-native ordering.
Although undocumented, it appears that somewhere in the import on the
GL side, the ordering is swizzled to rgba - which makes sense as that's
the only way to be able to support importing all the different formats.
But we didn't know this, and we do our own swizzling based on the
original imgfmt - which matches the drm format. So we get double
swizzling and messed up colours.
As there is no way for us to express that the GL swizzle happened to
the rest of mpv, the easiest thing to do is fudge the format to the
natural ordering so the GL doesn't change anything, then our swizzling
will do the right thing in the end.
Note that this change doesn't handle 0rgb and 0bgr because they seem to
be affected by some additional feature/bug that is mangling the
ordering somewhere that equally affects Vulkan interop. That could be a
vaapi driver bug or something going on in ffmpeg.
Diffstat (limited to 'osdep/windows_utils.c')
0 files changed, 0 insertions, 0 deletions