4k Video Frame Drops (video stuttering)

[mindrunner]

Important Information

Provide following Information:

• mpv version

mpv 0.33.1-dirty Copyright © 2000-2020 mpv/MPlayer/mplayer2 projects
 built on UNKNOWN
FFmpeg library versions:
   libavutil       56.70.100
   libavcodec      58.134.100
   libavformat     58.76.100
   libswscale      5.9.100
   libavfilter     7.110.100
   libswresample   3.9.100
FFmpeg version: n4.4

• Linux Distribution and Version

arch

• Source of the mpv binary

pacman

• Window Manager and version

sway 1:1.6.1-1

• GPU driver and version

intel

mpv --no-config --log-file=output.txt HDR10-LG-Cymatic-Jazz*
output.txt

mpv --no-config --hwdec=auto --log-file=output-hw.txt HDR10-LG-Cymatic-Jazz*
output-hw.txt

Reproduction steps

mpv --no-config video.x264.mkv

Playing a high quality Video results in heavy frame drops and messages like

Audio/Video desynchronisation detected! Possible reasons include too slow
hardware, temporary CPU spikes, broken drivers, and broken files. Audio
position will not match to the video (see A-V status field).

Also, the mouse cursor movement seems not smooth anymore then.

This happens with 4k Videos x264/x265 and only if the mpv window is actually full screen on a 4k monitor. A screen with lower resolution or a smaller window gives a better experience. I noticed that intel-gpu-top shows 100% load onRender/3D, but only about 30% on Video.

I suspect that this is more an issue with the actual rendering on the screen and not the video decoding itself. However, it is unclear to me if that is an issue with mpv or sway/wayland, or even something else.

Other apps with mpv backend (e.g. plexmediaplayer) show the same behaviour.

VLC is able to play videos without any issues

[Dudemanguy]

It sounds like you need to enable hardware decoding. Press ctrl+h to test it.

[mindrunner]

It is the same with and without hardware decoding.

[philipl]

Intel iGPUs cannot do much post processing on 4K content at 4K size. You need to run vo=gpu in dumb mode and you will have no luck going above 24fps even then. You need a real GPU to do 4k60.

[mindrunner]

This does not really make sense to me.

1. It works in another video player (VLC)
2. Video Rendering is at about 30% load

So I guess, the GPU is not at its limit when decoding the video, right?

What do you mean by dumb mode?

[mindrunner]

More information:

There are 4k Videos which are being rendered without any problem, for example:
https://www.demolandia.net/downloads.html?id=247525

And then some are problematic, e.g.:
https://www.demolandia.net/downloads.html?id=64388452

[mindrunner]

Oh and I am pretty sure it used to work some months ago. I have never had problems and I think an i7-10875H CPU/GPU should be capable of bringing 4k to the screen.

[Dudemanguy]

Have you tried xorg? Does it perform better/worse/same for you?

[mindrunner]

same/similar issues with i3/xorg

[CounterPillow]

try --hdr-compute-peak=no if those videos are 10-bit.

[philipl]

Yeah, the sample identified as 'problematic' is an HDR clip and the one that's fine is not. So basically, the hdr post-processing is too intensive. Maybe basic HDR10 with a single peak value for the whole file would be fine.

[mindrunner]

I do have issues with non-HDR videos as well. The two I posted were only examples.

--hdr-compute-peak=no does not really change anything.

Is there any explanation why VLC is so much more performant/efficient than mpv?

[avih]

You really need to post a log (when the issue happens) like the issue template requires. Otherwise, everyone is just shooting in the dark.

[mindrunner]

I was so sure I did that already. So sorry. Here it comes! :)

mpv --no-config --log-file=output.txt HDR10-LG-Cymatic-Jazz*
output.txt

mpv --no-config --hwdec=auto --log-file=output-hw.txt HDR10-LG-Cymatic-Jazz*
output-hw.txt

[skrew]

I have the same problem with a 4K TV channel on my MBP 2018 and my iOS app (the other "well-know" app play it without problem)
What is strange is, on the mac, pressing CTRL+H fixes the problem (as i understand, it force hw decoder)

CPU usage: 290% and frames drop
After CTRL+H: 31%

I will put full logs + sample video if you need it, waiting to see if logs provided by @mindrunner are enough

