madVR - high quality video renderer (GPU assisted)

[huhn]

openGL is not limited to 8 bit processing it's 32 bit: https://www.khronos.org/opengl/wiki/Image_Format

but as always these open standarts are to open same counts for vulkan:

The OpenGL specification is fairly lenient about what image formats OpenGL implementations provide. It allows implementations to fall-back to other formats transparently, even when doing so would degrade the visual quality of the image due to being at a lower bitdepth.

and it doesn't matter both output RGB and the RGB values in madVR are correct. if you want more "color" think about the vivid mode on your end device.

[Warner306]

Ok, so I don't know what technological limitations are limiting rendering in Kodi.

I have nothing against Kodi. I just think its video rendering needs to be updated to keep up with the times. I thought OpenGL standards were to blame.

[tp4tissue]

Hi guys, recently took off the lazy hat and setup 3dlut through display cal

How do I verify the output with madvr// madtpg ?

The profile is installed into madvr and as far as I can tell, the color correction is working when videos play but I don't see a test tab anywhere.

[Asmodian]

I like ColorHCFR (https://sourceforge.net/projects/hcfr/). Simply measure your color space with the 3DLUT enabled in madTPG.

[ryrynz]

This is why i prefer OpenGL render.


if you want more "color" think about the vivid mode on your end device.

Or better perhaps add a few points to madVR's saturation levels + any of the various sharpeners available (I find Adaptive sharpen rather nice) and your own displays color settings.

You're better off using madVR to get the picture you want, rather than relying on a renderer that's clearly deviating from the original image by default.

[suanm]

OpenGL or D3D do not have an impact on the image quality - it all depends on the algorithms you use to process the image. I'm not madshi, but I think I can safely state that madVR will never use OpenGL.
Master,why will madshi never integrate OpenGL in madVR ?
To be honest I'm not good at the technologies about video, processing algorithms,renderer and so on.I only use potplayer to play 4K HDR or 1080p movies on my TV set.
BY the way,Could you build any ***.zip instead of ***.exe in nightly version about LAV files?

[suanm]

Or better perhaps add a few points to madVR's saturation levels + any of the various sharpeners available (I find Adaptive sharpen rather nice) and your own displays color settings.

You're better off using madVR to get the picture you want, rather than relying on a renderer that's clearly deviating from the original image by default.
Thank you,i try to do this as you said above.

[Sebastiii]

Thank you @madshi for the new release :)

[stefanelli73]

That said, the HDR output should probably be set to BT.2020 as you found. Almost everything HDR is encoded in the very wide BT.2020 color space so I think most displays do better mapping when receiving BT.2020.

But there is also to say that no TV or vpr, currently, sufficiently covers the color space BT.2020 (for example my vpr OPTOMA UHZ65 covers it at 56%), while there are some displays that cover the DCI-P3 to 100% .... then also in Madvr in the information says "BT.2020> DCI-P3", so "in this dispalay is already calibrated" would not it be fair to use DCI-P3?

[LigH]

Master,why will madshi never integrate OpenGL in madVR ?

3D APIs are just different ways to the same goal: Graphic card internal features. DirectX under Windows is a more direct way there (and there may be even shorter paths), OpenGL under Windows rather a detour in comparison. The advantage of OpenGL is portability across different operating systems; that's not important for a DirectShow renderer which will work only under Windows anyway.

[suanm]

3D APIs are just different ways to the same goal: Graphic card internal features. DirectX under Windows is a more direct way there (and there may be even shorter paths), OpenGL under Windows rather a detour in comparison. The advantage of OpenGL is portability across different operating systems; that's not important for a DirectShow renderer which will work only under Windows anyway.
I got it,thank you,master.OpenGL would rather make a detour to the final goal.D3D11 can take a shortcut to the final goal,instead.That also means both d3d11 and openGL actually are not different for the final image quality except processing algorithm. May i think so?
i will keep doing the test with madVR on 4K HDR and 1080p movies till i get some best color images

