madVR - high quality video renderer (GPU assisted)

[Charky]

- 12 minutes between frame drops in 3D (vs 3 minutes with 385.28)
- 12bits RGB Full with custom res (CRU), survives a reboot (as long as default refresh rate is 23p)
Has anyone ever managed to switch from 60p RGB 8 bits (default) to custom 23p RGB 12 bits ?

On my setup, 12 bits won't kick in on a custom res if it's not already activated. That's why I stick to 30p RGB 12 bits as the default resolution.

I would be glad to know if someone has ever found a way around...

[Manni]

But HDR passthrough only activates under very specific conditions (must be windowed, can't be FSE, must be fullscreen, can't be windowed, must be D3D11, can't be D3D9, must be 10bit, can't be 8bit) which is bad, and HDR metadata is not properly passed through, as far as I can see.

Now you're being greedy, you want *everything* to work for *everyone* in a single nVidia driver? :)

I consider myself lucky if everything I need works. That's why I said "for me":

- I don't use FSE, except in 3D, and it worked fine. I didn't check if I still needed FSE in 3D, I will.
- I only use fullscreen to watch films. When windowed, I don't mind about quality.
- I only use D3D11 native, nothing else can deal with HDR without making too many compromises here
- I only use 10bits because my JVC has a bug in 8bits (as you know, the magenta bug), so 8bits isn't an option except at 4K60p and I have to use a profile to not send metadata in that case.
- I don't really care about passthrough or HDR metadata as I only use pixel shaders tonemapping now given how excellent it is :). Except for the BT2020 flag, which I didn't check so good point.

I'll double check a few things later and will report back. Always ready to go back to good old 385.28, or even 416.81 :)

[Manni]

Has anyone ever managed to switch from 60p RGB 8 bits (default) to custom 23p RGB 12 bits ?

On my setup, 12 bits won't kick in on a custom res if it's not already activated. That's why I stick to 30p RGB 12 bits as the default resolution.

I would be glad to know if someone has ever found a way around...

No, as noted that's still a downside of the recent drivers.

It only works for me if I have 4K23 12bits RGB full as my default refresh mode. That survives a reboot, and it switches to 4K60p 8bits if needed. I use CRU for my custom res at 23p (hours without a drop/repeat).

The opposite doesn't work. If you select 4K60p as default, you're stuck with 8bits after a reboot, it won't switch back to 12bits at 23p.

So not great for gamers, but again, I'm not looking for perfection for everyone, just for something that works for me. :)

[Manni]

@Madshi

I can confirm that 417.71 doesn't send the correct metadata in HDR passthrough. It sends bogus 1000/20 instead of the actual MaxCLL/MaxFALL and bogus 1000/0.030 instead of actual Max/Min DL.

It does send the BT2020 flag correctly when using pixel shaders tonemapping, so the Vertex changes calibration flawlessly between SDR/HDR on the JVC.

It looks like it works for me, as I don't need passthrough anymore, but I'll keep an eye out for any other oddities.

The levels are still borked on the JVCs in 12bits, you have to use 0-255 in MadVR despite the GPU being set to 0-255 and the display being set to standard to get the correct levels, but that means nVidia or the JVC is probably doing something behind MadVR's back. You can't get the correct levels at all with the JVC set to enhanced.

That's one of the reasons why I stayed so long on 385.28, which is the last driver with which the correct settings give the correct levels (so no one dithering behind MadVR's back).

I'm not ruling out going back to it at some point, but that won't be an option if/when I move to RTX, so I have some motivation to find a more recent one.

[nevcairiel]

Considering how often this stuff is changing, maybe the OS is simply overriding whatever data madVR provides, because the OS is not being told. So in short, perhaps the OS HDR API would result in proper metadata, instead of the NV API (which afaik is still preferred by madVR today)?
Microsoft has put a lot of work into trying to make the OS, Desktop and applications all interact in HDR afterall. It would easily be feasible to imagine that the OS needs to be involved at that point for stuff to work properly.

[j82k]

I can confirm that 417.71 doesn't send the correct metadata in HDR passthrough. It sends bogus 1000/20 instead of the actual MaxCLL/MaxFALL and bogus 1000/0.030 instead of actual Max/Min DL.


Is there any way to test if the correct metadata is being sent without an external device like the vertex?
I assume it still shows the correct metadata in madvr even when it is sending the bogus data, correct?

[Manni]

Is there any way to test if the correct metadata is being sent without an external device like the vertex?
I assume it still shows the correct metadata in madvr even when it is sending the bogus data, correct?

Yes, metadata is correct in MadVR OSD.

Some displays show the metadata they receive, for example some recent JVC projectors do this, but otherwise you need another device. The Vertex shows it on the screen and on its OLED display, but a simple Integral or Linker can tell you the raw metadata if you can decode it.

