madVR - high quality video renderer (GPU assisted)

[thighhighs]

Originally Posted by flossy_cake

Take some comparison screenshots on the same frame then zoom in like 400% nearest neighbour to see what's going on with the pixels.

I'm not sure, I would like to know the opinion of others. For tests, I prefer to look from a normal distance. This is the only way I noticed how dramatically SSIM2D changes the overall look. Also, this is the only way I've noticed that 1D100 makes film grain more visible to my eyes. Even when the Bicubic150 and 2D are sharper, they don't have this problem, only the SSIM1D100 + no-AB has this problem.

Originally Posted by flossy_cake

I find the debloat has quite a softening effect when used with the sharpeners.

The same goes for downscaling. AB can help or just reduce the sharpness...
A small example. SSIM2D100 + AB100 looks good in most cases and is much better than Bicubic150 or 1D. But in some cases it looks blurry.
https://imgsli.com/MTQ3OTU5
In this scene from The Hobbit, Bicubic150 is preferable to my eyes. That's why I don't like the combination of 2D with AB above 75%.
What do others think? What combination of SSIM1D/2D and AB are you using? Is any AB required for SSIM1D? What do you think?

[Sunspark]

kopija: You should see if your monitor can do 23.976/24/25 refresh rates. Mine is able to on the HDMI input. If it is able to, then you never need to use smooth motion, etc.

[ryrynz]

Originally Posted by thighhighs

What do others think? What combination of SSIM1D/2D and AB are you using? Is any AB required for SSIM1D? What do you think?

I don't downscale any more as I have a 4K set, but 2D was quite superior to 1D. After my initial review of AB I decided I didn't find it useful, better imo to just reduce the sharpness of the display, but it all depends.

[flossy_cake]

Originally Posted by thighhighs

1D100 makes film grain more visible to my eyes.

The "enhance detail" sharpener kind of enhances that too, along with texture details like wood grain will look more detailed. But the downside is it also enhances compression artefacts, so I don't use a value more than about 0.5 for compressy SD and about 1.0 for a very high quality DVD remux.

I'm quite happy with Lanczos for scaling and then using sharpeners if the source is soft. To me that makes more sense to do the sharpening separately as it gives me more control over the type of sharpening for the source (using profiles for convenience). Whereas I'm not sure how 1D100 might react with certain source types so I'd have to do a lot of trial and error.

I'm not really seeing much meaningful difference in your Hobbit comparison. Small differences, but nothing that would cause me to pick one over the other. Maybe I need to look under better lighting.

Originally Posted by kopija

Greetings,
I intended to buy a Freesync monitor thinking that would remove need for smoothmotion/resolution autochange/custom resolution workarounds for eliminating judder.
But now I feel like I stepped into a minefield after doing some research.
First, Madshi saying MadVR does not support Freesync, then numerous posts saying it works.
It also supposedly works with major video players, (including Windows Movie Player!)
I really like Madvr black bar removal feature.
Is there any way to make Madvr work with Freesync?
I originally intended to buy 1080p 75Hz Freesync monitor, thinking that it would auto-switch to 72/60/50Hz and eliminate need for abovementioned workarounds.
Can Freesync do that? Are there any known downsides in such a scenario?
I know that 144Hz monitor running fixed 120Hz would be ideal for 24/30p, but it is out of my price range.
Thanks

I discussed that with Madshi some years ago and was begging him to officially support it when I first got my gsync monitor. As far as I'm aware there were no lines of code in MadVR written to facilitate gsync/freesync, but I was able to get it working in full screen mode on my Acer XB271HU (monitor's own gsync fps overlay in top right corner would match the content fps). But it had nothing to do with MadVR settings, it was entirely up to the DirectX version, being in the right full screen mode, and selecting the right NVidia Control Panel settings to make it work. I wouldn't rely on it working correctly or anything, but it probably would work in a certain configuration as long as the driver knows you are in full screen graphics mode or whatever the driver requires for freesync/gsync to become active.

[huhn]

Originally Posted by flossy_cake

I tried to tolerate the combed frames for those sequences but they are bothersome to me. NVidia/AMD deint is "video mode" and lose half res on movement, so I didn't want that either

but they are full res when working. that's why they are so good mixed content not perfect at all but good.

Originally Posted by kopija

