Skip to main content ↑ ↓
Topic: mpv and Hardware Acceleration (Read 2379 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

mpv and Hardware Acceleration

Foreword:

1. First it was ffmpeg 5, which removed VAAPi
2 Then it was mesa that removed VAAPi
3. VLC followed the lead because it depends on ffmpeg

Are you ready?

mpv coders are now in the process of transitioning from vo=gpu into vo=gpu-next

Quick test on AVC1 video in the following way results in over 2x higher CPU usage:

$ mpv --profile=gpu-hq --cscale=ewa_lanczossharp --scale=ewa_lanczossharp --hwdec=vaapi --vo=gpu-next video.mkv

reuslts in the following "error": [vo/gpu-next] 'ewa_lanczossharp' is deprecated and will be removed from vo=gpu-next in the future, use --scale=ewa_lanczos --scale-blur=0.981251 to replicate it.

Following the new vo=gpu-next output, as suggested, results in over 2x higher cpu usage. This means that instead of hardware decoding gpu-next uses software decoding on CPU:

$ mpv --profile=gpu-hq --scale=ewa_lanczos --scale-blur=0.981251 --vo=gpu-next video.mkv

PS. I won't even start on shenanigans required for firefox or chrome. They simply don't work and are noth worth bothering. On MS windows, it all just works. vlc, mpv, chrome*, firefox, librewolf. All good. Users don't know what VAAP or hwa is and don't have to.

Re: mpv is The Next Target and mpv Codeers Are Removing Hardware Acceleration

Reply #1 –
Thing is sw rendering is always more accurate and natural, and the bottom half is off topic, if you would have looked at the announcements text you would have noticed ewa_lanczossharp, and hwdec options changed. Maybe it even works, you didn't tell the hardware even.
This doesn't even matter unless you have ancient cpu and you watch 4k60+ stuff. Literally a core2duo from 14 years ago can decode 4k@24.
Here this time there's nothing at the bottom of this.

Re: mpv is The Next Target and mpv Codeers Are Removing Hardware Acceleration

Reply #2 –
I randomly happened to read the mpv FAQ recently and remember this section.
Quote
I'm using vo=vaapi or vo=vdpau, but there are problems

First off: DO NOT USE THESE VOs. They are broken and old. There is no reason to use them. Just don't override the VO selection and use the default. Some users seem to think using these VOs is required for hardware decoding. This is not true. If you want hardware decoding, use --hwdec=auto, which may use some of these APIs for decoding. (On older Nvidia drivers, you may need --gpu-context=x11 in addition.)

These VOs use rather old video output APIs, which have been mostly abandoned by their vendors. In particular, vaapi is known to be thoroughly broken in most Intel drivers. It's not surprising to see major bugs and problems, and mpv can do nothing about it.

In some cases, using them might be justified for performance (they might use a hardware overlay, most often these are just emulated with shaders though).

If they are not lying (which I doubt is the case) then that might explain the various projects dropping support ?
hwdec=auto and let mpv figure it all out is my advice.

PS. One of our devs is an mpv dev so they may know more ?

Re: mpv is The Next Target and mpv Codeers Are Removing Hardware Acceleration

Reply #3 –
Uh no, nobody in mpv is removing hardware acceleration. I also have no idea what on earth you mean by ffmpeg or mesa removing vaapi because neither of those things happened. On the contrary, one of the big features of mpv 0.36 was adding vulkan hardware decoding support. Anyways, if gpu-next really somehow results in higher CPU usage/not working hardware decoding, then that would be a bug that should be reported upstream. Personally, I would suspect some kind of misconfiguration first. Anyways, it's worth noting that the hardware decoding paths are exactly the same between gpu and gpu-next, so there really shouldn't be any difference.

P.S. you should actually use hwdec=auto-safe over hwdec=auto nowadays. I'll update that part of the FAQ. Actually no, technically vdpau isn't part of the auto safe whitelist so I'll leave it alone.

Re: mpv is The Next Target and mpv Codeers Are Removing Hardware Acceleration

Reply #4 –
Quote from: sonar – on
On MS windows, it all just works.

I am really curious to see if you can top your previous outrageous contributions.

Because, as far as I know, your problems have their origin in the obscure garage that you [and many other people too] keep praising.

"Ceterum censeo M$ esse delendam"
"Wer alles kann, macht nichts richtig"

Artix USE="runit openrc slim openbox lxde gtk2 qt4 qt5 qt6 conky
-gtk3 -gtk4 -adwaita{cursors,themes,icons} -gnome3 -kde -plasma -wayland "

Re: mpv and Hardware Acceleration

Reply #5 –
Quote from: gripped – on
I randomly happened to read the mpv FAQ recently and remember this section.
Quote
I'm using vo=vaapi or vo=vdpau, but there are problems

First off: DO NOT USE THESE VOs. They are broken and old. There is no reason to use them. Just don't override the VO selection and use the default. Some users seem to think using these VOs is required for hardware decoding. This is not true. If you want hardware decoding, use --hwdec=auto, which may use some of these APIs for decoding. (On older Nvidia drivers, you may need --gpu-context=x11 in addition.)

These VOs use rather old video output APIs, which have been mostly abandoned by their vendors. In particular, vaapi is known to be thoroughly broken in most Intel drivers. It's not surprising to see major bugs and problems, and mpv can do nothing about it.

In some cases, using them might be justified for performance (they might use a hardware overlay, most often these are just emulated with shaders though).

If they are not lying (which I doubt is the case) then that might explain the various projects dropping support ?
hwdec=auto and let mpv figure it all out is my advice.

PS. One of our devs is an mpv dev so they may know more ?

Thank you for explanation. I always used mpv wiki and followed it, many times. Those 2 options are aliases for sharp scaling (as opposed to some linear, etc):
a) alias for scaling
b)alias  for color scaling
And both of them used Intel  HD graphics to do both of those scaling. Now they are using  software scaling and are "deprecated" for new "gpu-next".  Options are different now for "gpu-next" and they are using software instead of HW. I used them with vo=gpu as suggested for my HW and it works perfectly. Exactly as auto I believe. They are used for low resolution videos (just as "sinc" or "lanczos" for upscaling photos).

