madVR - high quality video renderer (GPU assisted)

[70MM]

this has nothing todo with madVr if the file doesn't get there in time.



try the option: "if black bars change pick one zoom factor".

this feature will never be fool proofed. Yes I have tried that setting but it still goes crazy on titles with mixed ratios Im sorry to say...

[tp4tissue]

Yes I have tried that setting but it still goes crazy on titles with mixed ratios Im sorry to say...

Are there lots of mix-ratio movies ?

What quantity of rendering time improvements are you guys seeing.

I'm only seeing 0.4-0.6ms , that doesn't seem worth it.

The Most demanding settings in madvr have differences of 10-30ms on cheaper cards, so that 0.4-0.6 saving may not help to cut the cheese anywhere.

woah.. nm figured it out, didn't crop. 5-10ms on 1080p upscales...


How does cropped profiles work

Can i use (AR > 1.77) ?? so pretty much anything > 16:9 use a different profile ?

if (variableAR) "VAR"
else if (AR > 16:9) "AR"

Does AR have to be input as a ratio ?

Is there a way to crop horizontal bars only, but not crop vertical bars. ?

[ryrynz]

It does on very low spec machines.

He means directly related. Total system performance is another issue.

[Asmodian]

Is there a way to crop horizontal bars only, but not crop vertical bars. ?

Why would you want to do that?

[madjock]

Why would you want to do that?

Because he seems quite mad.....he wrote most of that last post to himself over an hr. :D

[Damien147]

I ain't gonna change anything but I am just curious.
Smooth motion blurs slightly the whole image,right?
For example does NGU still looks like NGU with smooth motion enabled or it looks like a lower quality upscaler?

[tp4tissue]

Why would you want to do that?

Because he seems quite mad.....he wrote most of that last post to himself over an hr. :D

Hahahahahahahahaah..

I got a few movies that have 2-3 pixel worth of vertical black bar,

I'd rather have that Uncropped, because otherwise it goes from NGU to NGU + Lanczos. Why waste so much processing power over 2 lines.

And not just the processing overhead, but how much is Lanczos messing with the already really good image from NGU..


If the detection could reject small quantities that would be good.

But I would say rejecting vertical in general would cover nearly all cases, because if it's a wide screen movie, the vertical black bar I've seen are at most 10-20 pixels wide. For example the ghost in the shell anniversary bluray.

Adding Lanczos on top of NGU could push it into the 40+ ms territory, without it , just NGU , it's in the 35ms territory, that's a huge difference. if we could crop horizontal and NOT vertical.

[huhn]

go to zoom control and read the first line...

[tp4tissue]

I ain't gonna change anything but I am just curious.
Smooth motion blurs slightly the whole image,right?
For example does NGU still looks like NGU with smooth motion enabled or it looks like a lower quality upscaler?

No, you still get your money's worth , it will just look slightly more blurry because interframes are blended.

It smooths out judder for people who are very bothered by judder.

I personally don't mind judder, because heck 24fps itself is almost a slideshow, why bother with judder removal. :D

[tp4tissue]

go to zoom control and read the first line...

Does this continue to crop horizontal but not vertical ?

[huhn]

cropping doesn't change the AR.

so crop both sides will result in scaling if not you will not scale.
if you setup your player to deform your image it will "always" scale.

if your source file doesn't match your device AR use an profile.

[tp4tissue]

cropping doesn't change the AR.

so crop both sides will result in scaling if not you will not scale.
if you setup your player to deform your image it will "always" scale.

if your source file doesn't match your device AR use an profile.

I'm not trying to match a target aspect ratio.

For example. If I got a 2.x : 1 movie. It's got both vertical and horizontal bars.

But the Vertical bars are only 2-3 pixels wide

I definitely want to crop the Normal Big Horizontal bars.

This allows for Pushing NGU Luma to Very High vs High. That's good. Render time 35ms

But now if the Detection works on the Vertical Bars again, it will add Lanczos Ontop of NGU VH, pushing render time to 40+ms.

[huhn]

try it out disabling scaling doesn't mean disabling cropping.

[tp4tissue]

try it out disabling scaling doesn't mean disabling cropping.

Here's what happening

the 1080 is going to 816, Want

the 1920 is going to 1918, Do not Want, adds Lanczos ontop of NGU(vh)

The scaling option you recommended doesn't seem to impact this.

https://imgur.com/a/v2m18bc

[nevcairiel]

There is an option to ignore small changes by X pixel, did you enable that?

[tp4tissue]

There is an option to ignore small changes by X pixel, did you enable that?

Are you refering to the first option on the zoom page, disable scaling if .... lines

[huhn]

There is an option to ignore small changes by X pixel, did you enable that?

which clearly works if madVR isn't doing 2x scaling. i don't have a test file to see if madVR still doesn't do that after scaling.

[tp4tissue]