Greetings,
I intended to buy a Freesync monitor thinking that would remove need for smoothmotion/resolution autochange/custom resolution workarounds for eliminating judder.
But now I feel like I stepped into a minefield after doing some research.
First, Madshi saying MadVR does not support Freesync, then numerous posts saying it works.
It also supposedly works with major video players, (including Windows Movie Player!)
I really like Madvr black bar removal feature.
Is there any way to make Madvr work with Freesync?
I originally intended to buy 1080p 75Hz Freesync monitor, thinking that it would auto-switch to 72/60/50Hz and eliminate need for abovementioned workarounds.
Can Freesync do that? Are there any known downsides in such a scenario?
I know that 144Hz monitor running fixed 120Hz would be ideal for 24/30p, but it is out of my price range.
Thanks

video is different from games.
you don't want to show the frame as fast as possible you want to show it for a very exact time .

is it possibile to make VRR work for video yes absolutely but that's unlikely to happen with madVR taking current development.
even HDMI has VFR for video now.

BTW.75 hz freesync devices are a pretty much fake usually having a range of 48-75 hz to make freesync work making it useless. low end devices are not rarely utterly broken too.
even freesync on LG OLED TVS is objectively broken and they are not cheap.

[Sunspark]

flossy, I have an mkv that is a bt.601/pal/50 fps from a dvd. It's poor quality and the original source is from decades ago.

Resolution is 720x576. I decided to set the display resolution to 720x576 and just let the monitor upscale the image to the screen dimensions which is the same process I follow for 1080p and it works well as madvr is only handling the chroma in that case.

However, what I am seeing here is that there still needs to be some image scaling in the x dimension because of the whole square vs rectangular pixel aspect ratio. If I select square, it will turn off madvr scaling but it will squish in the sides a little. If I leave it on default/4:3 it will look more normal, but then x dimension scaling comes into play..

What image upscaling algo are you using in the situation where you are only scaling in X and only for the pixel not a different resolution? Catmull-rom looks ok, and looking at the formula the b value is 0, so it's probably a good choice.. wonder if there's a better choice?

PS. Have you tried your bt.601/PAL DVDs in VLC? I'm looking at the mkv in VLC and the colours and gamma are different from how madvr is doing it--richer and not as washed out. Interesting.. twiddling about with the VLC renderer choices, selecting opengl or d3d9 makes it washed out, but selecting d3d11 or auto makes it darker and richer like how they should look.

[kopija]

Originally Posted by huhn

BTW.75 hz freesync devices are a pretty much fake usually having a range of 48-75 hz to make freesync work making it useless. low end devices are not rarely utterly broken too.
even freesync on LG OLED TVS is objectively broken and they are not cheap.

So the best way to go about judder elimination issue would be to buy monitor with 48-75Hz range and use "switch to matching display mode" in madVR for 24/25/30fps?

Also, there is this new thing called VESA MediaSync. It claims its main purpose is elimination of 3:2 pulldown.
Gimmick or gamechanger?

[nevcairiel]

MediaSync is not a new feature, just a standard set of tests that displays can be certified against, which is far more lenient then the gaming tests.

That does not change the situation that video presentation APIs on Windows are not designed to work with what we need for video - exact presentation at a pre-determined time.

[huhn]

sleep time the render call and pray that it works :-)

Originally Posted by kopija

So the best way to go about judder elimination issue would be to buy monitor with 48-75Hz range and use "switch to matching display mode" in madVR for 24/25/30fps?

Also, there is this new thing called VESA MediaSync. It claims its main purpose is elimination of 3:2 pulldown.
Gimmick or gamechanger?

LG OLED are freesync premium and gsync certified.
so you can get the claim on most devices.

[flossy_cake]

Originally Posted by Sunspark

flossy, I have an mkv that is a bt.601/pal/50 fps from a dvd. It's poor quality and the original source is from decades ago.

Resolution is 720x576. I decided to set the display resolution to 720x576 and just let the monitor upscale the image to the screen dimensions which is the same process I follow for 1080p and it works well as madvr is only handling the chroma in that case.

However, what I am seeing here is that there still needs to be some image scaling in the x dimension because of the whole square vs rectangular pixel aspect ratio. If I select square, it will turn off madvr scaling but it will squish in the sides a little. If I leave it on default/4:3 it will look more normal, but then x dimension scaling comes into play..

What image upscaling algo are you using in the situation where you are only scaling in X and only for the pixel not a different resolution? Catmull-rom looks ok, and looking at the formula the b value is 0, so it's probably a good choice.. wonder if there's a better choice?