@Madshi:
I went back briefly to 385.28 to confirm that the metadata is sent correctly, and it is, although for a short while the Vertex indicated "reserved" which means invalid mode. It was fine afterwards. No idea why.

Weirdly, MadVR custom res don't work even with 385.28, when they used to. Also, I only have the correct levels, with MadVR set to 16-235 as it should be, in SDR. In HDR, I have to set levels in MadVR to 0-255, which isn't correct in my setup.

As this was one of the main benefits of 385.28, I'm going back to 417.71 as I don't need passthrough and levels are borked just the same. At least I do get better 3D with a more recent driver.

[Warner306]

Considering how often this stuff is changing, maybe the OS is simply overriding whatever data madVR provides, because the OS is not being told. So in short, perhaps the OS HDR API would result in proper metadata, instead of the NV API (which afaik is still preferred by madVR today)?
Microsoft has put a lot of work into trying to make the OS, Desktop and applications all interact in HDR afterall. It would easily be feasible to imagine that the OS needs to be involved at that point for stuff to work properly.

This poster at AVSForum claims it was broken sometime after v398.11:

https://www.avsforum.com/forum/24-digital-hi-end-projectors-3-000-usd-msrp/2954506-improving-madvr-hdr-sdr-mapping-projector-164.html#post57498156

Maybe Nvidia isn't as interested in ripping UHD Blu-rays as the rest of us.

[KoKlusz]

Fake metadata is for video games, which don't sent metadata on their own. Consoles don't do that, which results in dim image or clipped highlights, depending on display.

But yeah, it should be enabled only when no metadata is detected, I wonder if there's a toggle somewhere in the drivers.

[nevcairiel]

Fake metadata is for video games, which don't sent metadata on their own.

Which supports my theory that the OS needs to be told about the real metadata, so it stops sending the fake stuff. As far as I can tell, madVR is currently trying to avoid the OS HDR functions by directly using NV HDR functionality. But that may as well be colliding with the OS now, since the OS is very much more HDR aware now then it ever used to be.

[brazen1]

My observations:
O/S HDR doesn't do anything at display level, at least on my Samsung display. Backlight and contrast do not increase. When using NV HDR, they do max out automatically and once out of HDR mode, the panel goes back to SDR settings. For this reason alone, I stay clear of anything to do with O/S HDR.

Fwiw, I've found nVidia v.416.81 video drivers are the last working drivers that don't require any specific settings in order to work. I think it's pretty universal. However, HD Audio drivers do not work under certain conditions so I edit the last good audio driver that still works properly into the installer - 388.59. I use HDR passthrough with D3D11 auto/native. 12bit doesn't survive a reboot. For that you need 385.28. But, I prefer 8bit over 12bit anyway. I use FSW for 3D and drop a frame every 12.75 mins. I use FSW for everything. FSW or FSE, HDR still switches.

[Manni]

Considering how often this stuff is changing, maybe the OS is simply overriding whatever data madVR provides, because the OS is not being told. So in short, perhaps the OS HDR API would result in proper metadata, instead of the NV API (which afaik is still preferred by madVR today)?
Microsoft has put a lot of work into trying to make the OS, Desktop and applications all interact in HDR afterall. It would easily be feasible to imagine that the OS needs to be involved at that point for stuff to work properly.

Which supports my theory that the OS needs to be told about the real metadata, so it stops sending the fake stuff. As far as I can tell, madVR is currently trying to avoid the OS HDR functions by directly using NV HDR functionality. But that may as well be colliding with the OS now, since the OS is very much more HDR aware now then it ever used to be.

It's the other way around. OS HDR sends the same bogus metadata, always has. So if you use the OS HDR you just get the wrong metadata all the time. nVidia API was the only way to get proper metadata to the display. But now they have broken this as well, and they send the same bogus metadata irrespective of the way you enable HDR (OS switch or nVidia API).

The other downside of using the OS HDR is that you severely compromise SDR quality, as everything tonemapped to HDR. I'd rather do the opposite and get great HDR to SDR tonemapping with pixel shaders by MadVR that botched SDR to HDR my MS/nVidia. :)

Frankly all this means even more reasons to leave HDR pass-through behind and use pixel shaders to tonemap. With the right settings, I doubt that any display would do better than that. The JVCs, even the new models, certainly can't.

My observations:
Fwiw, I've found nVidia v.416.81 video drivers are the last working drivers that don't require any specific settings in order to work. I think it's pretty universal. However, HD Audio drivers do not work under certain conditions so I edit the last good audio driver that still works properly into the installer - 388.59. I use HDR passthrough with D3D11 auto/native. 12bit doesn't survive a reboot. For that you need 385.28. But, I prefer 8bit over 12bit anyway. I use FSW for 3D and drop a frame every 12.75 mins. I use FSW for everything. FSW or FSE, HDR still switches.

