Hardware decoding on macOS results in chroma artifacts

inflation commented 5 years ago

mpv version and platform

mpv 0.29.1 Copyright © 2000-2018 mpv/MPlayer/mplayer2 projects
 built on Tue Nov  6 17:30:25 GMT 2018
ffmpeg library versions:
   libavutil       56.22.100
   libavcodec      58.35.100
   libavformat     58.20.100
   libswscale      5.3.100
   libavfilter     7.40.101
   libswresample   3.3.100
ffmpeg version: 4.1

Reproduction steps

Open a video with strong red objects and high contrast background. Then you can see chroma artifacts near the edges.

Expected behavior

up quicktime down mpv with software decoding Above one is from QuickTime and it also suffers the similar (but not same) issue, while the below one is correct using mpv with software decoding.

Actual behavior

mpv with videotoolbox I have already filed the bug to Apple. But from the results, mpv with hardware decoding does not look like flawed QuickTime either. While waiting for the response from Apple, I just want to make sure mpv or maybe ffmpeg does not make the issue worse.

I also tried to change cscale settings but it seemed not working.

Log file

https://0x0.st/sDVc.log

Sample files

For easy reproduction, try this file at 3:16: https://0x0.st/sDVT.mkv

ePirat commented 5 years ago

I can observe the same problem in VLC using Videotoolbox (in Software decoder mode as my hardware does not support decoding HEVC):

VLC has its own implementation of the Videotoolbox wrapper and does not use ffmpeg for it, so I would assume the issue is indeed with Videotoolbox. (Or the ffmpeg and VLC wrappers are both flawed in the same way)

Akemi commented 5 years ago

this is the first video where mpv's/ffmpeg's hwdec works but VLC's doesn't for me, weird.

anyway, correct me if i am wrong, videotoolbox returns pre-scaled chroma planes. so mpv's chroma scaling can't do much. the -copy version doesn't help either. what we see is basically very bad chroma scaling done in hardware(?) that is even worse than nearest neighbour.

it's also quite possible that quicktime uses a private API for hwdec and actually gets none pre-sacled chroma planes. for me it looks like classic nearest neighbour scaling.

mpv with cscale nearest. screenshot 2018-12-10 at 20 02 23

this is at least one of the reasons why we don't recommend hwdec. the quality can just suffer too much (hideous chroma aliasing and ringing). anyway if it's a bug, it's an ffmpeg and it should be reported to them.

kkanungo17 commented 5 years ago

So I tried this on my ancient Mac (mid-2010 macbook, c2d, geforce 320m). The output of mpv with software decoding and quicktime player seemed to match and look fine, but mpv with hwdec seems to be slightly worse.

mpv with hwdec: screen shot 2018-12-12 at 05 45 24 mpv with software decoding: Quicktime Player: screen shot 2018-12-12 at 05 53 13

Akemi commented 5 years ago

that old macbook supports hevc hw decoding? my mid 2010 macbook pro with a core i7 and a gt330m doesn't.

anyway the responsibility lies with ffmpeg here or the videotoolbox api. the only thing that could theoretically be done, is use reverse (down)-scaling (on the chroma planes) to undo the effect. in the case we would actually know what was used for scaling.

pxia commented 5 years ago

I don't know if this information is useful to anyone, but I just tested on iPad (using infuse app) which also uses videotoolbox, and it doesn't have this chroma artifact. (Looks like mpv software decoder).

Akemi commented 5 years ago

nothing uncommon. different hardware, different implementation of the hardware based decoder and possible differently returned frames/planes while retaining the same/similar higher level API.

inflation commented 5 years ago

Yeah, and some other users reported it only happened after High Sierra update. So Apple messed it up for sure.

Also, quoting some discussion from another forum:

这个就很诡异了。从log结果来看，硬解HEVC输出的是NV12，也就是YUV420p8： [ 1.553][cplayer] VO: [opengl-cb] 1920x1080 videotoolbox[nv12]

另外我还很在意这一句： [ 1.234][v][opengl-cb] Loaded extension GL_APPLE_rgb_422. 根据doc（https://www.khronos.org/registry/OpenGL/extensions/APPLE/APPLE_rgb_422.txt） APPLE_rgb_422实际上是YUV422p8，也就是已经做了部分chroma upscaling的结果。也就是过程中可能还有类似ffmpeg那样额外不必要转换。

He was saying that videotoolbox returned NV12 format pixel and mpv loaded GL_APPLE_rgb_422 extension, and suspecting some unnecessary conversion here.

Akemi commented 5 years ago

i believe GL_APPLE_rgb_422 was even used before and i am not quite sure that is related.

Akemi commented 5 years ago