PS. Have you tried your bt.601/PAL DVDs in VLC? I'm looking at the mkv in VLC and the colours and gamma are different from how madvr is doing it--richer and not as washed out. Interesting.. twiddling about with the VLC renderer choices, selecting opengl or d3d9 makes it washed out, but selecting d3d11 or auto makes it darker and richer like how they should look.

Can you send the file so I can check it out? I need to see what MadVR chooses for aspect ratio, matrix, primaries & limited range on its debug screen. It will also say whether it's guessing or getting that info from upstream decoder.

If it's a straight MPEG2 remux of a 4:3 DVD then debug screen should say 4:3, BT.601, EBU/PAL, limited range. If it was transcoded by someone else, then whatever software they used could have fudged something, depends how they encoded it.

I reckon it might be slightly safer to output square pixels over HDMI as I know the math MadVR uses is good on that. SD signals over HDMI have been dodgy for me in the past. If the show is 4:3 then you don't want to be pillarboxing that in the middle of 576p as the active pixel area will be only 540 wide which is lower than the source. The chroma shouldn't have issues as long as the final output to TV is 4:4:4 and therefore avoiding multiple 4:2:0 -> 4:4:4 conversions.

I'm satisfied with Lanczos scaling for everything, except chroma I use bicubic old because it happens to smooth out chroma artefacts in any sources which have such issues. But in a double blind test on a normal quality source I can't really tell any diff. If I pause on a scene & Ctrl+Alt+Shift+F12 to Cb/Cr channel and flick between chroma algos on SD source then yeah I can really see a lot of diff.

[Sunspark]

The reason I have done the png screenshots like this is because for whatever reason, if I take a screenshot with vlc it has the gamma/colour different than when it's in the player so they couldn't be used. This is just to show the difference in the players during playback side-by-side.

Usually I use overlay mode, but switched to windowed so I could capture the image.

Average rendering time can be ignored, it's only high because it's paused.

[flossy_cake]

Yes I see what you mean - VLC is rendering with a higher gamma it seems.

Check what settings you've got under MadVR's "devices > monitor > color & gamma"

I'm not familiar with VLC but maybe it assumes by default that monitor gamma is 2.2 and SDR content is mastered at 2.4, therefore applying a +0.2 gamma shift by default - are there any settings in VLC which relate to this?

If I take your madvr screenshot and darken gamma by 0.2 in photoshop it appears quite close to the VLC one (animated png):



So basically if your monitor's gamma is 2.4 then VLC is too dark (it will be giving you about 2.6).

If your monitor's gamma is 2.2 then VLC is roughly correct, but only on the assumption that most content - especially of that era of television - would have been mastered on 2.4 monitor.

VLC's behaviour can be reproduced with madvr's color & gamma settings if you desire. Just keep in mind that room lighting affects perceived gamma due to "simultaneous contrast" effect - in a daylit room 2.2 can look similar to 2.4 in a dim surround.

[x7007]

remind me again how do we get Dolby Vision? which player and codec do I need?

[Sunspark]

Yes I see what you mean - VLC is rendering with a higher gamma it seems.

More than that.. the colours themselves are different.. if you look at the red and blue in the first row, I guess similar to the same issue you had with Family Guy, except it doesn't have the blue cast. Unless the different shade of red, etc. is due only to gamma? Might be it, more below.

Check what settings you've got under MadVR's "devices > monitor > color & gamma"

Everything is at 0, and enable gamma processing is unchecked.

I'm not familiar with VLC but maybe it assumes by default that monitor gamma is 2.2 and SDR content is mastered at 2.4, therefore applying a +0.2 gamma shift by default - are there any settings in VLC which relate to this?

No idea, but what I have observed is that there is a choice of different renderers in VLC.. d3d11, d3d9, opengl, etc. d3d9 & opengl renderers do the washed-out effect but the d3d11 one doesn't. Not sure why there is a difference in presentation with d3d11.

So basically if your monitor's gamma is 2.4 then VLC is too dark (it will be giving you about 2.6).

It's actually set to "Mac Gamma" in the monitor settings instead of PC because I found PC to be too dark. Probably would be better if it was calibrated, but Mac Gamma 1.8 (maybe up to 2.0?, not sure how accurate it is) looks better generally especially during the day.

