Madvr 4 Life (Help and Tips)

[Z2697]

That would be from resizing not dithering (or not only, but combined), somehow.
Verify with --video-unscaled=yes.

And there's something specific about "non standard" resolution.
Correction, it's alpha channel.

[huhn]

what scaler can add error with 0 as input?

[Z2697]

Just drop it.
You don't like mpv it's fine. Don't act like someone forced you to like it.
Maybe some will care, but I can speak for myself that now there's one less person care about your mpv/libplacebo problem.

[nevcairiel]

I looked over the dithering logic and the values it uses, and other then the special 4bit and below logic, which seems a bit weird, the dithering seems fine. If you see that many non 0 pixels my guess is that the values become inaccurate in another step, and dithering does what its designed to do, and preserves even fractional differences.

My own renderer with libplacebo can't be used with images, but I guess i can convert it into a black rgb video a bit later to see if i get any errant pixels. At least I can more closely control what it does exactly.

[huhn]

it really is the presence of an alpha channel. the scaler doesn't seem to matter what so ever. it also didn't matter when i checked y 103 to fullrange rgb 102.3 at native 1080p or UHD.

[Z2697]

I looked over the dithering logic and the values it uses, and other then the special 4bit and below logic, which seems a bit weird, the dithering seems fine. If you see that many non 0 pixels my guess is that the values become inaccurate in another step, and dithering does what its designed to do, and preserves even fractional differences.

My own renderer with libplacebo can't be used with images, but I guess i can convert it into a black rgb video a bit later to see if i get any errant pixels. At least I can more closely control what it does exactly.

It's the alpha channel, sure that's a problem. but I don't care, I don't watch videos half transparant.
If you convert it to RGB video it should be using like FFV1 or FFVHUFF to get the alpha. (ARGB/RGBA/BGRA/GBRA, so many choices!)
But LAVFilter don't pass alpha channel right?
You should just use mpv to test it.

[nevcairiel]

I generally ignore alpha in video as early as possible. There may be some uses for it, but none ever interested me.

[huhn]

to re test this i need to create a different type of test file i see.
while that alpha stuff is a bug the png or other alpha related source are rare.

that's typical again i step into that. if i used a video test pattern that wouldn't have happened.

my answer was written before i saw the alpha part.

only errors at 6 bit and more should matter. i see 1 bit only useful to test dither algorithm but they don't need to be perfect for that.

maybe a 16 bit image with 1 as value is something i can create and then i dither that to 8 bit that may does something similar as 4 bit or lower to test that.

isn't there a windows DS filter that creates an video from image?

[Z2697]

But why, you have FFmpeg lavfi color source, and RGB48 support.

Well, "color" assumes 8-bit RGB value, but you have "lut" to coerce it into existence.

[kasper93]

cause i can't proof anything. have an easy one:
dither-depth=1
dither-size-fruit=8

and just to be clear the issue isn't that there are white dots it's where they are.

also try dither-size-fruit=2 the result is "interesting".
edit: sorry i used the free attachment i will fix it sorry.
https://ibb.co/V0M7XZ49
https://ibb.co/6csqG4PV

they have been deleted mistakes have been made.

I don't need proof or you do diagnose the issue, I need coherent report with what you do to arrive at the wrong result. Not every issue is the same issue. When you generalize things it makes it hard to know what is going on, what is expected and how to reproduce the issue.

I don't have problem with fixing issues, but I don't want to randomly go on a forum thread about madVR, look inside, and see it's just "mpv bad' thread. And then trying to unwrap what is going on.

And even after trying to figure out, I can't, because images are removed, there are inconsistent claims and I don't even know if you output to PQ swapchain or SDR one.

I could go on and explain, why the lifted black may happen, and how it's below what you can see, unless you do `dither-depht=1`, which you don't. But I don't want to muddy the discussion, because I'm not sure what part of the problem is affecting you.

Correction, it's alpha channel.

Could you say what images and output did you compare to get this conclusion? I could reproduce lifted black, only in completely different scenario.

Also note guys, that `mpv image.jpg` will look different for each of you likely, mpv does infer display parameters, adapt to that the image. It depends on your configuration, both in system and mpv.

[tp4tissue]

@kasper93, huhn always talks like that, he's clearly autist spectrum and uses it as a defense mechanism, indifference to positive/negative attention.

No need to get angry everyone.:D

[huhn]

I don't need proof or you do diagnose the issue, I need coherent report with what you do to arrive at the wrong result. Not every issue is the same issue. When you generalize things it makes it hard to know what is going on, what is expected and how to reproduce the issue.

I don't have problem with fixing issues, but I don't want to randomly go on a forum thread about madVR, look inside, and see it's just "mpv bad' thread. And then trying to unwrap what is going on.

