Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
aufkrawall opened this issue Aug 25, 2017 · 25 comments

Comments

Projects
None yet
6 participants
@aufkrawall
Copy link

commented Aug 25, 2017

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

This comment has been minimized.

Copy link
Member

commented Aug 25, 2017

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

@garoto

This comment has been minimized.

Copy link

commented Aug 25, 2017

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

@haasn

This comment has been minimized.

Copy link
Member

commented Aug 26, 2017

@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.

@wm4

This comment has been minimized.

Copy link
Contributor

commented Aug 26, 2017

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

@aufkrawall

This comment has been minimized.

Copy link
Author

commented Sep 10, 2017

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

This comment has been minimized.

Copy link
Member

commented Sep 10, 2017

Those two images look identical to me.

@aufkrawall

This comment has been minimized.

Copy link
Author

commented Sep 10, 2017

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

This comment has been minimized.

Copy link
Member

commented Sep 10, 2017

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

This comment has been minimized.

Copy link
Member

commented Sep 10, 2017

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

This comment has been minimized.

Copy link
Author

commented Sep 10, 2017

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

@haasn

This comment has been minimized.

Copy link
Member

commented Sep 10, 2017

And the other version?

@aufkrawall

This comment has been minimized.

Copy link
Author

commented Sep 10, 2017

@haasn

This comment has been minimized.

Copy link
Member

commented Sep 10, 2017

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

This comment has been minimized.

Copy link
Author

commented Sep 11, 2017

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

This comment has been minimized.

Copy link

commented Sep 11, 2017

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

@haasn

This comment has been minimized.

Copy link
Member

commented Sep 13, 2017

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

This comment has been minimized.

Copy link
Author

commented Sep 15, 2017

Linux + cuda also shows CL=unknown.

@haasn

This comment has been minimized.

Copy link
Member

commented Sep 15, 2017

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.

@wm4 wm4 closed this in 810990a Sep 19, 2017

@wm4

This comment has been minimized.

Copy link
Contributor

commented Sep 19, 2017

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

@aufkrawall

This comment has been minimized.

Copy link
Author

commented Sep 19, 2017

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

This comment has been minimized.

Copy link
Author

commented Sep 21, 2017

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?

@wm4

This comment has been minimized.

Copy link
Contributor

commented Sep 22, 2017

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

This comment has been minimized.

Copy link
Member

commented Sep 22, 2017

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?

@wm4

This comment has been minimized.

Copy link
Contributor

commented Sep 22, 2017

Yes, it could be set in that function.

wm4 pushed a commit that referenced this issue Oct 16, 2017

wm4
mp_image: select an explicit fallback for chroma location
If the chroma location is missing, vo_gpu will use centered chroma.
Select a better chroma location by default: normally, it will always be
MPEG video chroma location. If full levels are used, use JPEG chroma
location, because that sort of sounds like it could make sense as it
might coincide with JPEG being decoded.

See e.g. #4804.
@aufkrawall

This comment has been minimized.

Copy link
Author

commented Oct 16, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.