Edit: On my mac, adding -hwdec=auto-safe fixes the problem, but replacing auto by auto-safe on iOS app don't fixes it

[LaserEyess]

@mindrunner I think you're gonna have to give more information on your hardware and software set up. I'm on a kaby lake i7-7500U with an intel HD620 GPU and it chews through those videos on dumb mode just fine. This is nowhere near cutting edge in hardware performance so I would expect anything newer than this (~2017-2018) to work just as well.

The "problematic" video mentioned above has 0 performance issues despite being nearly 70 Mbps HEVC 10bit and scaled from 4k to 1080p.

Here's some statistics from doing mpv --no-config --hwdec=vaapi

You can see that it is barely going over 4 ms/frame, which is extremely good. Likewise, the other video where you have 0 performance issues works just as well for me.

So, what GPU are you using, what CPU are you using? What kernel version (assuming arch, mainline or lts?), what mesa version, what vaapi driver, what openGL driver, etc.

[mindrunner]

This is nowhere near cutting edge in hardware performance so I would expect anything newer than this (~2017-2018) to work just as well.

Yeah, I am pretty sure it used to work on this computer w/o any problems.

Computer: Dell Precision p5750 (Very similar to the current XPS 17)
CPU: Intel(R) Core(TM) i7-10875H CPU @ 2.30GHz
GPU: Intel UHD Graphics 630 (I think)

mesa: extra/mesa 21.1.4-1
kernel: 5.12.14-zen1-1-zen
vaapi: community/intel-media-driver 21.2.1-1 (not sure if that is what you were asking for)
opengl: also not sure how to figure that out.

I am usually on all latest versions of packages. Updating the system quite frequently.

[LaserEyess]

Your openGL driver is most likely iris, which is mesa's openGL driver for intel GPUs. And your GPU is better than mine (though probably not significantly better) so those videos should be no issue for you to play. Can you get a screenshot of page 2 on stats.lua? You can use ctrl+s to get a screenshot with the OSD on. Press shift+i to enable stats and the 2 to go to page 2. I'm curious what the bottleneck is.

EDIT:

Yeah, I am pretty sure it used to work on this computer w/o any problems.

Any approximate version?

[mindrunner]

I'm curious what the bottleneck is.

As I am. Thanks for jumping in btw. This is bugging me for a while now.

Your openGL driver is most likely iris, which is mesa's openGL driver for intel GPUs.

I remember playing around with that in the past because of some other bug. How can I check I am on default setting and make sure I am using some weird config somewhere which slows everything down

an you get a screenshot of page 2 on stats.lua?

This is kind of confirming what I see in intel_gpu_top mentioned earlier: I noticed that intel-gpu-top shows 100% load onRender/3D, but only about 30% on Video.

Any approximate version?
No, unfortunately not. I remember there was a similar problem in a sway-git/ wlroots-git version which (as far as i can remember) made things even worse as they are now. But that was supposed to be fixed before it got released. However, I have no idea if that is related at all.

[mindrunner]

I remember playing around with that in the past because of some other bug. How can I check I am on default setting and make sure I am using some weird config somewhere which slows everything down.

I guess that was this workaround: https://wiki.archlinux.org/title/Intel_graphics#Old_OpenGL_Driver_(i965)
However, I cennot see this env set anywhere. So I guess i am using iris

