Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Wrong color while playing 4K HDR video with vaapi #4555
Comments
|
Looks like your hardware is trying to decode 10-bit as if it were 8-bit. Probably not an issue to do with mpv. |
|
Also might just be because it uses the legacy GLX rendering method. It's not supposed to be used. |
|
The problem is, only Intel supports EGL interop, legacy GLX is all there is for the radeonsi driver used here. @JulianLai try --vo=vaapi |
|
@Gusar321 |
vanvugt
commented
Jul 7, 2017
•
Edited 1 time
-
vanvugt
Jul 7, 2017
-
Jul 7, 2017
|
Confirmed the wrong colours when playing the Sony 4K Camp video. But they're only wrong in mpv. If I use gstreamer-vaapi (totem or gst-play-1.0) then everything is rendered just fine. Also strange that this discolouration only seems to happen with that one video. Not in any other test video I've seen... P.S. You might need Kaby Lake for that video. I have not seen anything older play it successfully. |
|
@vanvugt By “just fine” do you mean “decodes correctly” or do you mean “displays correctly”? HDR clips need special handling in the video output as well. Anyway, as for that particular clip, if it's just the one I really wouldn't worry about it. It's a very horrifically badly made clip, with lots of corrupt metadata (e.g. the mastering side-data contains invalid values), shit mastering, and shit quality. |
vanvugt
commented
Jul 7, 2017
|
The same video displays perfectly with gstreamer-vaapi. This is indeed a corner case, not worth much investigation right now. The discolouration is only with the one video when played with mpv --hwdec. And if it is 10-bit HEVC then I guess it also requires Kaby Lake. |
That's weird, according to the gstreamer source code it doesn't seem to support HDR? At least not according to https://github.com/GStreamer/gst-plugins-base/blob/master/gst-libs/gst/video/video-color.h#L71 |
pushed a commit
that referenced
this issue
Jul 7, 2017
vanvugt
commented
Jul 8, 2017
|
It appears that video is not HDR, or 10-bit, but more like 8-bit HEVC. I can tell because my Cherry Trail Atom can play the same video with full acceleration. And Cherry Trail can only play 8-bit HEVC (I confirmed it hits a brick wall if you try 10-bit). Same behaviour observed on the Atom too: Discolouration and corruption only occurs in mpv but not with gstreamer-vaapi. I think there were some interesting log messages too. I'll reproduce the issue again and attach logs later. It's not an important issue but still a little intriguing. :) |
|
@vanvugt There are two versions of the Sony Camp clip, the one named The former is 8-bit SDR, the latter is 10-bit HDR. Your |
vanvugt
commented
Jul 9, 2017
|
I'll try and find the original file again and verify. But given I have multiple machines exhibiting identical discolouration and stripes to that shown in the above screenshots, it appears to be the same bug. All three of those machines play the video smoothly through VAAPI with the same visible flaws, and only one of them is capable of 10-bit. In all cases the flaws are only visible in mpv and not in gstreamer-vaapi apps. So this is starting to sound like the file is named and possibly encoded incorrectly. It looks like VAAPI is decoding it correctly and just the wrong GL shader is used under mpv (causing some colour value distortion?). |
Which means all these machines are decoding the video as if it's 8bit, even the one which could decode it as 10bit.
Which leads me to believe that the gstreamer apps aren't actually using hardware decoding. There's no other explanation why they'd decode correctly even on machines without a 10bit hardware decoder.
No, it looks like gstreamer isn't actually using vaapi. What I see as bugs here is that mpv does hardware decoding of the clip even if the hardware isn't cabable of 10bit, and that the video is decoded as 8bit even when a 10bit decoder is available. But this may not necessarily be a mpv bug, could also be something in ffmpeg or even the radeonsi vaapi driver. |
No, it's a decoding error, caused by the hardware decoder trying to decode 10-bit content as 8-bit. Either: A) the hardware decoder advertises 10-bit support but fails to render it properly (driver bug) There was also the commit ae4c013 which disables the use of vaapi-over-GLX. Have you tried again since that commit? |
vanvugt
commented
Jul 9, 2017
|
You are suggesting something that's impossible: "No, it looks like gstreamer isn't actually using vaapi.". Because it's just a 2 watt Cherry Trail Atom chip and is playing 4K HEVC H.265 flawlessly smooth. I have a collection of 8-bit and 10-bit HEVC videos and the 10-bit ones simply don't play at all (VAAPI reports unsupported profile) on Cherry Trail and Braswell. All the 8-bit ones play smoothly. Furthermore, I know of no CPU that can play this video smoothly in software, let alone a 2W Atom chip, It only works when VAAPI works. Further evidence that Cherry Trail/View and Braswell only support 8-bit and not 10-bit: I am aware of what the log messages show. It just seems like VAAPI itself has correctly detected the video stream as 8-bit but mpv thinks it's 10-bit. That's why I think the file might be encoded incorrectly. So it fools mpv into using the wrong shader, but not gstreamer. |
vanvugt
commented
Jul 9, 2017
|
Also, the hardware decoder works. Because: |
vanvugt
commented
Jul 10, 2017
|
Here's my log from playing the video. The on-screen corruption is identical to the above screenshots, and identical regardless of which machine I use (same for Kaby Lake, Cherry Trail and Braswell laptops)... |
|
Well that log you posted is for playback of an 8-bit file. If it exhibits the same corruption as in your initial post, on all three machines, then there's a good chance that the bug has nothing to do with 10-bit vs 8-bit. |
|
@haasn: vanvugt is not the initial reporter, JulianLai is. It seems vanvugt wanted to confirm JulianLai's observations, but he has a different version of the video. @vanvugt: Please also get the 10bit HDR version of the video and test that one with both mpv and gstreamer-vaapi on your Kaby Lake machine (the other two won't be able to handle the clip anyway). Anyway, it does look like mpv screws up playing both versions for some reason, while gstreamer-vaapi handles at least the 8bit version ok. |
|
@Gusar321 Oh, my bad. This is why it's better to keep separate issues separate.. |
|
I can reproduce the original problem from @JulianLai on a Polaris 11 card here. It must be some sort of decoder issue with AMD/Mesa/libavcodec (consider that the boundaries of the eight slices are visible in the first screenshot). It also happens with ffmpeg using VAAPI decode directly; other H.265 Main10 files do decode fine, so it isn't a 10-bit problem generally but something about that file specifically. No idea about the issue from @vanvugt . The file decodes sensibly on Kaby Lake for me, both with VAAPI-EGL and VAAPI-copy (though I don't have any means to tell whether the colours are actually correct). |
vanvugt
commented
Jul 13, 2017
|
I can confirm Sony_4K_HDR_Camp.mp4 has the same problems under mpv. The corruption is very similar to the 8-bit version of the file, only slightly different. Furthermore, playing Sony_4K_HDR_Camp.mp4 in gst-play-1.0 or totem using gstreamer-vaapi exhibits no corruption at all. Although it's a bit dull (which seems to be true for all HDR videos when played on my 8-bit screen). |
|
Fixed for me by https://lists.freedesktop.org/archives/mesa-dev/2017-July/162896.html. (If anyone feels like building Mesa and could test that, please do!) @vanvugt I suspect you might have an old version of ffmpeg which suffers from the converse bug - like in Mesa, some code was copied from the VDPAU implementation without noticing that the scaling list ordering was different. This was fixed a while ago - please try an up to date ffmpeg (it is fine for me on Kaby Lake with the current version). |
|
Oh nice, so it was a driver bug all along? |
AndyFurniss
commented
Jul 16, 2017
•
Edited 1 time
-
AndyFurniss
Jul 16, 2017
-
Jul 16, 2017
|
So is this still needed? It regresses h264 radeonsi hwdec=vaapi --vo=opengl[-hq] for me. --vo=vaapi still works, but it seems a shame to loose something that worked and was better in the case of hq. OK so I can still use vdpau for 264 anyway, not so sure about whether that's a future proof option for 265 10bit as I don't have a card that will do that. commit ae4c013 snip |
|
You can still force it. But in general, just use vdpau with radeon. At least until they implement EGL interop. |
AndyFurniss
commented
Jul 16, 2017
|
OK, what command forces? |
Sounds an awful lot like it doesn't actually support HDR |
vanvugt
commented
Jul 17, 2017
|
Yes, that's correct. I don't consider the dull rendering of HDR to be a bug. That is unrelated to this bug so I should not have mentioned it. |
|
Fixed in Mesa by https://cgit.freedesktop.org/mesa/mesa/commit/?id=63dcfed81f011dae5ca68af3369433be28135415. If there is another similar issue here then please open a new bug with full reproduction instructions. |
JulianLai commentedJun 27, 2017
•
Edited 1 time
-
JulianLai
Jun 27, 2017
mpv version and platform
Log file
Sample files
Sony_4K_HDR_Camp