`hwdec=vaapi` not working with `vo=dmabuf-wayland` on my system

[morialo3]

mpv Information

mpv v0.40.0-dirty Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
 built on Apr  4 2025 07:28:54
libplacebo version: v7.349.0
FFmpeg version: n7.1
FFmpeg library versions:
   libavcodec      61.19.100
   libavdevice     61.3.100
   libavfilter     10.4.100
   libavformat     61.7.100
   libavutil       59.39.100
   libswresample   5.3.100
   libswscale      8.3.100

Other Information

- Linux version:`"Arch Linux"`
- Kernel Version:`Linux Korialo-Arch 6.14.1-273-tkg-eevdf #1 SMP PREEMPT_DYNAMIC TKG Wed, 09 Apr 2025 09:49:46 +0000 x86_64 GNU/Linux`
- GPU Model:`00:02.0 VGA compatible controller [0300]: Intel Corporation CometLake-H GT2 [UHD Graphics] [8086:9bc4] (rev 05)`
- Mesa/GPU Driver Version:`OpenGL version string: 4.6 (Compatibility Profile) Mesa 25.0.3-arch1.1`
- Window Manager and Version:`Hyprland 0.48.1 built from branch  at commit 29e2e59fdbab8ed2cc23a20e3c6043d5decb5cdc  (version: bump to v0.48.1).`
- Source of mpv:`pacman`
- Latest known working version:`v0.39`
- Issue started after the following happened:`update`

Reproduction Steps

No hardware acceleration happens, throws error, and video plays.

 mpv --no-config --vo=dmabuf-wayland --hwdec=vaapi  'https://www.twitch.tv/videos/2314819556?collection=bL1PZGrMDBgM6Q'

Hardware accelerated(?), no errors, video plays normally.

 mpv --no-config --vo=dmabuf-wayland --hwdec=vaapi  --vf=format=fmt=nv12 'https://www.twitch.tv/videos/2314819556?collection=bL1PZGrMDBgM6Q'

Expected Behavior

vaapi should work without this workaround --vf=format=fmt=nv12

Actual Behavior

No hardware acceleration.

Log File

Case - 1 Debug without workaround

test_1.log

Case - 2 Debug with the workaround

test_2.log

Sample Files

No response

I carefully read all instruction and confirm that I did the following:

• I tested with the latest mpv version to validate that the issue is not already fixed.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

[guidocella]

Try --gpu-api=opengl

[Dudemanguy]

[vo/dmabuf-wayland/vaapi] Mapped surface with format nv12; drm format 'NV12(0100000000000002)' is not supported by compositor and GPU combination.

The compositor doesn't support nv12. So we have to autoconvert the format.

[vd] Using hardware decoding (vaapi).

hwdec looks like it's working to me though.

What's the actual problem? In the log, I see this gets spammed.

delaying audio start 393.057000 vs. 333.499000, diff=59.558000

Shouldn't have anything to do with hwdec though should just be the stream.

[kasper93]

Try --gpu-api=opengl

gpu-api is not used in vo=dmabuf-wayland

[morialo3]

The compositor doesn't support nv12. So we have to autoconvert the format.

That's true but looks like my gpu not happy with bgr0

[   2.862][e][ffmpeg] filter: Hardware does not support output format bgr0.

hwdec looks like it's working to me though.

I checked with intel_gpu_top , no hardware acceleration, without me adding --vf=format=fmt=nv12

[morialo3]

Interestingly enough I have a 4k HEVC sample video that works perfectly fine:

 mpv --no-config --vo=dmabuf-wayland --hwdec=vaapi --gpu-debug --log-file=test_3.log Downloads/4K\ HEVC\ 59.940\ Broadcast\ Capture\ Sample.mkv 

Log

test_3.log

Sample

[Dudemanguy]

I checked with intel_gpu_top , no hardware acceleration, without me adding --vf=format=fmt=nv12

This does a conversion via software first. bgr0 not working for you would just be a hardware limitation most likely.

Interestingly enough I have a 4k HEVC sample video that works perfectly fine:

That's a totally different format.

[morialo3]

This does a conversion via software first. bgr0 not working for you would just be a hardware limitation most likely.

Used to work with v0.39 before though. you can close this issue if you think it is user-end issue.

[Dudemanguy]

Did v0.39 pick bgr0 for that file?

[kasper93]

[   3.074][v][hwupload] Hardware conversion: scale_vaapi (nv12 -> bgr0)
[   3.074][i][autoconvert] Converting vaapi[nv12] -> vaapi[bgr0]
[   3.074][d][ffmpeg] mpv_src_default_in: w:1920 h:1080 pixfmt:vaapi tb:1/1000000 fr:60/1 sar:1/1 csp:bt709 range:tv
[   3.074][v][lavfi] Configuring hwdec_interop=vaapi for filter graph: scale_vaapi
[   3.074][e][ffmpeg] filter: Hardware does not support output format bgr0.
[   3.074][e][ffmpeg] filter: Failed to configure output pad on filter
[   3.074][f][lavfi] failed to configure the filter graph
[   3.074][f][vf] Cannot convert decoder/filter output to any format supported by the output.

I don't think it we constrain our format selection based on conversion capabilities. So this will fallback to software decoding.

But since only supported formats are rgb once, I doubt if we add logic to fallback to other one it would help in this case.

[   3.057][d][vo/dmabuf-wayland/vaapi] Supported formats:
[   3.057][d][vo/dmabuf-wayland/vaapi]  bgra
[   3.057][d][vo/dmabuf-wayland/vaapi]  bgr0
[   3.057][d][vo/dmabuf-wayland/vaapi]  rgb0
[   3.057][d][vo/dmabuf-wayland/vaapi]  rgb30

Possibly we could fallback to cpu conversion, but this require hwdownload and hwupload. Could you share 0.39.0 log? What it was doing?

[morialo3]

Did v0.39 pick bgr0 for that file?

No

[   3.551][v][hwupload] Hardware conversion: scale_vaapi -> rgb0
[   3.551][i][autoconvert] Converting vaapi[nv12] -> vaapi[rgb0]

Downgraded to v0.39 from https://archive.archlinux.org/packages/m/mpv/mpv-1%3A0.39.0-5-x86_64.pkg.tar.zst
Same commands

mpv --no-config --vo=dmabuf-wayland --hwdec=vaapi --gpu-debug --log-file=test_4.log 'https://www.twitch.tv/videos/2314819556?collection=bL1PZGrMDBgM6Q' 

Log

test_4.log

No issues in this case, maybe I should've bisected this release before opening this issue, my mistake.

[morialo3]

But since only supported formats are rgb once, I doubt if we add logic to fallback to other one it would help in this case.

Exactly @kasper93 .

[kasper93]

Hmm, look like vaapi[nv12] -> vaapi[rgb0] conversion works for you, while vaapi[nv12] -> vaapi[bgr0] doesn't. So this should be fixable. I don't recall that we had the constraints checks there before, so it kinda random breakage.

[morialo3]

Thanks @kasper93