Also making clear that I do not have Guc/Huc active (https://wiki.archlinux.org/title/Intel_graphics#Enable_GuC_/_HuC_firmware_loading). Not sure if that matters here.

[LaserEyess]

Very interesting, it looks like something is bugging out for HDR. You can see the peak frame times of 66 ms there, but average is <1 ms. So I imagine this is some sort of driver issue? Can you try --gpu-api=vulkan? This could still be an mpv bug but it could also be some sort of shader bug in intel's drivers.

[mindrunner]

I think vulkan is not supported on wlroots, [yet]. :(

[le@p5750]: ~/temp>$ mpv --no-config --hwdec=vaapi --gpu-api=vulkan "dolby-chameleon-uhd-(www.demolandia.net).mkv"
 (+) Video --vid=1 (*) (hevc 3840x2160 23.976fps)
 (+) Audio --aid=1 --alang=eng (*) (ac3 6ch 48000Hz)
[vo/gpu/vulkan/libplacebo] vk->GetPhysicalDeviceSurfaceFormatsKHR(vk->physd, surf, &num, NULL): VK_ERROR_INITIALIZATION_FAILED (../src/vulkan/swapchain.c:169)
[vo/gpu/vulkan/libplacebo] Failed picking any valid, renderable surface format!
Xlib:  extension "NV-GLX" missing on display ":1".
Xlib:  extension "NV-GLX" missing on display ":1".
[vo/vdpau] Error when calling vdp_device_create_x11: 1
AO: [pulse] 48000Hz 5.1(side) 6ch float
VO: [wlshm] 3840x2160 yuv420p10
malloc(): invalid next size (unsorted)00 Dropped: 4
Aborted (core dumped)

[LaserEyess]

mpv renders through mesa directly, so your window manager or even wayland vs. x11 makes no difference. You probably need to install vulkan-intel to get a vulkan driver.

Sidenote: that crash is interesting, but not at all related to this issue.

[mindrunner]

Cool, learned something.

installed vulkan-intel, still crashing.

[le@p5750]: ~/temp>$ mpv --no-config --hwdec=vaapi --gpu-api=vulkan "dolby-chameleon-uhd-(www.demolandia.net).mkv"
 (+) Video --vid=1 (*) (hevc 3840x2160 23.976fps)
 (+) Audio --aid=1 --alang=eng (*) (ac3 6ch 48000Hz)
MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0

Segmentation fault (core dumped)

[LaserEyess]

Also a separate issue, potentially even from the one above. So ignoring that for now my best guess is a problem with mpv's shaders or a shader bug in mesa. If this is consistent for videos with HDR then that would certainly narrow it down. The Japan video did not have HDR so that explains why it works well. Someone like @haasn might know more.

You can report either of those crashes as separate issues btw, though usually they're most helpful with debug symbols, which requires recompiling mpv, and, if you're unlucky, potentially libplacebo and mesa.

[mindrunner]

Is there an easy way to see whether a video has HDR or not?

You can report either of those crashes as separate issues btw, though usually they're most helpful with debug symbols, which requires recompiling mpv, and, if you're unlucky, potentially libplacebo and mesa.

I guess there is some getting started stuff in mpv repo, huh? I might give it a whirl

[LaserEyess]

You can use mediainfo to check, for the most part. Quick and dirty would be mediainfo file.mkv | grep HDR. There's a better command to pull out the specific HDR parameters but mediainfo's documentation is pretty bad and it's not worth the effort to figure it out.

[mindrunner]

Cool, that helps. I have a bunch of Videos with that issue. Checked on one of those. Has HDR enabled as well. Looks like we are on the right track :)

[mindrunner]

Tried the verbose thing. Maybe the coredump comes from a turned off NVidia card using options nvidia "NVreg_DynamicPowerManagement=0x02"?

Just a wild guess, tho

[le@p5750]: ~/temp>$ mpv -v --no-config --gpu-api=vulkan "dolby-chameleon-uhd-(www.demolandia.net).mkv"
[cplayer] Command line options: '-v' '--no-config' '--gpu-api=vulkan' 'dolby-chameleon-uhd-(www.demolandia.net).mkv'
[cplayer] mpv 0.33.1-dirty Copyright © 2000-2020 mpv/MPlayer/mplayer2 projects
[cplayer]  built on UNKNOWN
[cplayer] FFmpeg library versions:
[cplayer]    libavutil       56.70.100
[cplayer]    libavcodec      58.134.100
[cplayer]    libavformat     58.76.100
[cplayer]    libswscale      5.9.100
[cplayer]    libavfilter     7.110.100
[cplayer]    libswresample   3.9.100
[cplayer] FFmpeg version: n4.4
[cplayer]
[cplayer] Configuration: /usr/bin/waf configure --prefix=/usr --confdir=/etc/mpv --enable-cdda --enable-dvb --enable-dvdnav --enable-libarchive --enable-libmpv-shared --disable-build-date
[cplayer] List of enabled features: 52arch alsa asm caca cdda cplayer cplugins cuda-hwaccel cuda-interop debug-build drm dvbin dvdnav egl egl-drm egl-helpers egl-x11 ffmpeg ffnvcodec gbm gbm.h gl gl-wayland glibc-thread-name glob glob-posix gpl iconv jack javascript jpeg lcms2 libarchive libass libavdevice libbluray libdl libm libmpv-shared libplacebo librt linux-fstatfs linux-input-event-codes lua memfd_create optimize plain-gl posix posix-or-mingw pthreads pulse rubberband shaderc shaderc-shared stdatomic uchardet vaapi vaapi-drm vaapi-egl vaapi-vulkan vaapi-wayland vaapi-x-egl vaapi-x11 vdpau vt.h vulkan wayland wayland-protocols x11 xv zimg zlib
[cplayer] Setting option 'v' = '' (flags = 8)
[cplayer] Setting option 'config' = 'no' (flags = 8)
[cplayer] Setting option 'gpu-api' = 'vulkan' (flags = 8)
[cplayer] Waiting for scripts...
[osd/libass] libass API version: 0x1501000
[osd/libass] libass source: commit: 0.15.1-0-g5447214643eacef71776350e779adf4b6c07bb3b-dirty
[osd/libass] Shaper: FriBidi 1.0.10 (SIMPLE) HarfBuzz-ng 2.8.1 (COMPLEX)
[osd/libass] Setting up fonts...
[osd/libass] Using font provider fontconfig
[osd/libass] Done.
[cplayer] Set property: shared-script-properties -> 1
[cplayer] Done loading scripts.
[cplayer] Running hook: ytdl_hook/on_load
[ytdl_hook] ytdl:// hook
[ytdl_hook] not a ytdl:// url
[ifo_dvdnav] Opening dolby-chameleon-uhd-(www.demolandia.net).mkv
[bdmv/bluray] Opening dolby-chameleon-uhd-(www.demolandia.net).mkv
[file] Opening dolby-chameleon-uhd-(www.demolandia.net).mkv
[demux] Trying demuxers for level=normal.
[mkv] Seeking to 441246013 to read header element 0x1c53bb6b.
[file] stream level seek from 131072 to 441246013
[mkv] Parsing cues...
[cplayer] Set property: shared-script-properties -> 1
[mkv] Seeking to 441247611 to read header element 0x1254c367.
[file] stream level seek from 441248365 to 6306
[mkv] All headers are parsed!
[osd/libass] libass API version: 0x1501000
[osd/libass] libass source: commit: 0.15.1-0-g5447214643eacef71776350e779adf4b6c07bb3b-dirty
[demux] Detected file format: Matroska
[cplayer] Opening done: dolby-chameleon-uhd-(www.demolandia.net).mkv
[osd/libass] Shaper: FriBidi 1.0.10 (SIMPLE) HarfBuzz-ng 2.8.1 (COMPLEX)
[osd/libass] Setting up fonts...
[osd/libass] Using font provider fontconfig
[osd/libass] Done.
[cplayer] Set property: shared-script-properties -> 1
[find_files] Loading external files in .
[cplayer] Running hook: ytdl_hook/on_preloaded
[mkv] select track 0
[mkv] select track 1
[cplayer]  (+) Video --vid=1 (*) (hevc 3840x2160 23.976fps)
[cplayer]  (+) Audio --aid=1 --alang=eng (*) (ac3 6ch 48000Hz)
[vo/gpu] Probing for best GPU context.
[vo/gpu/vulkan] Initializing GPU context 'waylandvk'
[vo/gpu/vulkan/libplacebo] Initialized libplacebo v120
[vo/gpu/vulkan/libplacebo] Creating vulkan instance with extensions:
[vo/gpu/vulkan/libplacebo]     VK_KHR_get_physical_device_properties2
[vo/gpu/vulkan/libplacebo]     VK_KHR_surface
[vo/gpu/vulkan/libplacebo]     VK_KHR_external_memory_capabilities
[vo/gpu/vulkan/libplacebo]     VK_KHR_external_semaphore_capabilities
[vo/gpu/vulkan/libplacebo]     VK_KHR_surface
[vo/gpu/vulkan/libplacebo]     VK_KHR_wayland_surface
[vo/gpu/wayland] Registered for protocol wl_shm
[vo/gpu/wayland] Registered for protocol wl_compositor
[vo/gpu/wayland] Registered for protocol wl_data_device_manager
[vo/gpu/wayland] Registered for protocol zwp_idle_inhibit_manager_v1
[vo/gpu/wayland] Registered for protocol xdg_wm_base
[vo/gpu/wayland] Registered for protocol zxdg_decoration_manager_v1
[vo/gpu/wayland] Registered for protocol wp_presentation
[vo/gpu/wayland] Registered for protocol wl_seat
[vo/gpu/wayland] Registered for protocol wl_output
[vo/gpu/wayland] Registered for protocol wl_output
[vo/gpu/wayland] Enabling server decorations
[vo/gpu/vulkan/libplacebo] Probing for vulkan devices:
[vo/gpu/vulkan/libplacebo]     GPU 0: Intel(R) UHD Graphics (CML GT2) (integrated)
[vo/gpu/vulkan/libplacebo]            uuid: 95:68:AE:BF:43:D0:DF:1E:A5:C3:16:C3:7A:1F:3C:A2
[vo/gpu/vulkan/libplacebo]     GPU 1: NVIDIA Quadro RTX 3000 with Max-Q Design (discrete)
[vo/gpu/vulkan/libplacebo]            uuid: B9:AA:E3:46:19:9B:C8:97:38:A7:E7:F2:73:FF:7E:71
Segmentation fault (core dumped)

[LaserEyess]

You'd need to provide a backtrace with debug symbols to see exactly where it's crashing. Again though, this is almost certainly a separate issue than your playback stuttering.

[mindrunner]

It should be (relatively) straight forward to downgrade mesa

Well, the computer reproducing the issue is my daily driver and very important to be reliable. Downgrading mesa on arch sounds like a very bad idea actually. I might try some time, but that is definitely nothing I can do quickly I guess. Unfortunately, I have no other box to reproduce that issue and a VM is not an option here.

downgrading the kernel to the lts version (5.10) fixed the issue for me.

Interesting, will try that out and confirm if I see same behavior.

[mr-berndt]

So did it?

[Hergeirs]

I just installed linux-lts and booted from it on my machine. I commented --hdr-compute-peak=no from my config and experienced no lost frames at all on any of the test videos above and my own.
Kernel version:

$ uname -r
5.10.88-2.1-lts

I need to run a newer kernel though as oled brightness control is not baked into the lts version.
Would this then be classified as a kernel regression?

[LaserEyess]

If you guys can confirm that an older linux kernel works but a newer one does not, then that is by definition a kernel bug, and you should report it to the intel kernel driver bug tracker. You should first check to make sure this issue isn't already reported, since I didn't.

If this is a new issue, I would be very specific about reporting it, making sure to note:

• A feature called "global atomics" used by mpv for the --hdr-compute-peak option has regressed and causes performance issues
• This feature works properly in 5.10.x, but does not in 5.15.x
• This regression only occurs on some intel GPUs
• This regression is independent of vulkan or openGL, and independent of different openGL drivers (iris, i965)

You're most likely going to be asked to bisect, but if it's this trivial to reproduce then the bisection should be relatively clean. You can bisect only certain paths, so you can just append -- drivers/gpu/drm/i915 to your git bisect command and it will only bisect changes for the intel driver.

[Hergeirs]

Thank you for the pointers.
I have reported the issue as well as I had time to according to your pointers (thanks) and the guideline on their gitlab repo. Please give me feedback if you find anything lacking or erroneous.
https://gitlab.freedesktop.org/drm/intel/-/issues/4917

[mr-berndt]

I can report that moving to linux-lts on arch entirely resolved the issue and I can watch 4k HDR with frame brightness measurement (as verified with "i" and "2" OSD) on an Intel i7-7500U flawlessly.

[panchoh]

Oops, on Arch linux-lts has been bumped to 5.15.15, which means that the 5.10 kernel is no longer available. It had to happen sooner or later... Be advised, @mr-berndt; pin it while you can! :-)