AFAIK the 416.81 drivers do not passthrough HDR better than 417.71, so I'm not sure sure what's the advantage. You still need CRU to get custom res, you still can't hade 12bits survive a reboot if you don't default to 23p, so what's the advantage over 417.71?

The only drivers that did passthrough HDR properly are 385.28 in my testing. Even the crappy 388.16 installed by windows by default are broken re levels, custom res and HDR passthrough, at least here in 12bits.

[nevcairiel]

It's the other way around. OS HDR sends the same bogus metadata, always has. So if you use the OS HDR you just get the wrong metadata all the time. nVidia API was the only way to get proper metadata to the display. But now they have broken this as well, and they send the same bogus metadata irrespective of the way you enable HDR (OS switch or nVidia API).

I'm not talking about the switch you as a user can toggle. I'm talking about the API to talk to the OS, something madVR could do. Back in the early HDR days madVR also had an option to choose which method to use to communicate HDR info, but it was since removed and the NV API is always preferred (if available).
Chances are that the OS sends proper metadata if it knows the proper metadata. Right now, it does not know it, because nothing ever tells it.

You can't judge how this mode works, since you cannot use it.

(These APIs were introduced with Windows 10 Creators Update (1607) as part of DXGI 1.5, fwiw, and they let you specify the full range of HDR headers, both the mastering data, as well as the MaxFALL/MaxCLL values. Several new HDR APIs have been added since, expanding the control applications have over the process. Unfortunately madVR hasn't really been keeping up in development since then, so its very well possibly it could work better by trying to cooperate with Windows 10, instead of trying to work around it.)

[brazen1]

AFAIK the 416.81 drivers do not passthrough HDR better than 417.71, so I'm not sure sure what's the advantage. You still need CRU to get custom res, you still can't hade 12bits survive a reboot if you don't default to 23p, so what's the advantage over 417.71?

The only drivers that did passthrough HDR properly are 385.28 in my testing. Even the crappy 388.16 installed by windows by default are broken re levels, custom res and HDR passthrough, at least here in 12bits.

As I stated, 416.81 are more universal. YOU can use newer drivers because YOU are using a very specific environment. I am not. I'm a little more diverse and any driver after 416.81 does not meet that diversity. I'll give you one example: Try playing an HDR title with DVDFab Media Player v.3 (the only player that provides full menus for HDR.iso without very special hardware) using any driver newer than 416.81.

[Manni]

@Nevcairiel: OK, makes sense. As long as you're not suggesting that we should be permanently in HDR mode, it might be a solution. Let's see if Madshi can fix this.

Final note on 417.71, I don't need FSE anymore for 3D, so I'm now officially FSE free :)

Right now 417.71 is a keeper for my needs. Let's see if it lasts...

[Manni]

As I stated, 416.81 are more universal. YOU can use newer drivers because YOU are using a very specific environment. I am not. I'm a little more diverse and any driver after 416.81 does not meet that diversity. I'll give you one example: Try playing an HDR title with DVDFab Media Player v.3 (the only player that provides full menus for HDR.iso without very special hardware) using any driver newer than 416.81.

Well, if you really want universal, nothing beats 385.28. :) Every single driver since has broken something or the other.

DVD Fab media player is really buggy and I rip to BD folders, so I can use jRiver to get BD / UHD BD Menus in HDR with 417.71 when I need to, as well as direct TV Series episode playback with MyMovies. And that's with MadVR as a renderer, which is far preferable to whatever DVD Fab is doing.

I haven't tried but if you automount the ISO with jRiver (using data type), it might be able to play it. Anyway that's OT here.

[brazen1]

That's a bold statement to say DVDFab Media Player v.3 is really buggy. I've been using it for quite a while. I don't have any problems? It also produces a pretty decent picture for HDR since its chroma upscaling is good and since luma makes no difference for UHD HDR especially when passing through. Not that I use it exclusive. I still prefer madVR renderer with supported players but for those times I want menus...

385.28 video drivers can be beat. You know this yourself. For example, 385.28 driver results in a frame drop every few minutes. 416.81, every 12.75. I'd say that's a fairly significant reason to get away from 385.28.

Not all of us use jRiver. I'm not sure how well it handles UHD HDR menus via an iso or open file structure rips because I'm not familiar with it but to suggest it's better than FAB because it utilizes madVR isn't a reason to dismiss it imo. I know FAB automounts iso's. I'm unclear about your jRiver abilities? In one statement you said you use HDR menus when you need to and in another you say you've never tried it? But as you said, let's not get off topic.

[Manni]

That's a bold statement to say DVDFab Media Player v.3 is really buggy. I've been using it for quite a while. I don't have any problems? It also produces a pretty decent picture for HDR since its chroma upscaling is good and since luma makes no difference for UHD HDR especially when passing through. Not that I use it exclusive. I still prefer madVR renderer with supported players but for those times I want menus...