which clearly works if madVR isn't doing 2x scaling. i don't have a test file to see if madVR still doesn't do that after scaling.

So, it's the 2x scaling causing the issue, and it SHOULD work if not for the NGU ? This isn't the result of the vertical cropping ?

[huhn]

i don't have a test file i don't know and i clearly don't know what madshi things about this or what supposed to happen in this case.

if our don't use an x2 scaling leaving the boarders is just pointless.

[Damien147]

No, you still get your money's worth , it will just look slightly more blurry because interframes are blended.

It smooths out judder for people who are very bothered by judder.

I personally don't mind judder, because heck 24fps itself is almost a slideshow, why bother with judder removal. :D

Good to know.
My TV has judder problems by nature,so it's useful I guess.
Never done an A B,just use it since introduced and can't see anything wrong.I am used to the ''blur'' it seems and find it normal.
Thank you.

[tp4tissue]

i don't have a test file i don't know and i clearly don't know what madshi things about this or what supposed to happen in this case.

if our don't use an x2 scaling leaving the boarders is just pointless.

Well, I'm sure some people are OK with vertical bars because they're usually small on wide screen movies.

Because if we're to assume NGU already produces the best image, Why would we want Another Scaling layer Lanczos ontop of that JUST to get rid of a 2 pixel vertical bar ?


That is to say, the bestest bacon of the madvr system is NGU, so we're moving all our eggs to optimize performance for this feature. The lanczos cutting 2pixel vertical bar is good, but it's like kale, yea it's healthy, but we showed up at the picnic for bacon. ?

[brazen1]

No, you still get your money's worth , it will just look slightly more blurry because interframes are blended.

It smooths out judder for people who are very bothered by judder.

I personally don't mind judder, because heck 24fps itself is almost a slideshow, why bother with judder removal. :D

Judder is the worst motion I can imagine. I had it before modern 120Hz, 144Hz, 240Hz displays. 24fps isn't a slideshow. 60Hz displays are - resulting in pulldown. I tried madVR SM once. It appeared to still have judder just at a faster rate but I might have not optimized everything for it perfectly. I prefer 240Hz with modern interpolation algo. Smooth as butter including slow pans and no visible wrong guesses. Motion handling as good as gets for the time being...

[tp4tissue]

Just tested some more movies. Surprisingly QUITE MANY will cause the blackbar detection to crop 1920 down to 1919 or 1918 which causes the subsequent 2nd phase upscaling to kick in.. After NGU already upscales..

Darn tootn'

NGU (High) -> Lanczos AR

the disable scaling option doesn't work. :(

[Moksu]

Hey,

Has anyone else experienced problems with MPC-HC crashing when moving it to another screen? (using madvr to playback output)

[el Filou]

Just tested some more movies. Surprisingly QUITE MANY will cause the blackbar detection to crop 1920 down to 1919 or 1918
the disable scaling option doesn't work. :(Yes, a configurable option like "crop black bars of at least <x> lines" would be useful for 1920-wide sources, ideally with different settings for vertical and horizontal.
I'd even say the setting would be best if it could be specified as a ‰age of the picture dimensions instead of number of lines, that way you could just get rid of the "disable scaling if image changes by <x> lines only" (although I doubt UHD sources still have small vertical black bars, but you never know).

[Asmodian]

I think pixel lines would still be best for the option, I would even like it if was the same "disable scaling if image size changes by only" option but applied to post doubling scaling as well. It could also be relative to the screen itself, the number of extra black lines allowed on the display before scaling activates, and do the check at each instance of image scaling (e.g. before lanczos scaling after doubling). Anamorphic is a little more complicated but I would prefer to not check this until after fixing the aspect ratio.

[tp4tissue]

I think pixel lines would still be best for the option, I would even like it if was the same "disable scaling if image size changes by only" option but applied to post doubling scaling as well. It could also be relative to the screen itself, the number of extra black lines allowed on the display before scaling activates, and do the check at each instance of image scaling (e.g. before lanczos scaling after doubling). Anamorphic is a little more complicated but I would prefer to not check this until after fixing the aspect ratio.

Checking too many times is bad, because it doesn't seem to be a 100% reliable process. It may crop by an extra pixel or 2.

So, I think disabling Vertical check is best, because with horizontal we almost always have room to safely crop, whereas with vertical it could be risky.

I tried another file today, the detection cropped 3840x2160 to 3878, but because it was not doing NGU double, the Ignore scaling function did work in this case.

It's the 1920x1080 crops which cause issues when ngu to 3840.

[el Filou]

It's not "because it was not doing NGU double", it's simply because it didn't have to scale at all as instructed by the setting in question. It compared 3838 or 3828 or whatever (3878 was a typo, right?) to 3840 and sees it's less than the max number of lines under which it can avoid scaling and doesn't scale.
When it compares 1918 after crop to 3840, it concludes "well this image needs to change more than 50 lines after cropping so let's scale"
Using a doubler in your upscaling then just makes the problem worse, but NGU is not the root cause.