(Thanks a bunch to @LaserEyess for the pointers and to @Hergeirs for reporting this upstream).

[mr-berndt]

Thx for the hint, so the Long Term Support Kernel lasted me exactly 12 days, haha!

[damige]

Interesting i have this same problem with the same hardware (XPS 7590) and have narrowed the kernels down where the problem started:
5.11.16 good
5.12.1 bad

Tried to bisect but the second bisect (first one is good) allways throws an error

"/usr/include/c++/11.1.0/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options."

Even when the flags are enabled it doest compile anymore.

Probebly best if someone else with more compile and git knowledge looks into it

[alikasundara]

Oops, on Arch linux-lts has been bumped to 5.15.15, which means that the 5.10 kernel is no longer available.

Arch wiki lists some older Longterm kernels here: https://wiki.archlinux.org/title/kernel
5.10 is available (via AUR), here: https://aur.archlinux.org/packages/linux-lts510/

[LaserEyess]

You don't need to re-compile your kernel to work around this, just do --hdr-compute-peak=no.

Interesting i have this same problem with the same hardware (XPS 7590) and have narrowed the kernels down where the problem started:
5.11.16 good
5.12.1 bad

This is the most important piece of information in this thread. This is a kernel bug introduced in 5.12. Please move all of this conversation to the intel bug report. As you can see there there's a reply from someone requesting more information. Everything said here needs to be repeated there since this is very clearly not an mpv bug and instead an intel bug.

