madVR - high quality video renderer (GPU assisted)

[flossy_cake]

Originally Posted by mzso

The recent madVR crashing issue which we encountered, suggests otherwise.

Yes that appears to be a bug introduced by madshi's update nag screen, which only occurs in the beta version of madvr?

Disappointing if true, since there should never be any nag screens in madvr (I've never had one in final stable public version). I almost put a nag screen in an app once but came to my senses and realised how morally wrong that would have been.

Originally Posted by SirMaster

No reason to switch away from Windows 10 on my HTPC, just keep it firewalled off the Internet after 2025 or so.

So this means that Windows 10 STILL can't be reliably configured to disable updates? I'm still living in the stone age here (Windows 7) so I don't know what the current situation is with Windows 10. Isn't there like some Enterprise build or something that can be configured to disable updates?

Originally Posted by SirMaster

Why would you use smooth motion for a 120Hz display?
120Hz is exactly 5x24Hz 4x30Hz, and 2x60hz

It's because they couldn't successfully tune their 120hz mode to be very close to 120/1.001, so they end up with a dropped/repeated frame every n minutes, so instead of that they would rather have blended frames if they aren't noticeable to them.

[ryrynz]

Originally Posted by flossy_cake

So this means that Windows 10 STILL can't be reliably configured to disable updates?

Updates can be disabled perfectly fine.

[SirMaster]

Originally Posted by flossy_cake

So this means that Windows 10 STILL can't be reliably configured to disable updates?

It doesn't mean that. It means that Windows 10 eventually stops receiving security updates and would not be advisable to connect it to the Internet after that point.

[mrbinky]

Originally Posted by ryrynz

Could be your config. Try it without your profile after backing up. If it works load your settings back in manually.

Thanks, that would probably fix it.

I'm just wondering if it's worth doing, given that I've used version 17 since it was released and it seems to work. I'm not familiar enough with any of the beta releases to know if I'm missing out on any useful functionality.

Regardless what the product is, I've always ignored beta releases and waited until stable releases before installing an upgrade. I've done the same with madVR and so far never had any reason to regret that policy. But knowing that Madshi will never again release another stable version of his software does change things a bit.

[SamuriHL]

If you use HDR tone mapping in madvr, then yes, you are missing out by skipping the betas. Otherwise, no, not really other than a couple misc bugs that have been fixed.

[thighhighs]

Originally Posted by mrbinky

Regardless what the product is, I've always ignored beta releases and waited until stable releases before installing an upgrade. I've done the same with madVR and so far never had any reason to regret that policy. But knowing that Madshi will never again release another stable version of his software does change things a bit.

Just to clarify.
madshi said don't hack the madVR. Do not sell HTPC based on madVR. Otherwise, madVR will end for everyone Also, he's busy.
But this does not mean that there will never be updates. madVR: I Want to Believe

[flossy_cake]

Originally Posted by SamuriHL

If you use HDR tone mapping in madvr, then yes, you are missing out by skipping the betas.

Missing out on what, exactly? Can you show me in a screenshot how I am "missing out". I've got mine set to tone map HDR to SDR using BT.2390 - is this not ideal? What is ideal tone mapping from HDR to SDR? Or are you talking about HDR to HDR tone mapping? What is your target curve and why? Why should I desire that curve? What is the "correct" way of displaying HDR on a display that cannot physically match the peak brightness demanded by the source file? Again, you say I am "missing out" as if there is some good thing that I cannot attain. I want to know what this is.

[Alexkral]

Originally Posted by flossy_cake

Missing out on what, exactly? Can you show me in a screenshot how I am "missing out". I've got mine set to tone map HDR to SDR using BT.2390 - is this not ideal? What is ideal tone mapping from HDR to SDR? Or are you talking about HDR to HDR tone mapping? What is your target curve and why? Why should I desire that curve? What is the "correct" way of displaying HDR on a display that cannot physically match the peak brightness demanded by the source file? Again, you say I am "missing out" as if there is some good thing that I cannot attain. I want to know what this is.

Exactly, I would like to know that too. I think this is comparable to what madshi was saying about NGU sharp levels, that you only notice the difference in some specific frames with a lot of edges.

I think that BT.2390 tone mapping, even static, is perfectly valid in most situations, and in fact it's what I've been using for a long time.

[huhn]

tone mapping is not properly defined. is very open for interpretation and that's the issue there is no correct way.

[SamuriHL]

Exactly. Tone mapping is like the wild west. To explain how the beta builds have improved from the last stable build isn't really possible, however. Many many options have been added/ changed over the years that it's been worked on, all to make tone mapping better and provide an image that's closer to what you'd theoretically get on a 10000 nit display. Right now they're working on which luminance method is better. If you really want to know what improvements there are over whatever you're using now, you've got two options. Go try it for yourself, starting with settings you can find from people in the avs thread and tweaking them. Or read the several hundred posts over the last several years to see how it's evolved. No one can definitively tell you how it'll be better for your specific equipment and viewing environment. Nor are they going to be able to give you some magic settings that just work. The beta builds require effort but the result is a much more dynamic tone mapping solution that gets us closer to the end goal of emulating a theoretical perfect display on consumer equipment that is far from ideal.

Sent from my SM-G998U1 using Tapatalk

[mrbinky]

Originally Posted by Alexkral

Exactly, I would like to know that too. I think this is comparable to what madshi was saying about NGU sharp levels, that you only notice the difference in some specific frames with a lot of edges.

I think that BT.2390 tone mapping, even static, is perfectly valid in most situations, and in fact it's what I've been using for a long time.

I've always had HDR mapping set to "let madVR decide what's best." I always assumed that whatever Madshi programmed madVR to do was better than what someone with no understanding of HDR tone mapping (me) could manage.

Is that not a fair assumption? What does the software actually do when you tell it to "decide what's best?"

[SamuriHL]

I want you all to think about the premise of what you're asking for just a minute.

Hundreds of posts and 165 beta builds dedicated to improving dynamic hdr tone mapping, a 15k dollar video processing box released with the fruits of that work to make it easy to use, and you believe that static tone mapping or "letting madvr decide" in an old build is going to somehow look the same?

There is a large amount of picture quality to be gained by taking the time to learn how to configure and use the beta builds. But it takes effort and work. If you want easy to use, buy an envy. That's an opinionated view of all the settings that have been added to madvr over the years. Do you think he can charge over 10 grand for an envy to provide the image quality of static tone mapping? You can get the same image quality using the beta builds, but the tradeoff for getting something for free is the learning curve and accepting that the beta builds expire.

What i use for settings on a 900 nit oled is most likely not going to help someone with a 50 nit projector. That's why there's a learning curve. But in the avs thread you can likely find a base set of settings that are close to what you have for equipment that you can use as a starting point. It takes time and effort.

Sent from my SM-G998U1 using Tapatalk

[Alexkral]

Well, I own a STAX SR 009. Of course it's amazing, and without a doubt the best headphone I've ever heard. But the price difference to let's say a Sennheiser HD800 is hardly justifiable. And if, for example, you value the soundstage more than other features, you better stay with the Senns.

So here it is similar, the betas are using multiple settings and processing to get the most detail and luminance in the highlights. But you can get the same luminance simply by using the static BT.2390 with the original roll-off. And the difference in detail isn't usually very noticeable unless you're comparing screenshots.

In any case, I admit that I'm probably oversimplifying the matter, and that the differences can be more noticeable depending on the use case.

[SirMaster]

IMO tone-mapping on even beta 113 is significantly improved over the last non-beta release from 2018 or whenever it was.

I mean the non-beta release doesn't even have dynamic tone-mapping.

There's no reason anyone using madVR can't use at least beta 113 or 112b if you want to use smooth motion option.


Just drop the beta files on top and that's it. I have never seen any issue with 113 over the last non-beta.

[SamuriHL]

Yea that's a fair point, SirMaster. While obviously there's been a ton of improvement since 113, that at least gets you in the game with dynamic tone mapping which was really a very large improvement. Certainly noticeable without having to compare screenshots when looking at static tone mapping. But it all depends on what your goal is. If what you get now is "good enough" I'd question why you're even bothering with madvr at all at this point. Other solutions that are being updated to fix things like issues with Windows and driver updates would be far easier to manage. It's why I have two configurations in JRiver MC myself, one for "just work" and one for "I want the best quality I can get". One is madvr, one is not. I can switch between them in 30 seconds so it's not really an issue. At 900 nits, tone mapping for the majority of content (that's mastered to 1000 nits) is minimal at best. I only see improvements with 4000+ nit content when using madvr. But those with far less nits to play with, I can tell you, dynamic tone mapping in madvr matters, and it's not invisible. But there's really no need to take my, or anyone else's, word for it. Go try it.

[flossy_cake]

I suppose most people would agree that soft clipping is preferable to hard clipping?

And a method which minimises delta error in the soft clipping region is better than one which doesn't?

For still photos I can see this could be objectively superior, if it minimises delta error compared to the reference display.

But for video where the histogram is constantly changing, you could have a scene where a bright object appears on screen for a few seconds and the tone mapping for the lower section would have to change to accommodate this until the bright object leaves the scene. This could result in "brightness pops" or "dynamic gamma" type effect which could be subjectively undesirable. Perhaps this could be worked around by using a hysteresis characteristic to very gradually latch to the new scene tone mapping to avoid these noticeable fluctuations.

I guess I need to read up on how BT.2390's tone mapping works. If it just uses something like rolling off the RGB channels then that will produce some big hue and saturation deltas compared to other methods.

[SamuriHL]

And that's what people who've looked at this topic a lot have found exactly, hue and saturation problems. Madvr handles the "brightness pop" issue by reading ahead a few frames (I'm VASTLY oversimplifying some very technical things that madshi built into his dynamic tone mapping) to handle those kinds of transitions and there are options to tweak the sensitivity (I guess that's a bad word for it) to those changes. But static tone mapping definitely has hue and saturation challenges that they're working on right now in madvr's tone mapping. Having custom curve ability in madvr has solved some of that. They used a custom curve editor built into madvr to work through finding the "best" curves of which there's a lot of selection in there now. Eventually they plan on narrowing that down to a couple of the best ones. So all of these issues are what they've been working on for the past several years and why madvr brings a ton of quality to the table over other solutions.

[SirMaster]

Originally Posted by flossy_cake

But for video where the histogram is constantly changing, you could have a scene where a bright object appears on screen for a few seconds and the tone mapping for the lower section would have to change to accommodate this until the bright object leaves the scene. This could result in "brightness pops" or "dynamic gamma" type effect which could be subjectively undesirable. Perhaps this could be worked around by using a hysteresis characteristic to very gradually latch to the new scene tone mapping to avoid these noticeable fluctuations.

I guess I need to read up on how BT.2390's tone mapping works. If it just uses something like rolling off the RGB channels then that will produce some big hue and saturation deltas compared to other methods.

This is all literally what madshi has been fine tuning and tweaking for years with the madVR betas and 165 builds of them.

It's getting very, very good at this point. Yes things are constantly adjusting dynamically to compensate, but in ways that are not seemingly distracting or with noticeable artifacts.

[SirMaster]

Originally Posted by SamuriHL

At 900 nits, tone mapping for the majority of content (that's mastered to 1000 nits) is minimal at best. I only see improvements with 4000+ nit content when using madvr. But those with far less nits to play with, I can tell you, dynamic tone mapping in madvr matters, and it's not invisible. But there's really no need to take my, or anyone else's, word for it. Go try it.

Yeah, 900 nits is a whole different story than my 75 nits heh.

The difference between madVR "stable release" and beta 113 is quite large, and the difference between 113 and 165 is certainly noticeable, but it's more of a refinement at this point.

But anyone who is using tone mapping on projectors should at least be using beta 112b/113.

[flossy_cake]

Originally Posted by SamuriHL

But static tone mapping definitely has hue and saturation challenges that they're working on right now in madvr's tone mapping. Having custom curve ability in madvr has solved some of that. They used a custom curve editor built into madvr to work through finding the "best" curves of which there's a lot of selection in there now.

From what I learned a few years ago, the luminance of a colour can be isolated from its hue and saturation, so the curve could be applied only to the luminance component, thus avoiding significant hue and saturation shifts. But I read that the L component in HSL, B component in HSB, and Y component in YUV aren't accurate measures of luminance. But I seem to recall the L in Lab is accurate so that could be used. But then I read elsewhere that the a and b components aren't accurate measures of hue and saturation, so I'm not sure how curving the L channel would play along with leaving the a and b components unaltered. Here we can fiddle around with sliders and see how different models interpret the meaning of luminance.