Regression since mpv 0.25: wrong colors with hardware decoding on Windows

[aufkrawall]

mpv version and platform

0.24: last version not affected
0.25 - 0.26: affected
build by shinchiro from 2017-08-19: affected
Windows 10 x64 Creators Update

Reproduction steps

Play a cartoon video with distinguishable colors and compare software decoding vs. any hardware decoding on Windows

Expected behavior

Colors/image quality of hardware decoding copy mode vs. software decoding should be without difference.

Actual behavior

Colors with DXVA2-copy look wrong.

0.26 software decoding:
https://abload.de/img/mpvsoftwarecmsuw.png

0.24 dxva2-copyback:
https://abload.de/img/mpvoldh6shl.png

0.26 dxva2-copyback:
https://abload.de/img/mpvdxva2copy44sx1.png

Log file

http://sprunge.us/PeDP

Sample files

http://www87.zippyshare.com/v/hzYy0T0D/file.html

[wiiaboo]

That file host is really fucking annoying, btw.
Same with d3d11va-copy here.

[garoto]

--vf=format=colormatrix=bt.709 seems to display proper colors.

[haasn]

@garoto More likely, that makes them all look wrong.

Sounds like there was a regression in the DXVA2 color matrix loading code in between 0.24 and 0.26.

[ghost]

I don't think there's anything like "DXVA2 color matrix loading code".

[aufkrawall]

Probably every video format is affected, I could also find the problem with other videos.

dxva2-copy
mpv 0.24 (looks the same as software decoding):
https://abload.de/img/oldjts40.png

current (looks different to software decoding):
https://abload.de/img/newzrscc.png

Sample:
http://filehorst.de/d/cvmdboJz
(in this sample you can btw. also see that angle shows more banding than wgl/dxinterop, independent of hardware decoding)

Would be nice if the issue with damaged chroma channel with any hardware decoding could be fixed for next release. :)

[haasn]

Those two images look identical to me.

[aufkrawall]

You can see that the red arrow head has more distinct dark outlinings with recent mpv versions when using hardware decoding, which is a sign of quality degradation (undesired blur).

[haasn]

Oh, yes - I see it. Although this sample doesn't seem to have the BT.601/BT.709 issue you were talking about previously.

[haasn]

Is it possible that this issue is just caused by misaligned chroma? If the colormatrix tag doesn't survive the abstraction layers, then maybe the chroma position tag doesn't either. A verbose log for both would help.

[aufkrawall]

Hope this helps:
http://sprunge.us/aOiA

[haasn]

And the other version?

[aufkrawall]

http://sprunge.us/KABY

[haasn]

Thought so. old mpv:

[ 1.243][v][vf] [in] 1280x720 nv12 bt.709/bt.709/bt.1886/limited CL=mpeg2/4/h264
new mpv:
[ 1.691][v][vf] [in] 1280x720 nv12 bt.709/bt.709/bt.1886/limited SP=1.000000 CL=unknown

It goes from CL=mpeg2/4/h264 to CL=unknown, consistent with the result (the chroma plane seems misaligned based on the screenshot). This is probably the same issue as the other one.

Some metadata does not survive.

[aufkrawall]

I just tried a completely different file (MP4 container, 4k H.264 59.95fps) and it shows the same behavior.
So it seems the metadata detection is broken in general with hardware decoding and at least H.264 in the current mpv versions.

[daed-alus]

i see the same also for some hevc files
mpv .25/.26 also refuse to hardware decode some files that work with .24

[haasn]

Is it possible this is an ffmpeg bug? I'm not entirely sure where that metadata comes from, whether it's mpv or ffmpeg.

[aufkrawall]

Linux + cuda also shows CL=unknown.

[haasn]

Sounds like some pretty significant regression in whatever component is responsible for loading color space params. If it also affects cuda then I may be able to bisect it when I'm back on an nvidia GPU.

[ghost]

cuda probably doesn't export this field in the first place.

[aufkrawall]

I gave mpv 0.27.0-13-ga4de782272 a try:
Cuda does indeed always show CL=unknown, while VDPAU detects it properly for H.264.

So cuda has a quality drawback in general?

[aufkrawall]

To answer the question by myself: Yes, it apparently does. There is no great distortion going on, but the chroma channel gets slightly shifted by a pixel or a few vs. software decoding or vdpau.
Another case of unfixable garbage by Nvidia?

[ghost]

Unknown whether cuvid's API can export it, but ffmpeg's wrapper certainly doesn't.

We should probably select a better fallback for this. Ideas?

[haasn]

If we could figure out a way of distinguishing between jpeg and non-jpeg in guess_csp would could probably just set the default based on that and get it right 95% of the time?

[ghost]

Yes, it could be set in that function.

[aufkrawall]

Thank you, wm4! I can't recognize a difference to software decoding now.
Also thx for fixing zerocopy cuda decoding on Windows! Really not required anymore as soon as there is ra-d3d11, but it still can be interesting for comparing performance or troubleshooting.