[berkley4]

Thank you for the pointers. I have reported the issue as well as I had time to according to your pointers (thanks) and the guideline on their gitlab repo. Please give me feedback if you find anything lacking or erroneous. https://gitlab.freedesktop.org/drm/intel/-/issues/4917

I noticed from the first dmesg log that you are manually setting quite a few kernel parameters, including several i915-related ones. The consequences can be seen by searching the text for "Setting dangerous option" or "tainting kernel", which might well put off kernel developers from looking into the problem.

The i915 options are usually set to sane defaults by upstream, and force-setting some of them can cause problems/expose bugs. For the purposes of the bug report you ought to only set paramaters which are absolutely necessary to successfully boot your system.

(As an aside, commands such as 'modinfo i915' and 'systool -v -m i915' can aid in troubleshooting, eg to see if disabling a default-enabled parameter cures a problem).

Tried to bisect but the second bisect (first one is good) allways throws an error

"/usr/include/c++/11.1.0/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options."

Even when the flags are enabled it doest compile anymore.

This might be related to and fixable via https://gitlab.com/cki-project/kernel-ark/-/merge_requests/843/diffs?commit_id=e187313e5f0086538fefe0925ef84480f99616d8

[haasn]

By the way, for those of you affected by this issue, can you test if --vo=gpu-next fixes it?

