madVR - high quality video renderer (GPU assisted)

[tp4tissue]

Originally Posted by huhn

ycbcr and rgb are a massive different with a massive lossy processing step. this is presentation not high bit deep processor don't forget that.
madVR is also allways RGB

Outputting 422 from nvidia seems to default to CEA (limited) and ycc709.

Does that mean it always goes through the lossy step?

[huhn]

madVR can't do ycbcr so it is always lossy and nvidia defaults to limited with HDTV resolution and uses full with PC resolution i don't know why.

[NeonPhoenix]

Originally Posted by ryrynz

Stated your problem right from the start, dial back your settings, they're way too high.

My render time is around 22 ms so I do not want to lower my settings. It's just downscaling to 2k from 4k anyways.

[NeonPhoenix]

Originally Posted by ryrynz

Stated your problem right from the start, dial back your settings, they're way too high.

Can I show you my settings on discord please?

[ryrynz]

Originally Posted by NeonPhoenix

Can I show you my settings on discord please?

Just upload a screenshot of the file playing that has the audio lag with the stats screen up to an image host and paste the link here.

[tp4tissue]

Originally Posted by huhn

madVR can't do ycbcr so it is always lossy and nvidia defaults to limited with HDTV resolution and uses full with PC resolution i don't know why.

Nvidia is so trash.

[huhn]

so nvidia is trash for having a refreshrate page and amd is not for not having it?

[tp4tissue]

Originally Posted by huhn

so nvidia is trash for having a refreshrate page and amd is not for not having it?

I can page refreshrate on AMD with addons like HRC.

But Some of the Nvidia problems as you've mentioned are unfixable.

[Sunspark]

RGB to YCbCr 4:4:4 conversion and vice versa is lossless from a mathematical perspective. You can convert back and forth, in math. What does happen is that rounding errors can accrue when working with lower bit depths like 8, so in the real world you cannot do conversions back and forth forever. RGB can sometimes look a little "harsh" I find. I am not saying for everyone to use it, I am just saying that it can be worth looking at to compare how it is if one is already having an issue with RGB output. Perhaps it will be processed differently by the driver or display panel. If it results in a better picture, then why not? It only takes a second to compare.

[tp4tissue]

Originally Posted by Sunspark

If it results in a better picture, then why not? It only takes a second to compare.

I don't think we can see a difference Sunspark, and without a reference device, we have no idea what it's suppose to look like.

My personal complaint is only that the video driver UI makes these settings confusing and non transparent. The TV also goes through its own set of "whatever it wants." I highly doubt we can achieve bit perfect end to end. The fact that we need to use colorimeters in the first place attests to that.

As for your perception of Harsh, what I notice is that on some textures for example 422 can cause more noise, and have a sharpening effect. Things like this on specific surfaces can cause weird anomalies.

I thought about this alot, and you'd think some guy goes over every frame of the movie, and make sure it all looks right, and as intended. But from my research this is not how it's done. The colorist's job is really just to eyeball it. He has tools, the scope, the waveform, etc. But he's eyeballing it, and he has limited focus/ time to do it. So I think the expectation of mathematical perfection, the right texture color, the right blacks, it's all mostly in our heads. No such perfection exists, as no such perfection is even possible.

[huhn]

Originally Posted by Sunspark

RGB to YCbCr 4:4:4 conversion and vice versa is lossless from a mathematical perspective. You can convert back and forth, in math. What does happen is that rounding errors can accrue when working with lower bit depths like 8, so in the real world you cannot do conversions back and forth forever. RGB can sometimes look a little "harsh" I find. I am not saying for everyone to use it, I am just saying that it can be worth looking at to compare how it is if one is already having an issue with RGB output. Perhaps it will be processed differently by the driver or display panel. If it results in a better picture, then why not? It only takes a second to compare.

because it is mathematically impossible to do lossless while keeping the same precision. 16 bit is not enough
you are just adding noise to the image and that's it in the bested of best cases.
with is objectively worse.

there is no processing by the driver we know RGB is not touched by nvidia.

[Octo-puss]

I vaguely remember asking about any new development around madVR several years ago and being told there were new builds on a completely different site, but that's about it.
Can anyone fast forward me to present state of events please? Apparently, madshi doesn't even come here anymore, so I guess newer madVR is to be found elsewhere?

[huhn]

https://www.videohelp.com/software/madVR/old-versions
smooth motion flickers or worse in this version.

there is pretty much no development anymore.
some tone mapping changes barely anyone responses to and regression like this.

[Siso]

Originally Posted by huhn

there is pretty much no development anymore.
some tone mapping changes barely anyone responses to and regression like this.

The alternatives are not good...

[SamuriHL]

While I realize this is the madvr thread, I completely disagree with the "alternatives are not good" statement. JRVR works very well, as an example.

[Siso]

Originally Posted by SamuriHL

While I realize this is the madvr thread, I completely disagree with the "alternatives are not good" statement. JRVR works very well, as an example.

If you buy it.

[SamuriHL]

It's still an alternative.

Sent from my SM-S928U1 using Tapatalk

[dbezerra]

MPV also has an excellent tone mapping - and very similar (if not equal) to JRVR since they both use LibPlacebo.

[tp4tissue]

Originally Posted by dbezerra

MPV also has an excellent tone mapping - and very similar (if not equal) to JRVR since they both use LibPlacebo.

I'm very thankful for madshi saving old monitors and bridging the initial wave of non-hdr devices.

Very confused that they decided tonemapping was to remain their headline feature, when the whole point of the hardware side improvements is to make tonemapping obsolete. So it's like working against the current by investing so much into that function.

Then, without actual low level control of the tv hardware, what are you actually doing, didn't madvr come to be because we didn't like bad renderers making a mess of the data, but now, you're making a mess of the data, because the hardware is not expecting these curves injected into the pipeline.

[mzso]

Originally Posted by huhn

https://www.videohelp.com/software/madVR/old-versions
smooth motion flickers or worse in this version.

there is pretty much no development anymore.
some tone mapping changes barely anyone responses to and regression like this.

Yeah, but older versions have a water mark, a long way back.