385.28 video drivers can be beat. You know this yourself. For example, 385.28 driver results in a frame drop every few minutes. 416.81, every 12.75. I'd say that's a fairly significant reason to get away from 385.28.

Not all of us use jRiver. I'm not sure how well it handles UHD HDR menus via an iso or open file structure rips because I'm not familiar with it but to suggest it's better than FAB because it utilizes madVR isn't a reason to dismiss it imo. I know FAB automounts iso's. I'm unclear about your jRiver abilities? In one statement you said you use HDR menus when you need to and in another you say you've never tried it? But as you said, let's not get off topic.

For me any player that doesn't use MadVR is a poorer player, at least that's on topic :)

Yes 3D with 385.28 is not as good as we all know, but that's the only minus, compared to all the downsides of later drivers.

You didn't understand what I said. I said that I don't use the ISO automount in jRiver because I rip to BD folders. I didn't test this feature because I don't need it. I was only saying that it might be an option for you if it worked with your UHD ISOs. Of course I use BD and UHD BD Menus, otherwise why would I mention jRiver as an alternative to DVD Fab in this area?

HDR Passthrough is VERY poor quality on most displays compared to what MadVR's tonemapping can do today. With the dynamic tonemapping and dynamic targets recently developped in test builds with Soulnight's utility, this is the best HDR has ever looked. I have zero desire for HDR10+ or Dolby Vision support anymore. DVDFab player simply can't match this.

Yes, there is no luma upscaling with UHD but that doesn't mean that the tonemapping isn't crucial. You can get the player to do it, or the display. I'd rather have MadVR do it :).

This should be clearer when a new public build of MadVR is released, with some documentation. It's improved leaps and bounds in the last couple of months regarding HDR tonemapping.

But if you're happy with what your display does with static HDR10 metadata, then of course stick with DVD Fab.

Anyway, there is one thing we agree on, it's that this discussion is off topic, especially what concerns the DVDFab player which doesn't support MadVR. :p

So let's leave it there. :)

[Soxbrother]

When I play some mkv inside mediaportal, I get a black screen for about 9 seconds, audio starts after 5 seconds. Any way around this ?

[tp4tissue]

I can't get UHD highlight recovery and dynamic measurement to work on my older win7 7870xt machine.

Does highlight recovery require dx11 on win 10 or something ?

It's running via CPU decode in lav, then madvr.

[el Filou]

When I play some mkv inside mediaportal, I get a black screen for about 9 seconds, audio starts after 5 seconds. Any way around this ?Does the madVR OSD appear during those 4 seconds where there's only audio? Post a screenshot if it does.
It sometimes takes a few seconds for some files to start playing on my system, but it's closer to 3 than 5.

[ashlar42]

compared to what MadVR's tonemapping can do today. With the dynamic tonemapping and dynamic targets recently developped in test builds with Soulnight's utility, this is the best HDR has ever looked. I have zero desire for HDR10+ or Dolby Vision support anymore.Could you provide a link to where this is being discussed? :thanks:

[Stereodude]

Could you provide a link to where this is being discussed? :thanks:
https://www.avsforum.com/forum/24-digital-hi-end-projectors-3-000-usd-msrp/2954506-improving-madvr-hdr-sdr-mapping-projector.html

[Warner306]

HDR Passthrough is VERY poor quality on most displays compared to what MadVR's tonemapping can do today. With the dynamic tonemapping and dynamic targets recently developped in test builds with Soulnight's utility, this is the best HDR has ever looked. I have zero desire for HDR10+ or Dolby Vision support anymore. DVDFab player simply can't match this.

I can agree that the tone mapping has improved by leaps and bounds, but you are often forgetting the experience of flat panel TV owners with displays that have a peak brightness of 700 nits to 2500 nits. Converting to SDR requires a seperate picture mode, which usually has to be selected manually, and some help from the display. An OLED will only get you as far 400 nits in SDR, kind of negating some of the benefits of dynamic tone mapping designed to reduce unnecessary losses in luminance. Not many would survive SDR at 400 nits, and almost no one would survive SDR at 1,000 nits without a suntan. So I don't agree that everyone should give up on HDR passthrough. Many of the bright flat panels with dynamic tone mapping do very little tone mapping at all in HDR mode because of its high peak brightness.

Projectors are almost universally static and poor at tone mapping, but the newest flat panels are actually not bad at all. The OLEDs from LG, Sony, Panasonic and Phillips all use dynamic tone mapping and are compared regularly to the Sony BVM OLED mastering monitor with great accuracy in many cases. I'm betting the image coming from madVR would be sharper, but the newest flat panels aren't doing a poor job of tone mapping. Even bright LEDs are starting to leverage the same dynamic HDR10 tone mapping from the OLEDs.