[tp4tissue]

It's not "because it was not doing NGU double", it's simply because it didn't have to scale at all as instructed by the setting in question. It compared 3838 or 3828 or whatever (3878 was a typo, right?) to 3840 and sees it's less than the max number of lines under which it can avoid scaling and doesn't scale.
When it compares 1918 after crop to 3840, it concludes "well this image needs to change more than 50 lines after cropping so let's scale"
Using a doubler in your upscaling then just makes the problem worse, but NGU is not the root cause.


I'm not actually sure if it's just ngu, i haven't tested that.

But I think it's prolly just coming up short after cropping to 1918 or 1919, after doubling, short of 3840.

But with 3840x2160, I have a file, it'd crop to 3839, detection works here, even though chroma is also NGU.

So I guess it all comes down to whether there is a second round of scaling. the first round is detected properly

[ryrynz]

Anyone compared a Geforce 2060 to a 1080 with madVR?

[Manni]

Just to update regarding the 8bits/12bits difference with madTPG on the new JVCs. It looks like you need to enable the BT2020 flag in 12bits to get the native gamut. Problem is, you also need to do this with a rec-709 calibration. In 8bits, this isn't necessary. The gamut is linear whether you enable the BT2020 flag in the calibration tab or not.

So I highly recommend to calibrate in 8bits. In fact, I have resolved my banding issue in 8bits, it was due to the "auto" setting in madVR not detecting that the driver is set to 8bits. I discussed this with madshi and currently, the "auto" setting is based on the display EDID, not the driver settings to 8bits or 12bits. Madshi might fix this at some point. In the meantime, if you set the driver to 8bits, you have to force the bit depth to 8bits in madVR.

With 8bits dithering, there is no visible banding compared to 12bits, even with HDR 10bits content. So given all the issues with 12bits with post-385.28 drivers at least with the JVCs (no custom refresh rate, can't select 12bits, calibration issues, borked video levels), I'm using 8bits now, both for playback and calibration. That way, madVR can generate a custom refresh mode that stick,s I only have to enable it in the nVidia CP as it's disabled by default.

I couldn't use 8bits with the rs500 due to the magenta bug, but it's gone with the rs2000.

Thanks to Huhn for his help resolving this.

[Warner306]

Anyone compared a Geforce 2060 to a 1080 with madVR?

The RTX 2060 is about equivalent to a GTX 1070 Ti in performance, so it is still below a GTX 1080.

[el Filou]

But I think it's prolly just coming up short after cropping to 1918 or 1919, after doubling, short of 3840.Exactly, and this is the issue: the condition is only evaluated after cropping and before upscaling, but not after individual scaling steps.But with 3840x2160, I have a file, it'd crop to 3839, detection works here, even though chroma is also NGU.
So I guess it all comes down to whether there is a second round of scaling. the first round is detected properlyI'll say it another way: it has nothing to do with how many rounds of scaling there is or if NGU is enabled somewhere, but with the difference in definition between the cropped image and the final definition the image needs to be displayed in.
Let's say your screen is 3840-wide, you set the setting to "disable scaling if image size changes by only 2 lines or less" and you have 2 black lines to crop in each of those two examples:
- 1920-wide source on 3840-wide display ==> madVR evaluates "my source is now 1918-wide, that's more than 2 lines difference with 3840, so I'll scale", then NGU gets you to 3836 and then has to use another scaler to get to 3840. The condition is only evaluated once before any scaling, so it doesn't even check after using NGU that it's now at less than 2 lines from the display def. In effect, it behaves as if it was playing back a native 1918-wide source!
- 3840-wide source on 3840-wide display ==> "my source is now 3838, that's 2 lines or less difference from 3840, I won't scale."
The setting is evaluated after cropping and before any upscaling operation, and only once. It has nothing to do with how many rounds of scaling are needed, or if NGU is enabled for chroma, or anything else.
Which is why it would be nice if madshi could change the behaviour of this setting to be checked after any scaling step, as Asmodian suggested. You could set it to 5 lines or less and it would handle 5 lines on a 3840 source or 2 lines on a 1920 source.
1920-wide sources is probably the only case where you'll encounter this specific issue as 960x540 video isn't a standard consumer def, but you could in theory also encounter it if you played that source def on a 1920x1080 screen, and also on 640x360 video with a 1280x720 screen.

[huhn]

just use mpc-hc video frame double size for now.

EDIT: or better, madVR should avoid cropping black bars in the source definition if their size is less than the configured setting for this option, that way it wouldn't need to do checks after each scaling step.
1920-wide sources is probably the only case where you'll encounter this specific issue as 960x540 video isn't a standard consumer def, but you could in theory also encounter it if you played that source def on a 1920x1080 screen, and also on 640x360 video with a 1280x720 screen.

black bar detection is also run on the CPU so it's not that easy.

[el Filou]

Yes, thought about that afterwards. :o
I think re-evaluating that zoom control setting after each scaling step would be best and also not that hard to implement, IMHO.

[tp4tissue]

Yes, thought about that afterwards. :o
I think re-evaluating that zoom control setting after each scaling step would be best and also not that hard to implement, IMHO.

Or u know, disable vertical bar cropping, solves 90% of the cases of this issue, not perfect, but i mean, it's a good sweep

[el Filou]

sometimes there is 4:3 or 14:9 hardcoded in 16:9 source

[tp4tissue]

sometimes there is 4:3 or 14:9 hardcoded in 16:9 source

I'm not saying a better solution isn't possible.

Only that as a quick and dirty fix that would resolve most of the issue is also very straight forward by disabling vertical bar detection

Moving ahead, we're mostly dealing with widescreen.

[FlashGordon]

Possible bug:

in madVR 0.92.17

In keyboard shortcuts, if I set a key for 'chroma upscaling algorithm - Bicubic' the keybinding will do nothing. If I set keys specifically for the other chroma upscalers such as Lanczos, Spline, and Jinc they will work. This might have to do with the different options Bicubic gives you (75,100,150, etc.). If I set a key for 'chroma upscaling - toggle' it does select the last Bicubic I used once I toggle over to it.

[ryrynz]

Pop it up on bugs.madshi.net

[totalz]

madVR 0.92.17
with KMPlayer, in fullscreen, player's seek(bottom)/function(top) bars are in auto-hide. When I try to use the seek bar, the video frame moved down, is there option(s) to "fix" that with MadVR? Cause that does not happen with EVR or older versions of KMPlayer.

* please ignore my Setup in signature

[tp4tissue]

Anyone compared a Geforce 2060 to a 1080 with madVR?

Unless someone owns both, it's difficult to compare, because they could be using different paths, different drivers, different amount of shaders, somehow the memory is accessed in a different way, power setting, power limits..

Guessing isn't super useful.. we'll just have to wait until someone buys one.. :scared:

[huhn]

there is no need to own both the 1080 is clearly faster without a doubt.

the only way to make the 2060 faster then the 1080 would be new code in madVR that uses new features from the Turing architecture and that's clearly not the case yet.

[ryrynz]

I know the 1080 would be faster, I'm curious about the performance delta though given things like card size and power draw. Thanks to the 1660Ti there should be some good prices on 1060s second hand/New? for all you people still using 950/960s or lower, or just straight up go for a 1660Ti for the best performance per dollar new.

[tp4tissue]

I know the 1080 would be faster, I'm curious about the performance delta though given things like card size and power draw. Thanks to the 1660Ti there should be some good prices on 1060s second hand/New? for all you people still using 950/960s or lower, or just straight up go for a 1660Ti for the best performance per dollar new.

No price drop yet, if anything, the good 1060 models went up by $5-10 recently.

Only the super shitty 1060s go for the $150 range.

A while back 1060 FTW/FTW+ could be had for $150/160

580 is the best deal for gamers right now, good models go for $150 routinely. BUHHHH then Huhn's gonna be like, NGU NGU NGU.. :eek:

[ryrynz]

Yeah, same though. [emoji28] Love ma supersampling.

[KoKlusz]

there is no need to own both the 1080 is clearly faster without a doubt.

the only way to make the 2060 faster then the 1080 would be new code in madVR that uses new features from the Turing architecture and that's clearly not the case yet.

I don't think this is entirely accurate, in most gaming benchmarks I've seen OC 2060 is more or less as fast as stock 1080, sometimes it almost matches stock 2070 (while being quite cheaper on top of it), I assume this at least partially reflects madVR performance as well. Besides, madshi said on another forum that when choosing between RTX or GTX cards, he recommends former.

[tp4tissue]

I don't think this is entirely accurate, in most gaming benchmarks I've seen OC 2060 is more or less as fast as stock 1080, sometimes it almost matches stock 2070 (while being quite cheaper on top of it), I assume this at least partially reflects madVR performance as well. Besides, madshi said on another forum that when choosing between RTX or GTX cards, he recommends former.

WHY did he recommend RTX, that's important. What did he say in the other thread ?

[tp4tissue]

Yeah, same though. [emoji28] Love ma supersampling.

Also, how are you guys making those image comparisons with the red and blue dots.

[ryrynz]

Dunno what anyone else is using but I use Beyond Compare https://www.scootersoftware.com/download.php

I believe madshi's recommendedation was mostly down to future proofing. If there is going to be any tensor core code it's probably a year or two away if not more...
MadVR 1.0 coming 2025 hold your pants.