just some additional info. i just removed all usage of GL_APPLE_rgb_422 (and related) within mpv and it doesn't load that extension any more. though the issue stays the same.

so it's just loading that extension but not using it. it's only there for compatibility for older hardware.

kkanungo17 commented 5 years ago

Mid 2010 macbooks don't have actual hardware decoding, though the videotoolbox api silently falls back to the apple provided hevc software decoder. That said, I really doubt apple would provide a software decoder that does stuff differently from actual hardware decoders.

Acerbicus commented 5 years ago

Movist 2 has no such problem in hardware mode.

Akemi commented 5 years ago

Movist is an easy-to-use and powerful movie player. You can choose QuickTime or FFmpeg as decoder

yeah, if it uses the quicktime decoder(?).

Acerbicus commented 5 years ago

Movist is an easy-to-use and powerful movie player. You can choose QuickTime or FFmpeg as decoder

yeah, if it uses the quicktime decoder(?).

No, it uses FFmpeg (hardware mode).

Movist

Iinna vs Movist

Akemi commented 5 years ago

i can't confirm this. just tried moviest 2.1.5 and i get the same artifacts.

Screenshot 2019-05-30 at 12 08 17

Acerbicus commented 5 years ago

i can't confirm this. just tried moviest 2.1.5 and i get the same artifacts.

Send me this sample files.

Akemi commented 5 years ago

it's the one from the OP (3:16). reuploaded it https://0x0.st/sDVT.mkv

i had to use "Hardware (Force)" in movist, otherwise it didn't use hardware decoding at all.

Acerbicus commented 5 years ago

Movist Pro - Hardware (Force)/macOS 10.14/iMac 27 5K 2017 (MNED2RU/A)

Movist Pro - Hardware (Force)

Akemi commented 5 years ago

now we are none the wiser.

could be that it silently falls back to software decoding. seems like movist doesn't have any kind of indicator what it actually uses, other than the difference in CPU usage that can be observed. could be difference in hardware.

since it doesn't work on my end, there is no point for me to look into it.

Acerbicus commented 5 years ago

could be that it silently falls back to software decoding

What is "Hardware (Force)" in video decode? To use the hardware video decode acceleration, the video file must be made to conform to the relevant format. Otherwise, hardware decode does not work although supported codec. Movist can force hardware decode through special handling to be used even in such cases. However, it is not always possible, and may cause abnormal behavior in some files.

If you have some trouble in "Hardware (Force)" mode, please change to "Software". You can change it while watching video via main menu and control panel. In the main menu, press the Option key on the video track menu item to display the submenu. In the control panel, click the video track icon to display the pop-up menu.

If it's occurred in too much files and you're not comfortable with it, set the video decode setting to "Hardware" in Preferences. It will work only for movie files that are made to conform to the relevant format. Please send the files via "Send Bug Report" to help us improve Movist.

http://cocoable.com/faqs.html

Akemi commented 5 years ago

i wouldn't blindly believe a faq. what i meant is, videotoolbox itself can fallback internally to software decoding apparently. it's always better to properly check.

Akemi commented 5 years ago

This issue is still present in both hardware decoding on and off.

then this would be a totally different issue and you should open another issue for that with all info provided.

wojciechbielecki commented 5 years ago

Hi, may I ask whether this issue has been reported to ffmpeg? I tried looking at the ffmpeg bug tracker but couldn't find anything that matched this issue.

The following screenshots were captured on the same frame, with IINA 1.0.4 Build 107 (mpv 0.29.1). The file is HDR HEVC encoded:

Hardware decoder: Auto: https://images2.imgbox.com/93/0d/5oLGmcKq_o.png
Hardware decoder: Disabled: https://images2.imgbox.com/33/2b/TFBQ7zIY_o.png

Akemi commented 5 years ago

as far as i know no.

tmm1 commented 5 years ago

Can someone summarize what the ffmpeg bug here is?

Akemi commented 5 years ago

can't say anything specific since i have no idea what videotoolbox actually outputs. for me it looks either like vt outputs prescaled chroma planes to the full resolution with like something like nearest neighbour (though it looks even worse), the planes are prescaled but assumed not to be and some kind of mismatch happens, and/or the chroma planes are kinda only 1/4 of the full resolution or 1/2 of the chroma resolution. seems like it also depends on the hardware.

anyway i re-uploaded the mentioned sample (artifacts at ~3:16). https://0x0.st/sDVT.mkv

here the extracted U and V planes of the screenshot:

lets use some less obvious one where one can still clearly see the problem on the chroma planes:

also as a small test, i downscaled the actual u plane to half the res and upscaled it to the full res with nearest neighbour and the result looks very similar to what we get with vt: