Featureless purple output with HEVC, VDPAU and gpu-next

[rankinc]

Important Information

• mpv-0.36.0-3.fc39.x86_64 and mpv-nightly-0 0.37.0^443c248-1
• Fedora 39
• Source from Fedora Project and Terra
• Window Manager: gnome-shell-45.4-1.fc39.x86_64
• AMD RX 6600, Mesa 23.3.5

Do not attempt to use Mesa 24+ with RX 6600 until fix for #10599 is merged. Edit: #27642 has now been merged into Mesa 24.1.0-devel.

Note that RX 6600 supports hardware decoding for HEVC:

$ vdpauinfo

Decoder capabilities:

name                        level macbs width height
----------------------------------------------------
HEVC_MAIN                      186 139264  8192  4352
HEVC_MAIN_10                   186 139264  8192  4352
HEVC_MAIN_STILL                --- not supported ---
HEVC_MAIN_12                   --- not supported ---
HEVC_MAIN_444                  --- not supported ---
HEVC_MAIN_444_10               --- not supported ---
HEVC_MAIN_444_12               --- not supported ---

Reproduction steps

Your graphics card must support hardware decoding of HEVC.

$ mpv --msg-level=vd=debug --vo=gpu-next --profile=gpu-hq --hwdec=vdpau sample_1280x720.hevc

Expected behavior

Video plays correctly, as it already does with VA-API.

Actual behavior

Video is featureless and purple, and console fills with errors like:

VO: [gpu-next] 1280x720 vdpau[yuv420p]
Mesa: error: GL_INVALID_VALUE in glFramebufferTexture2D(invalid level 0)
[vo/gpu-next/libplacebo] Failed creating framebuffer: error code 36055
[vo/gpu-next/libplacebo] gl_tex_destroy: OpenGL error: GL_INVALID_VALUE
[vo/gpu-next] Failed rendering frame!

The problem appears to be that the texture object is immutable, but its "immutable levels" attribute is zero. I have no idea how the "immutable levels" attribute should acquire its value, but a value of "1" would allow gpu-next to work :shrug:.

Log file

output.txt

Sample files

sample_1280x720.hevc

[sfan5]

Note that 0.36.0 is outdated and unsupported. Have you tried 0.37.0?

[rankinc]

Note that 0.36.0 is outdated and unsupported. Have you tried 0.37.0?

I tried, but I couldn't find any RPMs that were compatible with Fedora 39. Basically, it would need to install into somewhere like /opt, along with all of its dependencies (including libplacebo), so that it wouldn't conflict with anything.

[rankinc]

I think I've managed to install mpv 0.37.0 locally by using rpm2cpio on these RPMs:

• mpv-nightly-libs-0 0.37.0^443c248-1.fc39.x86_64.rpm
• mpv-nightly-0 0.37.0^443c248-1.fc39.x86_64.rpm
• libplacebo-6.338.2-1.fc40.x86_64.rpm

(Not sure I needed mpv-nightly-libs). And "yes", I can still reproduce this issue using mpv 0.37.0^443c248-1.

[sfan5]

Well that's good to know. I have the same GPU as you so I'd be in a good position to verify this bug, but my ffmpeg and mpv is compiled without vdpau as there's generally no reason to use that with AMD. :shrug:

[rankinc]

but my ffmpeg and mpv is compiled without vdpau as there's generally no reason to use that with AMD. 🤷

Then download the RPMs I mentioned above, convert them into .cpio files using rpm2cpio, and then install them somewhere else, exactly as I did :roll_eyes:.

However, it would actually be more useful if someone with an NVIDIA card (that supports HEVC decoding in hardware) could test this so that we could eliminate Mesa as the problem.

FYI VLC 3.x only supports VA-API when compiled with old ffmpeg, which means that VDPAU is currently the only "hardware acceleration" game in town for VLC until VLC 4 is released.

[guidocella]

The sample plays correctly on NVIDIA with --no-config --vo=gpu-next --gpu-context=x11 --hwdec=vdpau sample_1280x720.hevc

[rankinc]

Fixed in Mesa 24.1.0-devel.

[CounterPillow]

I'm glad the bug you experienced with an out-of-date mpv that was in a component that is not mpv when using an API you should have no reason to use with your hardware but use anyway because of a different application for some reason is now resolved.

[rankinc]

I'm glad the bug you experienced with an out-of-date mpv

And also reproduced with the current 0.37.0 nightly release.

that was in a component that is not mpv

The problem could have existed in libplacebo, which AIUI is also part of mpv.

when using an API you should have no reason to use with your hardware but use anyway

What does that have to do with anything? There was never any reason for that functionality not to work, regardless of how useful you might have thought it was / wasn't.

because of a different application for some reason is now resolved.

Not quite sure what you're saying here, but since the issue has now been identified as existing in Mesa it seems only polite not to leave this ticket open.