As for new vo=gpu-next. I tried it and its "incomplete" as regarding HW upscaling old videos. (just to 2x of small resolution, so 2x(640x480), so its viewable on 1080p screen ($ mpv --window-scale=2 or =1.5)

All from mpv wiki.

Re: mpv and Hardware Acceleration

Reply #6 –
Quote from: Dudemanguy – on
Uh no, nobody in mpv is removing hardware acceleration. I also have no idea what on earth you mean by ffmpeg or mesa removing vaapi because neither of those things happened. On the contrary, one of the big features of mpv 0.36 was adding vulkan hardware decoding support. Anyways, if gpu-next really somehow results in higher CPU usage/not working hardware decoding, then that would be a bug that should be reported upstream. Personally, I would suspect some kind of misconfiguration first. Anyways, it's worth noting that the hardware decoding paths are exactly the same between gpu and gpu-next, so there really shouldn't be any difference.

P.S. you should actually use hwdec=auto-safe over hwdec=auto nowadays. I'll update that part of the FAQ. Actually no, technically vdpau isn't part of the auto safe whitelist so I'll leave it alone.

Nobody mentioned this, but its from Debian 12 release notes. ffmpeg 5 removed vaapi, so Debian removed vaapi from VLC. No HW accel of avc1 etc on Intel on Debian. I had read it on Debian release notes. All distros based on Debian have this "bug".
As for mesa, I believe its the default now without vaapi, unless you put the flag specifically. This was first done on Fedora by IBM lawyes. It was a big news. Default is the king.