[Warner306]

But there is also to say that no TV or vpr, currently, sufficiently covers the color space BT.2020 (for example my vpr OPTOMA UHZ65 covers it at 56%), while there are some displays that cover the DCI-P3 to 100% .... then also in Madvr in the information says "BT.2020> DCI-P3", so "in this dispalay is already calibrated" would not it be fair to use DCI-P3?

This is really not clear. Some users report correct colors with DCI-P3. Others report correct colors with BT.2020. If you report BT.2020, then gamut mapping might be unnecessary as the source input is already BT.2020. It is unclear if BT.2020 is a container in madVR like it is reported in the OSD or if the source is mapped to BT.2020 primaries. If it is a container, then DCI-P3 and BT.2020 should produce the same results, unless the BT.2020 mapping goes over the DCI-P3 limit.

One user pointed out it may be safer to select BT.2020 because the display expects a BT.2020 container.

[Warner306]

Target nits is completely up to preference and experimentation. Increasing the peak nits value has a similar effect to increasing the gamma; the image gets progressively darker. This is because the tone mapping is more gradual in the transition from dark to light. The result is more contrast and dynamic range. So you should aim for the highest peak nits value you can use without crushing black. This will produce more highlights and a greater HDR effect. A properly calibrated HDR display should be a little darker than SDR without crushing shadow detail.

I read a post that better explains target nits than the post above.

The closer to the display's actual peak nits, the more the top end is compressed leaving 0 to 100 nits pixels as close to normal as possible. At higher target nits, the more the low end is compressed creating black crush at 0 to 100 nits but adding more highlight detail at the top end. So you are creating more space for specular highlights by choosing a higher peak nits value at the expense of shadow detail.

That is probably a simpler way to think of things.

[stefanelli73]

This is really not clear. Some users report correct colors with DCI-P3. Others report correct colors with BT.2020. If you report BT.2020, then gamut mapping might be unnecessary as the source input is already BT.2020. It is unclear if BT.2020 is a container in madVR like it is reported in the OSD or if the source is mapped to BT.2020 primaries. If it is a container, then DCI-P3 and BT.2020 should produce the same results, unless the BT.2020 mapping goes over the DCI-P3 limit.

One user pointed out it may be safer to select BT.2020 because the display expects a BT.2020 container.

Perhaps I found the answer to our doubts, read the post from nr. 112:
http://www.avsforum.com/forum/26-home-theater-computers/2880609-madvr-hdr-passthrough-isn-t-working-4.html

[Manni]

This is really not clear. Some users report correct colors with DCI-P3. Others report correct colors with BT.2020. If you report BT.2020, then gamut mapping might be unnecessary as the source input is already BT.2020. It is unclear if BT.2020 is a container in madVR like it is reported in the OSD or if the source is mapped to BT.2020 primaries. If it is a container, then DCI-P3 and BT.2020 should produce the same results, unless the BT.2020 mapping goes over the DCI-P3 limit.

One user pointed out it may be safer to select BT.2020 because the display expects a BT.2020 container.