Those with a bright flat panel would probably want to output in an HDR format from madVR via its internal tone mapping or through the tone mapping by the TV. Not using HDR mode when your display with dynamic tone mapping is able to avoid most tone mapping for the majority of many movies because of its high peak brightness doesn't make much sense if you are going to convert to SDR and tone map heavily for every movie. You are just making HDR darker than it needs to be to use a better tone mapping algorithm. And the newest solutions from LG, Panasonic and Sony are known to be high-quality. Samsung is even adding dynamic tone mapping to its LEDs this year.

The lay of the land for HDR is very different for projectors and flat panel TVs. Projectors are way behind TVs when it comes to dynamic tone mapping and color accuracy. You would want accurate metadata when outputting in an HDR format with madVR's pixel shaders or for any display that uses this metadata to set the peak for the tone curve.

[Manni]

Good point, at least for the displays that can reach more than 1000nits in HDR and support dynamic tonemapping with HDR10 content (not many). I keep forgetting indeed how poorly designed flat panels are in that they don't allow to reach peak brightness in a non HDR mode. I guess in that case users are stuck with a driver that can passthrough the correct metadata, until MS/nVidia/Madshi can correct this. Here, only 385.28 allows this, although 388.16 (the default driver installed by MS when detecting the GPU) seems to passthrough metadata correctly too, contrary to what I reported yesterday. Some are reporting more recent drivers working with passthrough, it might be dependent on GPU models and bit depth.

However, if I had an OLED in a dedicated room, I would much rather use MadVR's dynamic tonemapping and dynamic targets with a peak brightness of 400nits than the display's static tonemapping at 600nits+. So I stand by what I said, which applies to most current displays.

If there are displays that do dynamic tonemapping and dynamic targets with HDR10 content (given that HDR10+ isn't supported on UHD Bluray), I'd like to know which ones, because I'm not aware of any, although that's probably off topic.

[iSeries]

Here, only 385.28 allows this, although 388.16 (the default driver installed by MS when detecting the GPU) seems to passthrough metadata correctly too, contrary to what I reported yesterday. Some are reporting more recent drivers working with passthrough, it might be dependent on GPU models and bit depth

Is there any obvious way to know if the driver is sending incorrect metadata? I mean like the picture being obviously 'wrong'. I'm using 416.34 and it seems to work well, but now I'm reading that this incorrect metadata issue has been present for a while even before this version.

[Manni]

Is there any obvious way to know if the driver is sending incorrect metadata? I mean like the picture being obviously 'wrong'. I'm using 416.34 and it seems to work well, but now I'm reading that this incorrect metadata issue has been present for a while even before this version.

If your display doesn't report the metadata, then no, you need a device such as the HD Fury Vertex.

You could install 385.28 and see if you get any improvements on your display. If you don't you can always go back to a more recent driver.

There is a thread (https://forum.doom9.org/showthread.php?t=176013) about drivers versions reporting that some users do get metadata passthrough with recent drivers including 417.71. It's not the case here.

[nevcairiel]

However, if I had an OLED in a dedicated room, I would much rather use MadVR's dynamic tonemapping and dynamic targets with a peak brightness of 400nits than the display's static tonemapping at 600nits+. So I stand by what I said, which applies to most current displays.

My concern with such a setup is that one doesn't only play HDR content. So somehow I need to flip the screen between different brightness between SDR and HDR. Even if I get madVR to process SDR content to lower its brightness, the players user interface still remains a problem, somehow need to select a movie to play. :)

As far as I know, this is still a mostly unsolved problem. Personally, I really like stuff that "just works" once its all setup. :)

[Soxbrother]

Does the madVR OSD appear during those 4 seconds where there's only audio? Post a screenshot if it does.
It sometimes takes a few seconds for some files to start playing on my system, but it's closer to 3 than 5.

No, nothing appears on screen.
I'll post info of my system.
As far as I know I'm using the latest version of MadVR and upscaling set to dvxa2, other settings I'll have to check.
I'm using a HP Pavilion 300-030nb with Intel HD Graphics 4400 onboard and 4gb Ram and i3 processor.
I did found something with google and other people had the same problem and submitted a bug report. Someone said a previous version didn't have the problem. But the page I found was from the beginning of 2018. So we are many versions past that.

[Manni]

My concern with such a setup is that one doesn't only play HDR content. So somehow I need to flip the screen between different brightness between SDR and HDR. Even if I get madVR to process SDR content to lower its brightness, the players user interface still remains a problem, somehow need to select a movie to play. :)

As far as I know, this is still a mostly unsolved problem. Personally, I really like stuff that "just works" once its all setup. :)

True, if your display doesn't allow to have two different user modes, one for SDR, one for tonemapped HDR, and switch automatically according to content, then it can be a problem.

It is fully solved here because I have one Rec-709/BT1886 calibration with peak brightness at 50nits for SDR content, and one BT2020/Gamma 2.2 calibration with peak brightness at the PJ's max (at the moment around 100nits) for tonemapped HDR.

I use the BT2020 flag in the calibration tab to tell the Vertex when SDR BT2020 content (HDR tonemapped by MadVR) is being sent, and it selects automatically the SDR BT2020 calibration with brightest settings.

When the content goes back to SDR Rec-709, the correct calibration is selected, with best contrast and lower black floor.

This works automatically with any player, MPC-BE, MyMovies, jRiver, because it's triggered by the content being played, not by the player itself.

The Vertex also selects a specific calibration for 3D, x.v.color, HDR10 (HDR passthrough) and HLG, when I use sources that support this.

True, it needs a display that support RS-232, but it's completely transparent for any user here, including my 3 year old daughter, so it just works once it's set-up. :)

Thanks again to Madshi by the way for implementing this BT2020 flag in the SDR metadata. It makes a huge difference from a user experience point of view.

[iSeries]

You could install 385.28 and see if you get any improvements on your display.

Thanks - unfortunately custom resolutions with this driver version don't work well for me. I can't seem to get any good timings with it.

[Warner306]