[damige]

By the way, for those of you affected by this issue, can you test if --vo=gpu-next fixes it?

Removed "hdr-compute-peak=no" in config, added vo=gpu-next , but does not resolve stutter.
Did not make it worse either, same stutters. Reverted to: hdr-compute-peak=no.

[mindrunner]

Hm, why closed? Why completed? What is the solution?

[LaserEyess]

The mpv solution is --hdr-compute-peak=no, there's nothing else to do. As I said a year ago, this is a kernel/hardware issue that mpv can't do anything about. It's a clear regression where it worked in 5.11 and not in 5.12. If you can still reproduce this and are brave enough to bisect, you can do a proper bug report to intel and maybe they can fix it.

[mindrunner]

You're right. Now I remember. Thanks for heads up! And all patience!! :)

[berndbb]

I too experienced heavy frame drops watching a 2k HDR-Video, on a second run I tried a 1080p HDR Video where the same amount of frame drops seemed to happen. Another observation is colours being too strong, so everyone looks like having a sunburn.
I use a Intel P4560 with a Intel® HD Graphics 610 (https://ark.intel.com/content/www/us/en/ark/products/97143/intel-pentium-processor-g4560-3m-cache-3-50-ghz.html, so this is a poor man's machine.

To cut a long story short: --hdr-compute-peak=no or downgrading the kernel didn't help me. All problems (frame drops and weird colours) are gone using --vo=vaapi instead of recommended --vo=gpu (together with --hwdec=vaapi-copy)

I have to bear the message about vaapi being inferior to vo=gpu, but I hope vaapi will be supported for longer since it gives me a satisfying video-experience.

[mindrunner]

Might be another issue and not directly related. Can you provide an example video, so I can test it on my box.

Also, we should really consider moving that to linux/intel bugtracker to not create so much noise here.

[berndbb]

1080p_HDR_sample.zip

I tried to upload a sample, hope this will do to show the issues.

mpv --no-config --hwdec=vaapi-copy -vo=gpu 1080p_HDR_sample.mkv
Stutter in or skippy movement, too much red colour, watch the skin of the actors.

mpv --no-config --hwdec=vaapi-copy -vo=vaapi 1080p_HDR_sample.mkv
To my opinion proper playback

The question remaining for me is:
Is this a problem with
a) mpv (unlikely, because on other GPUs there seems to be no issues)
b) driver implementation? (worth reporting to linux/intel?!)
c) just a performance issue (meaning the simple GPUs of intel CPUs are simply too weak to perform properly with --vo=gpu?)