And even after trying to figure out, I can't, because images are removed, there are inconsistent claims and I don't even know if you output to PQ swapchain or SDR one.

I could go on and explain, why the lifted black may happen, and how it's below what you can see, unless you do `dither-depht=1`, which you don't. But I don't want to muddy the discussion, because I'm not sure what part of the problem is affecting you.



Could you say what images and output did you compare to get this conclusion? I could reproduce lifted black, only in completely different scenario.

Also note guys, that `mpv image.jpg` will look different for each of you likely, mpv does infer display parameters, adapt to that the image. It depends on your configuration, both in system and mpv.
i wrote it intentionally in a way to not blame it directly or absolute that it could be improved. no image has been removed they have just been placed as a link instead of attachment that used full resolution as preview.

there is more. https://github.com/mpv-player/mpv/issues/13468
i can't write an error report now i'm silenced problem solved?

was ACM an issue in 2024? so mpv has absolutely nothing to do with it? i don't know. i only remember that the RGB balance was wrong and the image had a to green tint similar to the other report also that my meter didn't like it what so ever.

i can tell you so much more broken stuff from madVR argyllcms 3D LUT been broken and produce massive discoloration under specific situations. madshi said it is a 3D LUT issue displaycal dev said it is a madVR issue. never fixed in any of them but a WTW/BTB clipping shader does fix it.

i know about VRR issues with mpv. it just send 25 even through 99.5% of all devices have a min fps of 48 so it is always using LFC while it could easily do fps*(max HZ /current FPS truncated down).
current result is 50-150 (guess cause it shows 144) and it is flickering like crazy which is a display issue. lfc is a marketing lie most people know that.

BTW. depending on what that actually means and how far that goes. "Also note guys, that mpv image.jpg` will look different for each of you likely, mpv does infer display parameters, adapt to that the image. It depends on your configuration, both in system and mpv"
calibration as a concept would be dead. pgen exists to bypass stuff like that. if it reads HDR and SDR is played and instead of using the OS/driver SDR -> HDR conversation it is doing it on it's own as this is needed on windows that is a different story.

[Z2697]

Could you say what images and output did you compare to get this conclusion? I could reproduce lifted black, only in completely different scenario.

ffmpeg -f lavfi -i color=0x000000,format=rgb{a,24} -frames 1 test.png

mpv test.png --dither-depth=1 --no-config --target-colorspace-hint=no

Then make scaling active by resizing window or anything.