If there are displays that do dynamic tonemapping and dynamic targets with HDR10 content (given that HDR10+ isn't supported on UHD Bluray), I'd like to know which ones, because I'm not aware of any, although that's probably off topic.

All of the current gen OLEDs from LG, Sony, Panasonic and Phillips apply dynamic tone mapping to HDR10 content. They are all using the same panels and are starting to look more and more identical with each passing year as they copy each other. As stated, Samsung is supposedly adding dynamic tone mapping to its QLEDs this year.

This would have been a good time for JVC to get into dynamic tone mapping because projectors do the most tone mapping of any current displays. They probably shouldn't have put it off for another possible generation when the technology is already available.

[blu3wh0]

I've found that the best middle ground for OLEDs is to use the madVR tone mapping with pixel shaders outputting in HDR for a peak of 700 nits. SDR loses too much peak brightness for HDR (400 nits max) and the LG dynamic tone mapping can actually completely destroy dark scenes since it raises the overall black level. See the 2001 Space Odyssey star scene and watch as stars disappear with dynamic tone mapping. There are also some differences in color between LG and madVR, where I think madVR looks more correct. LG's dynamic tone mapping also handles 4000 nit movies rather poorly, at least on my B7. Whether there is a double tone mapping effect between madVR and the LG for this config, I don't know, but it clearly looks more accurate doing this.

[Warner306]

The raised blacks in the 2017 LGs have been documented. You need a 2018 model to get the newest dynamic tone mapping with a more neutral reference white. It wouldn't be surprising, either, if they were still handling gamut mapping less accurately. But you have to watch for double processing when madVR hands off to the TV. It is good to use an external reference such as the SDR Blu-ray to ensure madVR and the TV work harmoniously together and don't cause any unwanted shifts to the color.

Pixel shader would probably work really well with LEDs that reach 1,000 to 1,500 because they tend to ignore the highlights in the brightest movies in a favour of a gentle roll-off. It would be beneficial to bring that very bright detail back without making the overall image any darker.

[Manni]

All of the current gen OLEDs from LG, Sony, Panasonic and Phillips apply dynamic tone mapping to HDR10 content. They are all using the same panels and are starting to look more and more identical with each passing year as they copy each other. As stated, Samsung is supposedly adding dynamic tone mapping to its QLEDs this year.

This would have been a good time for JVC to get into dynamic tone mapping because projectors do the most tone mapping of any current displays. They probably shouldn't have put it off for another possible generation when the technology is already available.

Dynamic tonemapping is old school, that's what we were doing last year :)

I asked for dynamic tonemapping *and* dynamic targets with HDR10 (what you can currently achieve with MadVR's test build and Soulnight's utility). AFAIK no display currently does this.

JVC offers the best OEM tonemapping on projectors currently with their new models. That covers basic needs that work out of the box in most situations.

Those who want better results have a few options, namely MadVR and Lumagen.

I don't think projectors will ever keep up with these, so I'm not expecting anything special from any display manufacturer.

[j82k]

I really don't get why people keep praising LG's dynamic tone mapping. It's terrible and I don't ever use it. It behaves almost like a dynamic contrast setting where it brightens up most non-bright scenes that wouldn't need any tone mapping at all. I guess a more fitting term would be "bright room mode" instead of dynamic tone mapping.


Is there any obvious way to know if the driver is sending incorrect metadata? I mean like the picture being obviously 'wrong'. I'm using 416.34 and it seems to work well, but now I'm reading that this incorrect metadata issue has been present for a while even before this version.

The LG C8 actually uses different 20 point white balance adjustment points when sending 4000 nits metadata compared to 1000 nits.
I don't know the exact numbers on top of my head but with 1000 nits metadata the second last adjustment point is 6XX and with 4000 nits metatdata it's 7XX.

So that's a good way to check if metadata is sent correctly I guess.

[el Filou]

I'm using a HP Pavilion 300-030nb with Intel HD Graphics 4400 onboard and 4gb Ram and i3 processor.What is your screen definition? 4 GB isn't a lot for madVR with integrated graphics. Depending on the settings, VRAM usage can already take around 500 MB even for 1080p. 4K would take a bit more than 2 GB, leaving less than 2 GB for the OS and applications. Maybe your system is struggling from lack of RAM?

[SamuriHL]

Good point, at least for the displays that can reach more than 1000nits in HDR and support dynamic tonemapping with HDR10 content (not many). I keep forgetting indeed how poorly designed flat panels are in that they don't allow to reach peak brightness in a non HDR mode. I guess in that case users are stuck with a driver that can passthrough the correct metadata, until MS/nVidia/Madshi can correct this. Here, only 385.28 allows this, although 388.16 (the default driver installed by MS when detecting the GPU) seems to passthrough metadata correctly too, contrary to what I reported yesterday. Some are reporting more recent drivers working with passthrough, it might be dependent on GPU models and bit depth.

However, if I had an OLED in a dedicated room, I would much rather use MadVR's dynamic tonemapping and dynamic targets with a peak brightness of 400nits than the display's static tonemapping at 600nits+. So I stand by what I said, which applies to most current displays.

If there are displays that do dynamic tonemapping and dynamic targets with HDR10 content (given that HDR10+ isn't supported on UHD Bluray), I'd like to know which ones, because I'm not aware of any, although that's probably off topic.

My C8 does dynamic tone mapping. I combine it with madvr's and set a target of 700. What little tonemapping that needs to be done is done by madvr and passed to the tv. In theory the TV's dynamic tonemapping wouldn't need to do anything because it should be under the max nits for the display. This is what I've been using for a while now and absolutely love the results I get.

EDIT: Yes, I see your reply about dynamic targets above...

[SamuriHL]

I've found that the best middle ground for OLEDs is to use the madVR tone mapping with pixel shaders outputting in HDR for a peak of 700 nits. SDR loses too much peak brightness for HDR (400 nits max) and the LG dynamic tone mapping can actually completely destroy dark scenes since it raises the overall black level. See the 2001 Space Odyssey star scene and watch as stars disappear with dynamic tone mapping. There are also some differences in color between LG and madVR, where I think madVR looks more correct. LG's dynamic tone mapping also handles 4000 nit movies rather poorly, at least on my B7. Whether there is a double tone mapping effect between madVR and the LG for this config, I don't know, but it clearly looks more accurate doing this.

I agree, it definitely is an improvement even if there is a "double tonemapping" effect going on. And that's exactly how I drive my setup and it's been amazing so far!

[blu3wh0]

I agree, it definitely is an improvement even if there is a "double tonemapping" effect going on. And that's exactly how I drive my setup and it's been amazing so far!

I suggest you don't use LG's dynamic tone mapping at all, as I mentioned above, it does much more harm than good. I used it in the beginning as well because I had to in order to watch 4000 nit content at all before madshi fixed the HDR output for pixel shaders, but it's definitely not needed now.

[SamuriHL]

I've gone back and forth on that one. madshi theorized that with dynamic on it wouldn't need to do as much of its own tone mapping on top of what madvr does. With the latest LG firmware they fixed a few of the issues I saw so it's definitely better, but, I'll do some more testing with it off and see if there's a big difference.

[Warner306]

I really don't get why people keep praising LG's dynamic tone mapping. It's terrible and I don't ever use it. It behaves almost like a dynamic contrast setting where it brightens up most non-bright scenes that wouldn't need any tone mapping at all. I guess a more fitting term would be "bright room mode" instead of dynamic tone mapping.

Dynamic tone mapping is supposed to look similar to this. Scenes that are below the source peak get some relief from tone mapping, which will make them appear brighter as they follow PQ curve more closely. The other scenes that seem darker are probably being tone mapped. The 2018 models should be following the PQ curve in the 0-100 nits region, mostly to fix the raised blacks issue from the 2017 models. They are known to track the curve properly from the factory.

I would think you would get the best results by leaving dynamic tone mapping enabled. Using a static curve will provide no relief from tone mapping for the entire movie. This would only make sense if the display disabled its tone mapping when confronted with metadata that indicates the source is within the display's brightness. But dynamic tone mapping should already do this without needing any metadata.

I've seen some spectacular HDR on a 2018 LG OLED, so I have no reason to bash it's tone mapping.

[SamuriHL]

That's why I currently have it enabled in my setup. There was some DEFINITE issues in previous firmware versions that seem to be fixed now. Since then I've not seen any real issues with dynamic enabled and using madvr tonemapping set to a 700 target nit. It looks fantastic to me. But then again, I don't proclaim to be an expert in this area. I'm still constantly learning and I've been playing with this since last summer.

[Soxbrother]

What is your screen definition? 4 GB isn't a lot for madVR with integrated graphics. Depending on the settings, VRAM usage can already take around 500 MB even for 1080p. 4K would take a bit more than 2 GB, leaving less than 2 GB for the OS and applications. Maybe your system is struggling from lack of RAM?

Watching on a 4k tv. Resolution off course is set to 3840×2160 on a Samsung UE55JS9000.
In MadVR I've set the scaling settings to 1080p23

It's only the beginning of the file that has a delay, the rest plays normal. If my system would struggle, shouldn't it struggle with the whole file ? Weird that it struggles in the beginning of it then.

Then I would rather have it that after the delay it starts playing from 00:00:00 audio and video.
Now it's audio after 5s and audio+video after 10s

[huhn]

you are changing the refreshrate and the resolution by doing this your TV has to "resync"(it's the wrong word but whatever) and the time this takes is defined by your TV maybe AVR not really madVR.

a normal PC monitor can do this in about a sec or even less. TV and even worse projectors can take a long time like 5-20 secs.

a workaround would be leaving the screen at 1080p23
using a player that can start a file paused and enter fullscreen before you play.

using FSE can add even more blackscreen.

[Soxbrother]

you are changing the refreshrate and the resolution by doing this your TV has to "resync"(it's the wrong word but whatever) and the time this takes is defined by your TV maybe AVR not really madVR.

a normal PC monitor can do this in about a sec or even less. TV and even worse projectors can take a long time like 5-20 secs.

a workaround would be leaving the screen at 1080p23
using a player that can start a file paused and enter fullscreen before you play.

using FSE can add even more blackscreen.

Ok. Thanks for the info.

So I guess Mediaportal doesn't have such a function then ?

Anyway here's the link to the exact problem I have.
And people saying with another version they didn't have the problem.

http://bugs.madshi.net/view.php?id=479

[huhn]

did you try something simply like disabling FSE?

[j82k]

Dynamic tone mapping is supposed to look similar to this. Scenes that are below the source peak get some relief from tone mapping, which will make them appear brighter as they follow PQ curve more closely. The other scenes that seem darker are probably being tone mapped. The 2018 models should be following the PQ curve in the 0-100 nits region, mostly to fix the raised blacks issue from the 2017 models. They are known to track the curve properly from the factory.

I would think you would get the best results by leaving dynamic tone mapping enabled. Using a static curve will provide no relief from tone mapping for the entire movie. This would only make sense if the display disabled its tone mapping when confronted with metadata that indicates the source is within the display's brightness. But dynamic tone mapping should already do this without needing any metadata.

I've seen some spectacular HDR on a 2018 LG OLED, so I have no reason to bash it's tone mapping.

Not sure I'm getting what you're trying to say. Isn't tonemapping only needed because of TVs having a too low peak brightness?
As far as I know mastering monitors don't do any tonemapping, so non-bright scenes should look similar to what I see with dynamic tonemapping disabled.
Then why would it be a good thing to brighten up darker scenes?

I did a small test to see how much LGs dynamic tonemapping messes with non-bright scenes.
I just displayed a 50 nits movie scene in the background while running a grayscale sweep in HCFR.
The result shows exactly what my eyes have been seeing when using LGs dynamic tonemapping. Large deviations from the PQ, even in the lower range. With it turned off it at least follows it nicely up to like 125 nits.

https://i.imgur.com/Z7A9aTz.png

[Soxbrother]

did you try something simply like disabling FSE?

I've just checked and it's disabled already, so that is not the solution.

I'm going to try if this maybe make a difference :

In the Devices section under the "Generic PnP Monitor", you can choose "Display modes"
and the current setting is : Switch to matching display mode...when playback starts

So maybe it makes a difference when I choose ...when media player goes fullscreen ?

I'll try it in a moment and will post the result

For now I'll leave the "restore original display mode...when mediaplayer is closed" as it is.

I've just checked and I'm using MadVR 0.92.17, that's the latest version, right ?


Update : Nothing changed, I had hoped, that would do something :)

[Soxbrother]

I've adjusted the resolution of my 4ktv to 1920x1080, now the video starts almost instantly.
I've also disabled the "Switch to matching display mode" setting, because it has no use now.

But now I'm wondering if the video would look better at it's native 1080p resolution
or if it would look better even on the 4k resolution.

Any thoughts on that ?