It's not clear because Madshi for some reason doesn't want to change the way he reports the information (I respect whatever his reasons are, but it's just really confusing).

MadVR reports the information in the OSD as BT2020 -> DCI-P3, which suggests that the content is converted to P3. It's not. What it means is that the container is BT2020, but the content doesn't go further than P3. It's the -> sign that makes it confusing, because it suggests a conversion, as when MadVR converts it uses the > sign to signal it. I suggested to Madshi to report it differently to avoid such confusion a long time ago, maybe as BT2020 [DCI-P3] or BT2020 (DCI-P3) or whatever wouldn't suggest a conversion. The DCI-P3 here only reports the mastering monitor capability (i.e. the content doesn't go further than P3), not the way the content is conveyed, which is BT2020.

From a calibration point of view, there is no consumer content in DCI-P3. It's rec-709 or BT2020.

So if you don't do any conversion, your display should be calibrated to BT2020 (saturations), which doesn't mean that it has to reach BT2020. Most consumer displays do not go further than DCI-P3, but they still have to be calibrated to BT2020 to display say UHD Bluray content properly, for example with a UHD Bluray player.

What MadVR allows you to do though is to convert any content to the maximum capability of your display. For example, if your display can only reach DCI-P3, instead of creating a BT2020 calibration that will reach say 65% of BT2020, you'll create a DCI-P3 calibration that will reach 100% (or close) of DCI-P3. It should result in the same picture, as long as what the display expects matches what MadVR sends.

Overall, it goes like this:

During grading, the colorist usually has a DCI-P3 able monitor, so grades up to DCI-P3. But because DCI-P3 is only a stepstone towards the full gamut, it's wrapped into a BT2020 container. That way, UHD Bluray content needs only one calibration, and can display content graded in Rec-709, DCI-P3 or BT-2020 using the same container/calibration.

Usually, the source will send BT2020 without conversion, so if you want to use the same calibration for your UHD Bluray player and MadVR, you should use a BT2020 calibration.

If, however, you only use MadVR as a source, or you're happy to have a different calibration for MadVR, or if your display is old and doesn't have a BT-2020 mode, then you can create a DCI-P3 calibration and ask madVR to convert the BT2020 content into DCI-P3. But you have to specify this in the calibration tab.

In conclusion, you should specify in the calibration tab the calibration used on your display. If you don't know what it is, you have to measure it or decide what looks more right. The content is always BT2020 and always expect a BT2020 calibration (even when it was graded on a DCI-P3 monitor, as reported in the OSD), unless you tell MadVR that your display is calibrated to DCI-P3 or Rec-709.

A BT2020 calibration allows to display the content as is (if we're talking about UHD Bluray).

A DCI-P3 or Rec-709 calibration requires a conversion.

I hope it's clearer!

I read a post that better explains target nits than the post above.

The closer to the display's actual peak nits, the more the top end is compressed leaving 0 to 100 nits pixels as close to normal as possible. At higher target nits, the more the low end is compressed creating black crush at 0 to 100 nits but adding more highlight detail at the top end. So you are creating more space for specular highlights by choosing a higher peak nits value at the expense of shadow detail.

That is probably a simpler way to think of things.

This is not correct.

The way it works is as follow:

If your display isn't able to display 10,000nits, or rather if the content goes above the capability of your display, you need to tonemap. The lower your display actual peakY, the more you have to compress highlights.

If your display is a 1500nits LCD, there is very little compression, so you'll get both good highlights and good near black resolution.

However, as the actual peakY of your display goes down, you have to compress highlights more and more, and because of the way MadVR does it, it goes against resolving the low end.

So if you have a bright display, you can probably tell your actual peakY. But if you have a projector, you have to lie to leave some room for highlights.

Hopefully at some point this will change so that MadVR can both reproduce the low end of dim titles and the highlights of bright titles with the same parameters.

At the moment, if your display is less than at least an OLED at 500-600nits actual peakY, then you probably have to lie.

In order to decide which parameter to use, you have to test both very dim 1000nits titles (for example some scenes in The Revenant) and some very bright 4000nits titles with highlights going to 4000nits and more (Life, Mad Max, Batman vs Superman etc).

You should find a parameter that reproduces the low end of dim titles satisfactorily and yet doesn't clip too much the highlights of bright titles, or you should use profiles (soon to be automated when Madshi implements a new field to test the content's max brightness).

For example, on my JVC PJ with an actual peakY of 120nits in low lamp/iris open, I have to use a target nits of around 500nits to get a decent compromise for both.

[Warner306]

From a calibration point of view, there is no consumer content in DCI-P3. It's rec-709 or BT2020.

Yes, it was you that recommended BT.2020. As long as the input is not converted to color values wider than the source, then it is like selecting passthrough. The conversion to DCI-P3 should result in the same outcome, though, if your display only covers a percentage of DCI-P3. It's just madVR that adjusts the saturations, not the display. The display could make an error, though, if it is expecting BT.2020 primaries.



This is not correct.

The way it works is as follow:

Yes, got that, too. The quote came from madshi:



If you actually tell madVR the proper peak Nits value that you measure your display as, all the pixels in the lower Nits range (ideally from 0-100 Nits) are displayed absolutely perfectly, in the same way a true 10,000 Nits display would show them. Tone mapping only starts somewhere above this lower Nits range. However, we can't simply jump abruptly from 0 compression to strong compression, so the tone mapping curve needs to start smoothly, otherwise the image would get a somewhat unnatural clipped look. Practically, if you set madVR's peak luminance value to 200 Nits, the tone mapping curve starts compressing pixels at 23 Nits. If you set madVR's peak luminance value to 400 nits, the tone mapping curve starts compressing at 75 Nits.


If you enter the measured Nits value, the top end is heavily compressed. You don't like that. If you enter a much higher than measured Nits value, the bottom end becomes too dark (= compressed in a sense). You don't like that. So if you don't like compression at the top end and not at the bottom end, where should be compress instead?

So you are saying, at a certain nits value (say 1,000 nits), you no longer have to lie because the top end will not be compressed that badly. So most users will have to lie?

This is just madVR jargon, not how it should work in a practical way. madshi mentioned he wanted to leave the peakY value to imply the actual measured peak nits and leave the decision on how to tone map to madVR. That will make tone mapping much more useful for the average user.

[Manni]

Yes, it was you that recommended BT.2020. As long as the input is not converted to color values wider than the source, then it is like selecting passthrough. The conversion to DCI-P3 should result in the same outcome, though, if your display only covers a percentage of DCI-P3. It's just madVR that adjusts the saturations, not the display. The display could make an error, though, if it is expecting BT.2020 primaries.

You have to make a distinction between the native capability of the display and calibration.

Regarding calibration, you can calibrate a rec-709 display or a DCI-P3 display to BT2020. It simply will display up to its capabilities, and then it will clip (unless there is some tonemapping applied) if the content goes further than that.

So you can send BT2020 content to a rec-709, DCI-P3 or BT2020 display, as long as it's calibrated to BT2020.

If it's calibrated to its native capability (be it rec-709 or DCI-P3), then you have to convert the UHD Bluray content, because it will be using a BT2020 container, irrespective of the limitations of the mastering monitor.



Yes, got that, too. The quote came from madshi:


The problem with the current approach is that you can't reproduce 0-100nits as is (1:1) for displays that have 100nits or less, which is most projectors, or there is no room for highlights. For projectors, you need something like 2:1 or even 3:1 for the dimmest ones (less than 50nits peak brightness), then you start rolling off.

We'll be working on improving this later but Madhsi has asked to focus on getting color right for now.


So you are saying, at a certain nits value (say 1,000 nits), you no longer have to lie because the top end will not be compressed that badly. So most users will have to lie?

This is just madVR jargon, not how it should work in a practical way. madshi mentioned he wanted to leave the peakY value to imply the actual measured peak nits and leave the decision on how to tone map to madVR. That will make tone mapping much more useful for the average user.

This is NOT the way it works in the current build. It was possible to do this in the test builds because we could specify diffuse white, but now that Madshi has taken diffuse white away, most people - especially projectors owners with less than 500-600nits actual peakY) have to lie.

This is why Madshi is now calling that field "target nits" and not "actual display peak brightness", because it's simply a virtual value.

If you enter the actual brightness of your display, you will be able to show HDR content with no highlights pretty well (although the picture will likely be too bright, HDR shouldn't be brighter than SDR most of the time), but as soon as content goes above say 200nits you'll be in trouble.

I'm sure Madshi will explain when he has the time to post, but as he's super busy at the moment I'm just trying to clarify what users should expect.

Target nits is NOT the actual peakY of the display in most cases, especially displays dimmer than say a 600nits OLED, and the content is ALWAYS BT2020 when MadVR reports BT2020, even when there is a "->DCI-P3", which only means that the mastering monitor was limited to DCI-P3, hence content won't exceed DCI-P3, but by default a BT2020 calibration and saturations is expected to display the content properly, unless you specify a different calibration in the calibration tab, but in that case the display should be calibrated to whatever you specify, and MadVR will take care of the rest.

[Warner306]

If it's calibrated to its native capability (be it rec-709 or DCI-P3), then you have to convert the UHD Bluray content, because it will be using a BT2020 container, irrespective of the limitations of the mastering monitor.

Yes, as long as BT.2020 calibration is 1:1 with the source values, then you have no problems with clipping. You are probably right.



The problem with the current approach is that you can't reproduce 0-100nits as is (1:1) for displays that have 100nits or less, which is most projectors, or there is no room for highlights. For projectors, you need something like 2:1 or even 3:1 for the dimmest ones (less than 50nits peak brightness), then you start rolling off.

I don't think diffuse white helps anything if you don't know what diffuse white means. But the concept of adjusting white does make more sense in the context of what the tone mapping seems to be doing - it is crushing diffuse white with increased intensity to make room for spectral highlights.

Maybe target nits should be called compression ratio and show the peakY with a multiplier?

It sounds like you need to recruit more projector owners to your testing. Based on the screenshots I've seen, I think both "dumb" and "scientific" have a place in madVR and it doesn't matter which is the default. If left two options, most users will try both.

[Manni]

I don't think diffuse white helps anything if you don't know what diffuse white means. But the concept of adjusting white does make more sense in the context of what the tone mapping seems to be doing - it is crushing diffuse white with increased intensity to make room for spectral highlights.

Maybe target nits should be called compression ratio and show the peakY with a multiplier?

It sounds like you need to recruit more projector owners to your testing. Based on the screenshots I've seen, I think both "dumb" and "scientific" have a place in madVR and it doesn't matter which is the default. If left two options, most users will try both.

That's for Madshi to decide. Personally I'd prefer a single mode that works well with everything. At the moment it's a "pick your poison" situation.

Re the target nits parameter, Madshi has specifically asked not to discuss this until color is settled, so please let's not discuss this further. I know what diffuse white means, but most users don't and that's why Madshi took it off. You can get exactly the same results multiplying your actual peakY by your brightness factor (100/ref white), so it's not an issue at all.

I was only trying to clarify how "target nits" works at the moment so that people can try and report what works best with their display and provide the feedback that Madshi has requested at this stage, which is which tonemapping works best. The way target nits works is not ideal, but now isn't the time to discuss how to improve this. :)

[Sunset1982]

nvidia just released driver 397.31. Looks like it got some new features and a new hdmi driver part. hopefully they fixed some bugs and it works better with madvr / hdr than the last versions...

[Manni]

nvidia just released driver 397.31. Looks like it got some new features and a new hdmi driver part. hopefully they fixed some bugs and it works better with madvr / hdr than the last versions...

Thanks. I'll wait until someone confirms they have fixed the video levels...

[brazen1]

Don't bother wasting your time like I just did. This new pos driver still ignored the stereo vs multi channel switch when you turn your AVR on/off. Also ignored no RGB 10 bit setting as usual along with dropped frames every few minutes. I'm beginning to think no one wants us using HTPC's anymore and instead direct us to streaming boxes with limited crap video output and lots of monthly subscription fees instead to help obliterate physical media . Meanwhile, keeping the MSRP on cards through the roof so only gamers want them as miners are diminished and continue to provide lots of driver upgrades for individual games to keep them jubilant and in the market. In the mean time we can continue to sit around for months/years/decades waiting to see if by some miracle any A/V related bone is tossed our direction. As the new Windows update hits the masses, this might turn into a real clusterfluck with even less remedies ever provided. Yep, I'm disappointed..... again.

[Manni]

don't bother wasting your time like i just did. ... Yep, i'm disappointed..... Again.

385.28 :)

[brazen1]

Yep, just DDU reinstalled it for about the 30th time. Still dropped frames and no 10 bit otherwise I'd never upgrade the damn thing.

[Manni]

Yep, just DDU reinstalled it for about the 30th time. Still dropped frames and no 10 bit otherwise I'd never upgrade the damn thing.

I must be lucky, I only have dropped frames with 3D, with 2D at least in UHD I get a dropped frame every hour or so, which is perfectly acceptable.

12bits works fine on my display (pixel shader, not passthrough), so I guess that's luck too as I don't need a 10bits mode. I didn't need it with the UB900 either, but I know many users did.

There is really little incentive for me to upgrade from 385.28, except if one day a new driver made no frame drop in 3D possible.

Did you have a chance to see if the levels are fixed?

[brazen1]

I mean no dropped frames without the need to use madVR custom modes. Yes, I know you could care less about 8, 10, and 12bit offerings since your PJ handles 12bit correctly. I need 10bit passthrough personally and I think a whole bunch of other folks do too unless you like banding. Meanwhile we digress to 8bit after making sure all our equipment was at least 10bit. I don't know what the "levels' you are referring to is?

[Manni]

I mean no dropped frames without the need to use madVR custom modes. Yes, I know you could care less about 8, 10, and 12bit offerings since your PJ handles 12bit correctly. I need 10bit passthrough personally and I think a whole bunch of other folks do too unless you like banding. Meanwhile we digress to 8bit after making sure all our equipment was at least 10bit. I don't know what the "levels' you are referring to is?

Custom modes are needed on nVidia to not have dropped frames, that's been the case forever.

I'm talking about video levels. They are broken in 391.xx. In 390.65, they are inverted (you need to specify 0-255 in MadVR to get limited to the display). 385.28 is the latest fully working driver here.

[huhn]

looks like Samsung doesn't believe in 10 bit and 120 hz at the same time...

http://www.panelook.com/bramodlist.php?st=&pl=&brands[]=115&panel_size_inch=6500

so i recommend you to lay back set it to 8 bit forget this 10 bit garbage and just enjoy.

[LigH]

@suanm:

Don't focus too much on D3D11; madVR does not require D3D11, it will work as well with older graphic hardware, using interfaces which have been specified in earlier generations already (D3D9 / PS3.0).

[Asmodian]

You do need D3D11 for HDR.

[ashlar42]

Ok, so I don't know what technological limitations are limiting rendering in Kodi.

I have nothing against Kodi. I just think its video rendering needs to be updated to keep up with the times. I thought OpenGL standards were to blame.Kodi under Windows uses DirectX (Direct3D), not OpenGL.
The problem with Kodi has to do, unfortunately, with too few Windows developers on board. Being open source, I hoped for quite a long while that somebody would fork it to something Windows only and be done with it. While I applaud the spirit behind some of Kodi's team decisions, for the longest time the Windows release has been reduced to something of an afterthought in many occasions.

The software is free, so they are free to do whatever they want and, certainly, lack of developers is hurting the Windows release.

After the whole DSPlayer debacle with aracnoz (the developer, I know you are familiar with him) being attacked for asking simple questions, I kind of lost faith in the whole thing. It's too bad that nobody is picking up the torch, really (save from aracnoz kindly providing updated builds from time to time).

[Warner306]

Kodi under Windows uses DirectX (Direct3D), not OpenGL.
The problem with Kodi has to do, unfortunately, with too few Windows developers on board. Being open source, I hoped for quite a long while that somebody would fork it to something Windows only and be done with it. While I applaud the spirit behind some of Kodi's team decisions, for the longest time the Windows release has been reduced to something of an afterthought in many occasions.

The software is free, so they are free to do whatever they want and, certainly, lack of developers is hurting the Windows release.

After the whole DSPlayer debacle with aracnoz (the developer, I know you are familiar with him) being attacked for asking simple questions, I kind of lost faith in the whole thing. It's too bad that nobody is picking up the torch, really (save from aracnoz kindly providing updated builds from time to time).

Didn't know that. I think they still rely on the same video player code, but it could be different. The Windows release performs fine for me, but the lone Windows developer is definitely stretched for resources. I do know things are no better on Linux on the video rendering side. I was following the communication between the person in charge of the video player and a frustrated projector user who couldn't use his 3D LUT with Kodi because of the way it downgraded 10-bit BT.2020 inputs. Oddly enough, he left frustrated and left a link to madVR's HDR -> SDR thread at AVS Forums. I don't think he was very charming in his conversation. But he got the message across that he wanted more from Kodi. He probably could have left the madVR link out, though. The video player guy was actually trying to be helpful. Kodi isn't junk software.

Kodi DSPlayer doesn't really need a developer at the moment. It just needs someone to merge the Git to the latest Kodi master. I'll definitely try it myself if aracnoz doesn't provide an update this time. I just don't think I can move the player code around and still keep the player working. It depends on how many code conflicts there are in the already 6,000 new commits in Kodi master. It's more than just a simple merge.

DSPlayer is already a mature player with all the features it needs with new features being added all the time by LAV Filters and madVR. You are one of the users that has been there from the beginning.

[Warner306]

looks like Samsung doesn't believe in 10 bit and 120 hz at the same time...

http://www.panelook.com/bramodlist.php?st=&pl=&brands[]=115&panel_size_inch=6500

so i recommend you to lay back set it to 8 bit forget this 10 bit garbage and just enjoy.

I am a mostly satisfied Samsung 120Hz owner. Granted my older plasma still has a better picture and Samsung is less interesting now that they don't make OLEDs.

Seems like a poor decision from a company that used to be associated with the best image quality in its heyday, taking over the throne from Sony. But, like you said, maybe no one will notice.

[Warner306]

I must be lucky, I only have dropped frames with 3D, with 2D at least in UHD I get a dropped frame every hour or so, which is perfectly acceptable.

12bits works fine on my display (pixel shader, not passthrough), so I guess that's luck too as I don't need a 10bits mode. I didn't need it with the UB900 either, but I know many users did.

There is really little incentive for me to upgrade from 385.28, except if one day a new driver made no frame drop in 3D possible.

Did you have a chance to see if the levels are fixed?

Full -> Full -> Full has been working here for some time. I haven't tried any other configuration. This was verified with test patterns.

[ryrynz]

Seems like a poor decision from a company that used to be associated with the best image quality in its heyday, taking over the throne from Sony. But, like you said, maybe no one will notice.

They know what they're doing..

[Warner306]

Don't bother wasting your time like I just did. This new pos driver...Yep, I'm disappointed..... again.

There is no knowing if anyone has reported these issues to Nvidia. Although, they seem to be so incompetent at not bug testing anything that I wonder if these issues have been reported several driver versions ago and not fixed due to neglect.

[Warner306]

They know what they're doing..

I think so, too. But choices like that make me wonder if they are trying to cut costs to improve margins. If so, I'm not impressed.

[Audionut]

* display peak nits edit control now accepts down to 80 Nits (formerly 120 Nits)

Is it just me or does this control now only accept down to 100 Nits?

It would be nice if this control accepted down to 50 Nits.

edit: The other issue I notice is that SD resolution deinterlaced 25i > 50p content is being displayed at 1080p60, where as HD resolution deinterlaced 25i > 50p is displaying at 1080p75.

Any idea why madvr uses is selecting the 1080p60 display mode for SD?

[ryrynz]

I think so, too. But choices like that make me wonder if they are trying to cut costs to improve margins. If so, I'm not impressed.

It's ALWAYS about margins. Their bet is on MicroLED. You won't see any TV OLED from them for the home market ever.

The other issue I notice is that SD resolution deinterlaced 25i > 50p content is being displayed at 1080p60, where as HD resolution deinterlaced 25i > 50p is displaying at 1080p75.

Any idea why madvr uses is selecting the 1080p60 display mode for SD?

Did it before?

[Audionut]

Did it before?

I'm reasonably positive it did not (with 0.92.12).

[ryrynz]

Easy thing to test my man, to confirm.

[Manni]

Full -> Full -> Full has been working here for some time. I haven't tried any other configuration. This was verified with test patterns.

Doesn't work here on my JVC RS500.

Is it just me or does this control now only accept down to 100 Nits?

It would be nice if this control accepted down to 50 Nits.


In this build diffuse white is set to 100nits. I guess you can't set target nits below diffuse white, which makes sense.

[huhn]

full range is working perfectly here using 397.31.

is your problem related to SDR/HDR/3D all all together?

[Jasch]

Hi Madshi,

want to Report 2 (maybe)"Bugs".

I am using Dvbviewer + Madvr + LAV.(all latest, LAV nightly)
Win10
AMD RX560 latest Driver (Friend has same Problems with RX580)
I am using the Madvr switching Option.
Profiles are: 1080p23, 1080p24, 1080p50, 2160p23, 2160p50, 2160p60

I let Madvr scale to 1080, only 4K i let switch to native.

First Problem:
On LiveTv 1080i50 -> 1080p50 (OSD reports Source 1080 50fps) good .
On records from LiveTv (1080) (OSD says Source 25fps) -> 2160p50 but it should be 1080p50.

Second Problem:
switching to 4K/60Hz
On Hotbird is a 4K Demo Channel 60fps 30Mbit+...
When i switch from 1080x to 2160p60 its working.
When i switch from 2160p50 to 2160p60 its not working, stays on 50Hz(source info 60fps).


Then i have seen another thing, maybe it helps you.

I dont use FSE, because way longer switching Times and Problems with Ambilight(Ambibox does not work all the Time with FSE).
When watching HDR Content, it works most of the Time.(enabling HDR)
When its not work (switching to HDR) the following does the Trick(else only reboot helps).
When playing content with HDR and switch to HDR was not working, i switch Player from Fullscreen to Window mode.
Then i can see in Window mode its HDR.(enable Fullscreen its goes normal..) now open AMD Panel switch from RGB to YUV and back. #
Now Window player is non HDR -> make Fullscreen Player -> HDR working


wbr Alex

[stefanelli73]

385.28 :)

I went from the latest version of the NVIDIA drivers to 385.28, after reading this your post, but as in the previous one I continue to have "1 frame repeated every 5 minutes" and I can not in any way go beyond 5 minutes, even changing the settings in LAV VIDEO or Madvr, any suggestions? I have a GTX1080, first an AMD RX480 and I did not have these problems.

[stefanelli73]

.....I also noticed switching to the 92.14 of Madvr that nell'osd (ctrl + j) the bits always remain at 8 even if you selected 10bit in Madvr is a bug or is it a choice of Madshi?

[huhn]

windowed HDR is limited to 8 bit with nvidia because it is buggy with 10 bit.

10 bit FSE should work fine.

[stefanelli73]

...IN 385.28, but with the last driver this problem is not there, it reads 10bit regularly.

[stefanelli73]

10 bit FSE should work fine.

the problem with FSE is the black screen

[leeperry]

Turns out I can do RCA Medium on 1080p30 now, every time I thought a GPU upgrade from my 7870 was long overdue madshi strikes again with a new build that does it all and then some :)