If your monitor's gamma is 2.2 then VLC is roughly correct, but only on the assumption that most content - especially of that era of television - would have been mastered on 2.4 monitor.

Well, that is interesting to contemplate.. since you were talking about bt.601 etc. recently.. so the question then becomes, why doesn't madvr adjust? Unless it's simply just that public releases stopped before it could be addressed?

VLC's behaviour can be reproduced with madvr's color & gamma settings if you desire. Just keep in mind that room lighting affects perceived gamma due to "simultaneous contrast" effect - in a daylit room 2.2 can look similar to 2.4 in a dim surround.

I turned on enable gamma processing to see, and 2.6/pure power curve looks pretty similar, but could stand to be a bit darker still, 2.7 or more perhaps but it doesn't go past 2.6 as an option.

I know what you mean about adjusting room light affecting perception, I do that all the time to make the picture have more depth, but the thing is, adjusting the lighting isn't going to at-all fix the washed out gamma issue.. if the room has all the lights off, or turned up high, it's still going to be washed, I'm still going to see the macro-blocks on dark scenes, etc. So it actually does need to be right when it is processed.

I don't know what the issue is, if it's the file, if it's madvr, or if it's something else like vlc's d3d11 renderer being bugged and just happened to coincide with being correct for this file? But one thing I do know, this odd gamma issue with bt.601 doesn't happen really with bt.709. Just now I threw up a different file and compared them (with enable gamma turned off). On a scene that I paused, the madvr rendering had slightly better rendering in the darker ground shadow areas, but vlc's d3d11 had slightly better rendering in the highlight areas (clouds), but overall, it wasn't doing the great difference that it was with the bt.601 file.

MPCVR renderer does the same thing with the bt.601/pal file like madvr, washed out gamma.

PS. I haven't watched it yet, but the images were from a 1978 British series by Terry Nation called Blake's 7. "Blake's 7's narrative concerns the exploits of political dissident Roj Blake, who leads a small group of rebels against the forces of the totalitarian Terran Federation that rules the Earth and many colonised planets. The Federation uses mass surveillance, brainwashing and drug pacification to control its citizens."

[flossy_cake]

Originally Posted by Sunspark

More than that.. the colours themselves are different.. if you look at the red and blue in the first row, I guess similar to the same issue you had with Family Guy, except it doesn't have the blue cast. Unless the different shade of red, etc. is due only to gamma? Might be it, more below.

Yep, applying gamma exponent to RGB channels changes the hue and saturation as well. Here's madvr with +0.2 gamma on RGB channels vs VLC:



The amount of red in the cyan section is still quite different though - RGB (79,155,181) vs (73,154,182).

The red sections behind it are identical though. Maybe something to do with gamut conversion...

Originally Posted by Sunspark

Everything is at 0, and enable gamma processing is unchecked.

So you haven't told madvr that your monitor's gamut is BT.709 ? If not, then gamut will be wrong (assuming your monitor is BT.709). VLC may be assuming monitor is 709 gamut by default.

[Sunspark]

Originally Posted by flossy_cake

So you haven't told madvr that your monitor's gamut is BT.709 ? If not, then gamut will be wrong (assuming your monitor is BT.709). VLC may be assuming 709 gamut by default.

I was working on the assumption that if it was on "disable calibration controls" it's supposed to assume BT.709/2.2 and do everything from there in terms of making changes regarding bt.601 content, etc. Played around with it, if I tell it already calibrated to BT.709 the picture doesn't change whether I set it to 1.8 or 2.6 and seems to be the case still whether on or off.

However, turning on only enable gamma processing changes things.

So if I tell it it's calibrated to bt.709/1.8 and set 2.40/pure in enable processing, it looks basically the same between the two players actually!

So, is my understanding correct, that one needs to manually enter in the processing # based on the content? To use 2.4 for bt.601 and to change that to any number between 1.8 and 2.2 for bt.709 content? It would have been nice if it was automatic just based on the "calibrated to" setting..

[thighhighs]

Originally Posted by thighhighs

I would like to know what other users think about 1D. I think 25% AB sometimes helps for video 2160 -> 1080

After taking a closer look at SSIM1D100 + AB25% vs SSIM1D75 no-AB (video source), I changed my mind. AB blurs too much. So it's better to use SSIM1D without any AB.

[flossy_cake]

Originally Posted by Sunspark

