Dithering causing framedrops for an 8-bit video on an 8-bit display.

[kkanungo17]

Important Information

mpv git-2020-04-17-a09c769 (from McMahon's repo)
Pop OS 20.04
GNOME 3.36
Intel Iris Plus G4 (ICL GT1.5)
Vulkan Instance Version: 1.2.131

Reproduction steps

mpv "https://www.youtube.com/watch?v=MSNvXyuuIvg" --no-config --dither-depth=auto --dither=error-diffusion --error-diffusion=burkes

Expected behavior

No framedrops, because even if burkes were too intensive it's an 8-bit video, hence there shouldn't be any dithering happening. Apologies if I'm just ignorant and dithering should be always active.

Actual behavior

Framedrops, which don't happen when I use fruit or sierra-lite, though I'm not sure if dithering is active for these two.

Log file

http://0x0.st/i0qV.txt

[Jules-A]

I was getting something like a 60% performance hit from dithering on similar content and display using Vulkan but on Windows 10 using an RX570.

EDIT: That was using error diffusion.

[Akemi]

you still have to convert from yuv420 to RGB and that's where you have to dither too.

[edit]
why did you mention vulkan, you are using opengl in your log? is this actually about the dithering from 8bit to 8bit, which is expected, or about the high performance hit? for the former i think we can close this issue, for the latter i believe it's expected that this is quite compute intensive.

[kkanungo17]

It was about the dithering from 8-bit to 8-bit, so I'm closing the issue, though just for curiosity, why would YUV420 to RGB need dithering? Does the chroma channel actually have less color depth too? And would there be any actual observable difference between fruit and error-diffusion?

BTW, the guy with the Vulkan issue is someone else.

[Akemi]

it's because you have to convert from one colour format to another. one has a luma (y)(brightness) and two chroma planes (u,v)(color) and rgb has a red, green and blue channel. even though all those planes and channels have a range from 0 to 255 you can't just map them 1:1, you have to convert them. to be more specific the chroma plane's neutral is at 128 (grey) and not 0. so you either round, truncate or dither for that conversion.

as an encoder, yes there is definitely a difference, but you have to look for therm actively. on playback you will hardly see any. best to just try both and see what looks better.

no i i really mean you and not jules. your initial post mentioned "Vulkan Instance Version: 1.2.131" under important information, that's why i am asking.

[kkanungo17]

Ah okay, I forgot about that. I just added Vulkan information because I use that normally, but figured it would be better to give a log with —no-config just to isolate the parameter better.

As for quality, I didn’t notice any difference even for 10-bit h264 anime raws on my 1080p 21.5 inch monitor, though I’m not sure what I should be looking for. Apparently error-diffusion gives sharper edges, but lines looked equally sharp for both cases, so I decided to stick with fruit.

One last question, what advantage does temporal dithering offer?

[Akemi]

either to spread the error not (just) spatial but also temporal or to 'simulate' more colours just temporal. see the image below.

[v-fox]

As for quality, I didn’t notice any difference even for 10-bit h264 anime raws on my 1080p 21.5 inch monitor, though I’m not sure what I should be looking for. Apparently error-diffusion gives sharper edges, but lines looked equally sharp for both cases, so I decided to stick with fruit.

Maybe because mpv uses subtler parameters or that testing scenes weren't very presenting ? I've been testing dithering algorithms of ditherting stage (see algorithm list in doc/fmtconv.html) of my motion-interpolation mpv script (still trying to find good settings that are balanced between aggressiveness and artifacts). I ended up with "Void and cluster halftone dithering" with rotation but without static noise. I think it works quite well for preserving gradients (even if you have 8-bit display and 8-bit source, you convert the format for all those processing stages) with aggressive debanding via F3KDb stage and motion-based degraining, especially on noisy analogue film recordings and/or low-res files encoded with blocky pre-h264 codecs. #8137 might allow bringing all that directly into mpv.

So I aimed to use something similar as mpv's own default and enabled error-diffusion=sierra-2 (fmtconv recommends that) "just to make sure" but haven't tested it like that, just noticed that sierra-3 doesn't work on RX580 GPU due to insufficient "shared memory".

either to spread the error not (just) spatial but also temporal or to 'simulate' more colours just temporal. see the image below.

Is the one below "temporal" ? Looks quite glitchy on my slow VA display. I keep it disabled in mpv due to warning in manual, even though I haven't tested it enough to blame. But in manual it's explained as "changing the orientation of the tiled dithering matrix" which sounds like rotation parameter in fmtconv and that one works quite well.

[Akemi]

yeah, that's an example of temporal dithering.