Mpv: Artifcats/glitching and slowness on videos (relating to HandBrake, h265 x265 encoder)

[Geroyuni]

mpv version and platform

mpv 0.29.1, Windows 10 Pro 1809 (Build 17763.475)

Reproduction steps

1. Get files encoded/compressed by HandBrake in h265 x265
Use the files I provided in _Sample files_, or, make your own. I used "Fast 1080p30" preset as base, modifying codec to H.265 (x265).

2. Open them and move randomly through the timeline

Expected behavior

No artifacts/glitching, slowness or any sort of weird behaviour, the same as in other players such as VLC and WMP.

Actual behavior

Artifacts/glitching and slowness, unlike in other players such as VLC and WMP. It's demonstrated in this video.

Log file

mpv -v (did I do this wrong/was I supposed to do something else? let me know if so)

Sample files

The files from the demonstration video are here in 7z (OG-Test2 removed for file size limit; any tests can be done with OG-Test1). OG- denotes original file before passing through handbrake.

[Akemi]

can't reproduce the glitches with the latest mpv and a more recent ffmpeg. i will reopen if you still have these problems with recent versions of both.

[mia-0]

You can get git snapshots here: https://repos.cirno.systems/mingw-w64:/publish/archives/

[Geroyuni]

Thanks for the link. Artifacts/glitching definitely not present in newer version, which is great news.

However the slowdowns still seem present, and it's a big difference compared to the original file or vlc's reproduction of the same file. Here's a video of that, let me know if this is still noteworthy as bug/issue and if I should do anything else / update main post.

[Akemi]

vlc could use hwdec in comparison to mpv, so try with hwdec=auto. otherwise it's expected that h265/hevc is significantly slower to decode than h264. there are also some other differences between vlc and mpv that could make seeking a bit slower in general.

also since you asked, your log file is useless if you don't make a log with the file loaded and your issue present in the log itself.

[Geroyuni]

That all makes sense. Changed it to auto and works really great. Why is it not default? (just curious)
Figured I was probably being dumb about the log, fortunately it wasn't needed after all
Thanks a lot

[Akemi]

quote from the man.

Most video filters will not work with hardware decoding as they are primarily implemented on the CPU.
...
Quality reduction with hardware decoding.

In theory, hardware decoding does not reduce video quality (at least for the codecs h264 and HEVC). However, due to restrictions in video output APIs, as well as bugs in the actual hardware decoders, there can be some loss, or even blatantly incorrect results.

In some cases, RGB conversion is forced, which means the RGB conversion is performed by the hardware decoding API, instead of the shaders used by --vo=gpu. This means certain colorspaces may not display correctly, and certain filtering (such as debanding) cannot be applied in an ideal way. This will also usually force the use of low quality chroma scalers instead of the one specified by --cscale. In other cases, hardware decoding can also reduce the bit depth of the decoded image, which can introduce banding or precision loss for 10-bit files.

besides that, for h264, hwdec could actually be slower than software decoding. bug in the software decoder can be easily fixed within ffmpeg. on the other hand, for h265 hwdec is quite helpful still since with most common hardware software decoding is still quite slow.