[mindrunner]

The Video heavily stutters on my computer. It actually renders my whole Desktop unusable (mouse cursor gets very laggy). Cannot confirm the color issue, tho.

hw:
Intel(R) Core(TM) i7-10875H CPU @ 2.30GHz

If I try with -vo=vaapi. The player does not open.
Log:

❯ mpv --no-config --hwdec=vaapi-copy -vo=vaapi 1080p_HDR_sample.mkv
 (+) Video --vid=1 (*) (hevc 1920x1080 23.976fps)
 (+) Audio --aid=1 --alang=eng 'DTS-HD MA 5.1' (eac3 6ch 48000Hz)
File tags:
 Title: The Dark Knight (2008) DV
[vo/vaapi] OSD format not supported. Disabling OSD.
[vo/vaapi] Warning: this compatibility VO is low quality and may have issues with OSD, scaling, screenshots and more.
[vo/vaapi] vo=gpu is the preferred choice in any case and includes VA-API support via hwdec=vaapi or vaapi-copy.
Using hardware decoding (vaapi-copy).
[autoconvert] Converting p010 -> yuv420p
AO: [pipewire] 48000Hz 5.1(side) 6ch floatp
[autoconvert] Converting p010 -> yuv420p
VO: [vaapi] 1920x1080 yuv420p
[vo/vaapi] vaPutSurface() failed (invalid parameter)
[vo/vaapi] vaPutSurface() failed (invalid parameter)
AV: 00:00:00 / 00:00:21 (0%) A-V:  0.000
[vo/vaapi] vaPutSurface() failed (invalid parameter)
AV: 00:00:00 / 00:00:21 (0%) A-V:  0.023
[vo/vaapi] vaPutSurface() failed (invalid parameter)
[vo/vaapi] vaPutSurface() failed (invalid parameter)
AV: 00:00:00 / 00:00:21 (1%) A-V:  0.020
[vo/vaapi] vaPutSurface() failed (invalid parameter)

[LaserEyess]

@mindrunner That is a specific issue with libva not supporting DRI3, which is required for xwayland, not really related but see intel/libva#536. This was "fixed" by downgrading it from a crash to an error. Until libva supports DRI3, it won't work.

@berndbb Please see this post

1. Do all HDR videos reproduce the issue for you?
2. Does --hdr-compute-peak=no or 4k Video Frame Drops (video stuttering) #8981 (comment) fix the issue?
3. If 2), then what is your exact GPU model and your exact GPU driver. (vulkaninfo and/or glinfo should give this)

If 2) doesn't work for you, then this is not your issue, and you should open a new one and fill out the issue template.

Emphasis mine. Please open another issue. Also keep in mind that HDR is a performance feature, it has no hardware acceleration on linux or vaapi, so it requires a decent GPU. If you have a potato machine, you simply will not be able to play it back properly. You can mitigate performance impacts by turning down settings but at some point your GPU is just not powerful enough and you have to accept that.

[berndbb]

I consider opening another issue.

I don't use HDR videos regularly, but as far as I see, all HDR videos show the same behaviour.
All HDR videos are playable with my "potato machine" using --vo vaapi without any problems for me.

If mpv did not insist on suggesting to not use vo vaapi at all, I would have thought it to be a performance problem. But if vo gpu is superior in any case to vo vaapi, then what is wrong?

For the record:
glxinfo.txt

[LaserEyess]

--vo=vaapi has a very, very different purpose than --vo=gpu. It is more designed for potato systems like yours, so use it if it works. The warning is there fore people who mistakenly believe that you need it to get hwdec. The reason --vo=gpu is superior is because it's better at rendering, but that requires more processing power that your GPU doesn't have. So use vaapi, there's no issue.

[berndbb]

@LaserEyess
Thank you very much for clarification. I already started to open a new issue, so I finished it.
But what you are saying puts everything together: no bug here, but my hardware beeing not sufficient for demanding --vo=gpu.