I was working on the assumption that if it was on "disable calibration controls" it's supposed to assume BT.709/2.2 and do everything from there in terms of making changes regarding bt.601 content, etc. Played around with it, if I tell it already calibrated to BT.709 the picture doesn't change whether I set it to 1.8 or 2.6 and seems to be the case still whether on or off.

However, turning on only enable gamma processing changes things.

So if I tell it it's calibrated to bt.709/1.8 and set 2.40/pure in enable processing, it looks basically the same between the two players actually!

So, is my understanding correct, that one needs to manually enter in the processing # based on the content? To use 2.4 for bt.601 and to change that to any number between 1.8 and 2.2 for bt.709 content? It would have been nice if it was automatic just based on the "calibrated to" setting..

As far as I can tell, in relation to SDR content only, if you don't tell MadVR anything about your monitor in the "this display is already calibrated" section, MadVR won't assume anything about your monitor, and therefore won't modify the colour at all to suit your monitor, and you'll get incorrect colour if the video content uses a different gamut than your monitor's gamut, which is the case when watching SD 601 gamut content on a typical HD 709 gamut monitor or TV. That's what the Family Guy screenshots here are showing.

Also in the "this display is already calibrated" section, there is "this display is calibrated to the following transfer function / gamma". This appears to be used by MadVR as part of its gamut conversion formula only. For SDR content it barely affects the midtones (as you have noticed). It's not a gamma control, I think it's just one of the coefficients used in the gamut conversion formula, as far as I can tell.

Separately to this in the other "color & gamma" section is the "desired display gamma / transfer function". This is a real gamma control and does change the entire gamma curve to the value you choose. To do such a conversion requires knowing what your monitor gamma is to begin with. If you haven't told MadVR what your monitor gamma is in the previous section (which happens if you select "disable calibration controls for this display") it assumes your monitor is 2.2. So if you chose 2.4 it would do a +0.2 adjustment. Otherwise, if for example you already told MadVR your monitor is 2.4 in the other section, selecting 2.4 results in no change in colour.

We shouldn't need per-content settings since MadVR automatically gets the source gamut from upstream, and even if upstream doesn't have it, MadVR guesses correctly based on things like resolution and framerate of the video ("best guess" on debug screen) and I've never seen it get it wrong.

So if your monitor has 2.2 gamma and 709 gamut, and you want to get accurate gamut conversion for SD 601 gamut content, and additionally emulate what VLC appears to be doing:

1. calibration > this display is already calibrated > BT.709 & pure power curve 2.2 (informing MadVR your monitor characteristics)
2. color & gamma > enable gamma processing > pure power curve 2.4 (emulating VLC behaviour of assuming SDR content was mastered at 2.4 gamma by applying a +0.2 gamma shift)

The downside to 2 is that it will cause MadVR's HDR->SDR conversion to be 0.2 gamma darker than it should be. To avoid this I only set 1 and not 2, and calibrate my monitor to 2.4 for night and 2.2 for day in the video card gamma table which is system-wide.

Originally Posted by thighhighs

After taking a closer look at SSIM1D100 + AB25% vs SSIM1D75 no-AB (video source), I changed my mind. AB blurs too much.

Yeah that's why I stopped using it as well.

Anti ringing seems ok and has a subtle effect when used in conjunction with sharpening filters, but doesn't seem to be effective at removing ringing in the source, eg. S01E01 of The Sopranos Bluray has some ringing that I wanted to get rid of and it couldn't help there at all.

[Sunspark]

Originally Posted by flossy_cake

Anti ringing seems ok and has a subtle effect when used in conjunction with sharpening filters, but doesn't seem to be effective at removing ringing in the source, eg. S01E01 of The Sopranos Bluray has some ringing that I wanted to get rid of and it couldn't help there at all.

I vaguely remember madshi saying that the anti-ringing only applies to new ringing created by scaling done by the algorithm and not the original material itself. Makes sense to me, probably easier to write a calculation to compare before and after and see if it made new ringing on edges than to only have 1 image and decide whether it has elements that need to be removed.

[Asmodian]

Originally Posted by Sunspark

probably easier to write a calculation to compare before and after and see if it made new ringing on edges than to only have 1 image and decide whether it has elements that need to be removed.

I don't think it looks for ringing at all, it always runs another algorithm after scaling which makes aliasing a little worse while also making ringing better. It is based on the known amount of ringing added by the scaling algorithm, not an analysis of the image after scaling.