(Yes it's very unlikely to happen in real life scenario)

[kasper93]

i wrote it intentionally in a way to not blame it directly or absolute that it could be improved. no image has been removed they have just been placed as a link instead of attachment that used full resolution as preview.

The links didn't work for me at the time. All good.


there is more. https://github.com/mpv-player/mpv/issues/13468
i can't write an error report now i'm silenced problem solved?


You shouldn't be blocked. I think you might have been at some point, other org members are not very patient. I may be sometimes abrasive, but I generally don't mean bad and always try to get to the bottom of things.


was ACM an issue in 2024? so mpv has absolutely nothing to do with it? i don't know. i only remember that the RGB balance was wrong and the image had a to green tint similar to the other report also that my meter didn't like it what so ever.

Screenshots are not the best way to evaluate quality. Because they go through, unrealistic pipeline, especially in gpu-next. It renders to rgba64 and then converts it to target image with swscale or zimg. Either way, I can look into this. Those however are corner cases and not real playback issues.


i know about VRR issues with mpv. it just send 25 even through 99.5% of all devices have a min fps of 48 so it is always using LFC while it could easily do fps*(max HZ /current FPS truncated down).
current result is 50-150 (guess cause it shows 144) and it is flickering like crazy which is a display issue. lfc is a marketing lie most people know that. VRR is not supported. Disable it for mpv. Use `--video-sync=display-resample` for sync to vsync. IIRC there are workarounds for VRR, like using different swap interval. EDIT: you can `--vf=fps=144` to output at specific rate.


BTW. depending on what that actually means and how far that goes. "Also note guys, that mpv image.jpg` will look different for each of you likely, mpv does infer display parameters, adapt to that the image. It depends on your configuration, both in system and mpv"
calibration as a concept would be dead. pgen exists to bypass stuff like that. if it reads HDR and SDR is played and instead of using the OS/driver SDR -> HDR conversation it is doing it on it's own as this is needed on windows that is a different story.
If your display is calibrated to a target that doesn't match EDID, you have to specify this target using mpv options. Same as in madVR you have to select "display is already calibrated ..." option. Additionally nowadays displays are factory calibrated, with reasonable results, so targeting the luminance and gamut that they report as native is genially good for 99% of users. Also you can use ICC profile in mpv or 3dlut.

ffmpeg -f lavfi -i color=0x000000,format=rgb{a,24} -frames 1 test.png

mpv test.png --dither-depth=1 --no-config --target-colorspace-hint=no

Then make scaling active by resizing window or anything.

(Yes it's very unlikely to happen in real life scenario)

Thanks, I see it. Generally this all stems form the fact that internal representation is absolute linear in libplacebo, so SDR input is black lifted there and then reduced back down to 0, but if you have some processing that adds noise above black it may not round-trip. I can look at this specific case, but again this isn't that common scenario.

[huhn]

Screenshots are not the best way to evaluate quality. Because they go through, unrealistic pipeline, especially in gpu-next. It renders to rgba64 and then converts it to target image with swscale or zimg. Either way, I can look into this. Those however are corner cases and not real playback issues.
i use alt+print do they also bypass the normal pipeline?
VRR is not supported. Disable it for mpv. Use `--video-sync=display-resample` for sync to vsync. IIRC there are workarounds for VRR, like using different swap interval. EDIT: you can `--vf=fps=144` to output at specific rate.
if it is not supported then it doesn't need to work. i only remember that it triggered automatically there was even an option to avoid it. it's currently killed using EDID overrides so i do not remember the option.

just for reference i needed to playaround with nvidia inspector mpc-hc to allow vrr. i also needed hack the exe so nvidia wouldn't know this is mpc-hc. mpv is not driver blocked.
If your display is calibrated to a target that doesn't match EDID, you have to specify this target using mpv options. Same as in madVR you have to select "display is already calibrated ..." option. Additionally nowadays displays are factory calibrated, with reasonable results, so targeting the luminance and gamut that they report as native is genially good for 99% of users. Also you can use ICC profile in mpv or 3dlut.

that's madVR specific but you have to do nothing. madVR assumes bt709 and may mess up bt 601 but that's it also assumes a gamma of 2.2. the assumption of 2.2 is up to this day an inconvenience that can not be easily over come people wanted that to be 2.4 over and over again.

while screen are out of the box much better these days they are still very problematic.
that's why ACM is so funny. yes my S90C is supposedly "reference" (not my words) out of the box if you ignore gamma but with ACM it is broken cause the edid has most likely native gamut information in it or worse... so if screen are calibrated these days you shouldn't trust edid or what ever. just saying.
Thanks, I see it. Generally this all stems form the fact that internal representation is absolute linear in libplacebo, so SDR input is black lifted there and then reduced back down to 0, but if you have some processing that adds noise above black it may not round-trip. I can look at this specific case, but again this isn't that common scenario.

i took the image striped the alpha channel und redid the test. it is black now as it should be. it is really the alpha channel. you also need to scale but the alpha channel is the common nominator. making the risen black an insanely rare issue. i only wanted to show the grid BTW.

there is still maybe an issue. it targeted 0.03 as a pixel value at 8 7 and 6 bit meaning 6 bit is not gamma corrected to get a similar bright image the value should be lower at lower bit deep(close to black at least) to avg to something lower then 0.03 that has a similar brightness as 8 bit 0.03. but i need to trigger that without an alpha channel cause who knows what is really happening.

[DragonQ]

By the way, while trying to make my own 1080p SDR versions of the 2160p HLG footy highlights, it seems that using "zscale=tin=arib-std-b67" produces horrible results (kind of similar to the officially provided "1080p" SDR stream but with more intense colours, which might be tweakable). Using libplacebo tonemapping produces very similar results to the MPC Video Renderer, which looks far better overall (IMO at least).

[Z2697]

By the way, while trying to make my own 1080p SDR versions of the 2160p HLG footy highlights, it seems that using "zscale=tin=arib-std-b67" produces horrible results (kind of similar to the officially provided "1080p" SDR stream but with more intense colours, which might be tweakable). Using libplacebo tonemapping produces very similar results to the MPC Video Renderer, which looks far better overall (IMO at least).

For that "naive" version of conversion, you can raise the npl, default is 100 (probably).
*it will cause the resulting image to be darker overall, but can avoid clipping in high brightness.

But yeah libplacebo should be the go-to choice of tonemapping filter in FFmpeg and Synth's.

[DragonQ]

For that "naive" version of conversion, you can raise the npl, default is 100 (probably).
*it will cause the resulting image to be darker overall, but can avoid clipping in high brightness.

But yeah libplacebo should be the go-to choice of tonemapping filter in FFmpeg and Synth's.
It does surprise me that the SDR "layer" of HLG looks so rubbish when I thought that was the entire point of HLG in the first place (to be backwards compatible with SDR)!

[Columbo]

It does surprise me that the SDR "layer" of HLG looks so rubbish when I thought that was the entire point of HLG in the first place (to be backwards compatible with SDR)! Ditto +1

My TV switches to HDR HLG to play a stream but when I invoke menus everything is flat and gray. Maybe it's a different issue entirely?!