madVR - high quality video renderer (GPU assisted)

[Polopretress]

Hey guy, we were not talking about the fact of a drop/repeat frame that can be seen but the impact of this settings on the smoothness of the video (and the need or not to use Smooth Motion function)
Of course 40min of drop/repeat is not really an issue to lose or repeat a frame but the impact on the fluidity of the video is more visible when timing is not "perfectly" or "near perfectly" set

[SweetLow]

Hey guy, we were not talking about the fact of a drop/repeat frame that can be seen

No. We were talking exactly about the fact of a drop/repeat frame that can be seen and how avoid this.

[Manni]

Even without madshi's tool to make custom refresh rates easier, I've been setting up custom rates with only NVIDIAs control panel for years with 2+ hours of drop time. Its really not that hard.

If your display allows it, sure.

Unfortunately that's not the case for many of us, especially with projectors.

I do agree though that if I could get 3+ hours in both 2D and 3D then I wouldn't be looking for anything more. :)

50-60mn in 2D is close enough, if the shot is mostly static when the 2-3 frame drops happen I won't notice them.

3-5mn in 3D sucks and makes it close to useless to those of us sensitive to frame drops though, and there doesn't seem to be a way to improve this, sadly.

[Polopretress]

No. We were talking exactly about the fact of a drop/repeat frame that can be seen and how avoid this.
Not really but it does not matter.

see attached the beginning of the discussion :
No. It is not improvement of SM nor new algorithm. This is struggling with almost the same but not equal frequencies. Read the beginning of this discussion.

But Smooth Motion is completly useless when you have perfect custom resolutions adapted to movie fps (or adapted to a multiple of fps)

[SamuriHL]

Yea, the drops in 3D on nVidia is very noticeable. If there's a way to improve that, I'd be all over it. Lately I can't even get a 2D custom res to work all that well for my panasonic plasma. sigh.

[Polopretress]

Yea, the drops in 3D on nVidia is very noticeable. If there's a way to improve that, I'd be all over it. Lately I can't even get a 2D custom res to work all that well for my panasonic plasma. sigh.
I was not aware that 3D behavior was different from 2D on the custom resolution. (i do not read 3D in fact)
Does someone here knows the root cause ?

If you have also problem with 2D , it is probably because even if you modify and create a custom resolution for your Pana, it does not take into account and keep using his EDID settings to display.

In this case, 2 solutions :
1. modifiy the EDID instead of creating custom resolutions
2. create a multiple of your frequency but apply the settings of the real frequency.(and , of course, modify this setting in madVR by replacing for example 1080p23 by 1080p47) in that case, you "turn-around" the system lock.

On my Pana plasma , i apply the second solution because i prefer to avoid to modify the EDID file.

If your display allows it, sure.
Unfortunately that's not the case for many of us, especially with projectors.
Exact. i see you have a JVC and it is a mess with this brand....
I have already spent hours and hours with one JVC of my friend to try to make it accept a new setting without blanck screen....

Sony and Epson are really more flexible !

[Manni]

Exact. i see you have a JVC and it is a mess with this brand....
I have already spent hours and hours with one JVC of my friend to try to make it accept a new setting without blanck screen....


There is only one custom refresh rate setting that works with the JVCs (at least mine) with my 1080Ti and it's the EDID/CTA. That's the one that gives me 50-60mn between drops in 4K24 (2D). There is no need to "train" MadVR for 30mn, just select it and apply it. I haven't tested any other res/refresh rate as I don't really care.

[madshi]

3-5mn in 3D sucks and makes it close to useless to those of us sensitive to frame drops though, and there doesn't seem to be a way to improve this, sadly.
Just a short comment while still having piles of commercial work on my desk:

Thanks to my great Nvidia driver contact, I managed to get a fix for 1080p23 timings into newer driver versions. So stock 1080p23 timings should be much better now with newer drivers, probably also for 3D. I know, the newest drivers come with their own problems, so many are still using older driver versions. But JFYI...

[Manni]

Just a short comment while still having piles of commercial work on my desk:

Thanks to my great Nvidia driver contact, I managed to get a fix for 1080p23 timings into newer driver versions. So stock 1080p23 timings should be much better now with newer drivers, probably also for 3D. I know, the newest drivers come with their own problems, so many are still using older driver versions. But JFYI...

Wow, that's great news, thanks!

I hope they'll solve the levels issue at the same time, that's the main problem with the latest drivers.

And good luck with your commercial work :)

[sat4all]

Just a short comment while still having piles of commercial work on my desk:

Thanks to my great Nvidia driver contact, I managed to get a fix for 1080p23 timings into newer driver versions. So stock 1080p23 timings should be much better now with newer drivers, probably also for 3D. I know, the newest drivers come with their own problems, so many are still using older driver versions. But JFYI...

Great news, thank you and best of luck with your work.

[sat4all]

Wow, that's great news, thanks!

I hope they'll solve the levels issue at the same time, that's the main problem with the latest drivers.

And good luck with your commercial work :)

What levels issue do you have? I'm on last drivers and didn't notice anything!
GPU 0-255, madVR and TV 16-235

[BetA13]

Just a short comment while still having piles of commercial work on my desk:

Thanks to my great Nvidia driver contact, I managed to get a fix for 1080p23 timings into newer driver versions. So stock 1080p23 timings should be much better now with newer drivers, probably also for 3D. I know, the newest drivers come with their own problems, so many are still using older driver versions. But JFYI...



dunno, if that makes a difference, but i allmost never had a problem with the NVidia drivers..
BUT, i also DONT use teh GeForce drivers, i do use Quadro drivers that i modd beforehand to install it on my gtx670.
Maybe worth a try for the ones having problems..
I do feel, that the quadro drivers are more stable and have less Bugs/Problems..

Greetings..

[madjock]

Well, out of a pure fluke and messing about for a long time, then giving up when I had at best 38 Mins frame repeats which was livable...

I came across this post on a random Google search...

1. Go to Nvidia Control Panel
2. Change the Resolution to 23 HZ (I left this one at 24hz and it made no difference)
3. Create Custom Resolution With Following Settings:

Horizontal Pixels: 1920

Vertical Lines: 1080

Refresh Rate: 23


Timing:

Standard: Manual


Horizontal:

Active Pixels: 1920

Front Porch(pixels): 638

Sync width(pixels): 44

Total Pixels: 2750

Polarity: Positive


Vertical:

Active Pixels: 1080

Front Porch(pixels): 4

Sync width(pixels): 5

Total Pixels: 1124

Polarity: Positive


Hz: 23.976



I'm using a 1050 and 390.77 drivers, and I am now getting 8 hrs + without a frame repeat on 1080p, and 2160p->1080p.

I never did get the MadVR ones to work, well any better than the Nvidia, and CRU and the likes were a pain for me for some reason.

It takes a minute and actually sits at 23.9755 ish, and the deviation locks out at 0.00230% or something like that and all good.

Sorted. :)

[Polopretress]

It is the standard setting except -1 in total pixel vertical (means -1 in vertical back porch) ==> you are just lucky.
Just for information, you do not have to focus on the time displayed for the first frame drop/repeat occurs if you have a deviation clock of this value. just focus on the value of "display" because the value of the time counter is wrong.

For having deviation clock at this value, you probably use MPC-be (or equivalent).
Potplayer is not creating clock deviation (will trend to 0.00000% after few seconds) and in this situation the value of time counter (1 frame repeat/drop every:) is correct and consistent with the value of "display" indicator.

[madjock]

It is the standard setting except -1 in total pixel vertical (means -1 in vertical back porch) ==> you are just lucky.
Just for information, you do not have to focus on the time displayed for the first frame drop/repeat occurs if you have a deviation clock of this value. just focus on the value of "display" because the value of the time counter is wrong.

For having deviation clock at this value, you probably use MPC-be (or equivalent).
Potplayer is not creating clock deviation (will trend to 0.00000% after few seconds) and in this situation the value of time counter (1 frame repeat/drop every:) is correct and consistent with the value of "display" indicator.

I don't think Im lucky, I have messed with the odd pixel here and there and never achieved anything like this, there were also a few people on the thread that got good results with it, a bit like the MadVR customs that I had no joy with.

I am using MPC-HC and KODI and Dsplayer, KODI gives even better results.

I also assume you are not Bitstreaming DTS-HD or TrueHD via HDMI to get 0.000000% and POT player uses some sort of re-clock, which is no use to people who want to Bitstream.

[nevcairiel]

Clock deviation makes no real difference. madVR accounts for it when calculating the repeat/drop timer, you just need to play long enough for it to stabilize, and the ultimate test is for every setup to just play a 2 hour movie and check the stats afterwards (clear them after launch to get rid of the first drops during startup).

[madjock]

Clock deviation makes no real difference. madVR accounts for it when calculating the repeat/drop timer, you just need to play long enough for it to stabilize, and the ultimate test is for every setup to just play a 2 hour movie and check the stats afterwards (clear them after launch to get rid of the first drops during startup).


I agree, but previous to this and after attempting lots and lots of custom resolutions, changing the odd pixel, using manual after setting different timings, I would get something like 23.9756-ish sat steady-ish and at best 38 Mins per frame drop.

Now with these figures I have applied, it is lower that 23.9756, yet the frame repeats have gone to the hours, at best they used to reach an hr and drop back and stabilize at 36-38 mins.

I think its as good as I am going to get for sure.

[Manni]

What levels issue do you have? I'm on last drivers and didn't notice anything!
GPU 0-255, madVR and TV 16-235

I also use RGB Full, MadVR and TV 16-235, but this doesn't work for me with 391.x. That and the other issues I reported a while back (broken Asio4all compatibility and a few other things).

It could be specific to my JVC display but the levels are completely borked for me with 391.x

Borked as in it's not possible to find a combination of settings that results in the correct levels both in SDR and in HDR.

I tried to set all GPU/MadVR/Display to 0-255 and a few other combos, it's just a no go. Levels simply don't match, blacks are either crushed or raised, there is no combo that gives me black at 16 in SDR and 64 in HDR.

I know many don't have this levels issue, and I'm happy for them :)

[sat4all]

I also use RGB Full, MadVR and TV 16-235, but this doesn't work for me with 391.x. That and the other issues I reported a while back (broken Asio4all compatibility and a few other things).

Latest driver version is 397.93, maybe you get lucky.
Try clean install using DDU.

Cheers

[Manni]

Latest driver version is 397.93, maybe you get lucky.
Try clean install using DDU.

Cheers

Yeah, that's what I do with every single new driver, before reverting to 385.28.

I did see the 397.93 and want to test it in case the refresh rate for 3D is fixed. Didn't have the time yet...

[madjock]

@Manni

Just been reading this thread
http://www.avsforum.com/forum/24-digital-hi-end-projectors-3-000-usd-msrp/2954506-improving-madvr-hdr-sdr-mapping-projector-24.html

Lots of good information, but if anyone asked about anything other than projectors they were told to use the correct thread.

I have not seen a lot of information on using the HDR->SDR options for a standard 1080p HDTV and doing 2160p->1080p.

I don't have fancy calibration equipment and the likes but from all the things you have learned with all the discussion, what would you class as a good standard for HDR->SDR with the latest MadVR, as the more I read the more it seemed to jump between person to person, which I get, but it does seem to be a grey area.


I guess I am also a little confused by HDR->SDR conversion, as although I get the comparisons with SDR, is that what everyone aims at, would we not hope to get it looking better than SDR if thats possible on a non SDR set ?

[Manni]

Just a short comment while still having piles of commercial work on my desk:

Thanks to my great Nvidia driver contact, I managed to get a fix for 1080p23 timings into newer driver versions. So stock 1080p23 timings should be much better now with newer drivers, probably also for 3D. I know, the newest drivers come with their own problems, so many are still using older driver versions. But JFYI...

Just tested 397.93, and I have good news and bad news:

Good news is that your friend delivered (partly) in 1080p23 for 3D (I didn't test 2D). I now get 13min between frame drops, which is a significant improvement compared to the 3min of previous drivers (at least those I had tested).

Bad news is that the levels are still borked (both in SDR and HDR), however I found why I have the issue and many others don't: the levels are only borked in 12bits, not in 8bits. So it looks like between the banding in passthrough and the borked levels, nVidia shows little love for their 12bits setting.

You would think that the solution is easy: use 8bits in the GPU... Well, that works fine for 2D and 3D SDR, unfortunately Passthrough HDR is borked in 8bits on the JVCs (not in 12bits!) and you get at all refresh rates (at least in UHD) the magenta bug that I only have on 4K60p with previous drivers. The only way to get rid of it is, like with the 4K60 magenta bug, is to disable the "send HDR metadata", which as you know is a no no for me until we get the ability to switch HDR profiles according to max brightness with pixel shader, as the Vertex relies on this to select my custom curve. It is, however, a viable workaround for those whose display doesn't need HDR Metadata.

So pick your poison:

385.28: everything works but 1 frame drop every 3mn in 3D.

397.93: better 3D (13min between frame drops), Asio4all compatibility still broken, levels still borked in 12bits (at least with the JVCs), HDR passthrough borked on JVCs in 8bits.

Aaaargh!

Thanks a lot for your efforts and your friends though, but I'm back to 385.28 if I don't find a way to get rid of the magenta bug in 8bits, at least until I can switch to pixel shader.

397.93 is probably 100% good news for non JVC users who don't care about Asio4All.

@Manni
I have not seen a lot of information on using the HDR->SDR options for a standard 1080p HDTV and doing 2160p->1080p.

I don't have fancy calibration equipment and the likes but from all the things you have learned with all the discussion, what would you class as a good standard for HDR->SDR with the latest MadVR, as the more I read the more it seemed to jump between person to person, which I get, but it does seem to be a grey area.


I'll let others reply. The AVS thread is indeed reserved to ongoing work on MadVR's HDR to SDR conversion with pixel shader for projectors, and it's not a support thread for MadVR projector users either, at least not at this stage, as it's a work in progress. HDR10 is a grey area because there is no standard and every display is different. HDR to SDR, when done well, is the same as HDR. It's just that the source (MadVR here) does the conversion instead of the display. But provided you use the correct settings, it can look as good or better than the HDR mode on the display.

So I suggest you post your display model and hope that someone can make suggestions for you. :)

[madjock]

Just tested 397.93, and I have good news and bad news:

Good news is that your friend delivered (partly) in 1080p23 for 3D (I didn't test 2D). I now get 13min between frame drops, which is a significant improvement compared to the 3-5min of previous drivers (at least those I had tested).

Bad news is that the levels are still borked, however I found why I have the issue and many others don't: the levels are only borked in 12bits, not in 8bits. So it looks like between the banding in passthrough and the borked levels, nVidia shows little love for their 12bits setting.

You would think that the solution is easy: use 8bits in the GPU... Well, That works fine for 2D and 3D SDR, unfortunately HDR is borked in 8bits on the JVCs and you get at all refresh rates (at least in UHD) the magenta bug that I only have on 4K60p with previous drivers. The only way to get rid of it is, like with the 4K60 magenta bug, is to disable the "send HDR metadata", which as you know is a no no for me until we get the ability to switch HDR profiles according to max brightness with pixel shader, as the Vertex relies on this to select my custom curve. It is, however, a viable workaround for those whose display doesn't need HDR Metadata.

So pick your poison:

385.28: everything works but 1 frame drop every 3-5min in 3D.

397.93: better 3D (13min between frame drops), Asio4all compatibility still broken, levels borked in 12bits, HDR borked on JVCs in 8bits.

Aaaargh!

Thanks a lot for your efforts and your friends though, but I'm back to 385.28 if I don't find a way to get rid of the magenta bug in 8bits, at least until I can switch to pixel shader.



I'll let others reply. The AVS thread is indeed reserved to ongoing work on MadVR's HDR to SDR conversion with pixel shader for projectors, and it's not a support thread for MadVR projector users either, at least not at this stage, as it's a work in progress. HDR10 is a grey area because there is no standard and every display is different.

So I suggest you post your display model and hope that someone can make suggestions for you. :)

Ok no problem. I understand all that you have said but as you say there are so many TV models then the chances may be slim, also with some people doing calibrations and other using a default built into MadVR this also muddys the water.

Was just looking for a middle of the road default that applys to most things as the thread was suggesting, but like most I guess it boils down to what people like or don't like.

Thanks for replying anyway. :)

[theDongerr]

Is it safe to install the Windows 10 Spring update? Or did it do something to mess up MadVr?

[Polopretress]

Clock deviation makes no real difference. madVR accounts for it when calculating the repeat/drop timer, you just need to play long enough for it to stabilize, and the ultimate test is for every setup to just play a 2 hour movie and check the stats afterwards (clear them after launch to get rid of the first drops during startup).
I agree but not in the conclusion.
Clock deviation is tacken into account in the calculation but the result will not be "no drop frame expected" when the display will be at 23.97602 Hz if clock deviation is not null.

That means that , with clock deviation, you if you want to target "no drop frame expected", you will not be at 23.97602.
(or if you want to target 23.97602, you will not be at "no drop frame expected")

And let's try the both players (MPC and potplayer) in pcm with the same settings and you wil see that "display" is at the same value and the tilme counter is different

So which player is giving me the truth ?
For me , it is clear that the value of the "display" is the truth because the both players give the same result.
Then my conclusion is that it is the time counter that is wrong using MPC-BE with clock deviation not null.

That's the reason why, i said, the judge is the value of the "display" and not the time counter if clock deviation is not null.
then i think that clock deviation is more tacken into account in the value of the "display" than in the value of the time counter.


If i am wrong , do you mean that i need to follow the time counter instead of the "display" ?
If it is the case, how to explain that value of "display" are the same with a player with no clock deviation and another one with clock deviation not null ?


I also assume you are not Bitstreaming DTS-HD or TrueHD via HDMI to get 0.000000% and POT player uses some sort of re-clock, which is no use to people who want to Bitstream.
Exact i am in pcm.
Potplayer in bitstream works fine but clock deviation is not null (like mpc-be).
Nervertheless... the value of "display" is the same and perfectly adjusted to 23.97602 (but the time counter is different and very far from "no drop frame expected".

Same question that previously. Which one is the truth ?
For me it is the "display" and not the counter.

Show me an example with a display at 23.97602 and the counter at "no drop frame expected" while the clock deviation is not null and i will revise my judgement :)

[nevcairiel]

I agree but not in the conclusion.
Clock deviation is tacken into account in the calculation but the result will not be "no drop frame expected" when the display will be at 23.97602 Hz if clock deviation is not null.

That means that , with clock deviation, you if you want to target "no drop frame expected", you will not be at 23.97602.
(or if you want to target 23.97602, you will not be at "no drop frame expected")

But thats perfectly fine. The goal is to not have any frame drops or repeats, not to hit some special magical number. Its perfectly expected to require a slightly different refresh rate to compensate for the clock deviation.

The perfect refresh rate would be where the display refresh rate multiplied by the clock deviation would be 23.97602 (without software tricks enabled), so for example if you have a small clock deviation of 0.003, you would want a refresh rate of 23.9767 instead (because 23.9760 + 0.003% = 23.9767)

And as others have said, in PCM mode PotPlayer just "cheats" by modifying the audio to perfectly match the video clock, ie. like ReClock. You could get it to match any refresh rate then. :) But it does modify the audio, so its no longer "bit-exact". Its probably not something anyone can hear and it usually works just fine, but you need to be aware that your software works around the hardware problem in this manner. The clock deviation does not go away, its just "hidden" from madVR and compensated for on the audio side instead. And of course this does not work when bitstreaming.

The entire drop/repeat frame mechanic only exists because of audio. If we had no audio, we could just show the video at 23.977 instead of 23.976 and no person in the world would ever notice. But we do have audio, and the audio would lose sync with the video. So to maintain sync, the video renderer has to drop/repeat a frame when appropriate. Now the alternative solution is to change the audio instead, which is what PotPlayer is doing, and why its claiming a zero clock deviation - because it handles that, and madVR does not have to.

The only number that really matters is the number of dropped/repeated frames at the end of the movie. Everything else is just there as information.

[el Filou]

HDR to SDR, when done well, is the same as HDR. It's just that the source (MadVR here) does the conversion instead of the display.If that really was the case then why would TV reviewers who test stuff like 2% window white find very different brightness levels in SDR and HDR modes (last two that come to mind were 400 cd/m² SDR / 700 HDR on an LG OLED, and 750 SDR / 1250 HDR on a Sony LCD)?

[Manni]

If that really was the case then why would TV reviewers who test stuff like 2% window white find very different brightness levels in SDR and HDR modes (last two that come to mind were 400 cd/m² SDR / 700 HDR on an LG OLED, and 750 SDR / 1250 HDR on a Sony LCD)?

Is this with MadVR?

Some players do an HDR to SDR conversion that doesn't exploit the whole dynamic range. Others don't even use the wider gamut.

I'm talking about pixel shader with MadVR, given that it's the topic of the thread. I don't know about OLEDs/LCDs, I can only comment about what I see on my JVC projector. Some displays might not be able to provide the SDR BT2020 mode with full brightness that the JVC delivers to be used as a baseline for MadVR's HDR to SDR conversion (pixel shader).

[Asmodian]

Yes, your projector probably does not have a seperate HDR mode in the same way TVs do. All non-projectors I have seen (not that many) do not work this way. You cannot use pixel shaders to get a similar image when the display is in its SDR mode. For one thing it will not go as bright, reasonably given that SDR at 700 nits peak white would be pretty bright and the display couldn't handle it. Projectors tend to be a lot dimmer so maybe they use the same peak brightness for both HDR and SDR.

I think we need to remember that HDR works very differently in projectors compared to backlit displays and to not assume we can transfer our experiance directly.

[Warner306]

For the HDR -> SDR for 1080p question,

I have two 1080p displays. One is calibrated to about 150 nits, the other is probably closer to 200 nits. I find a target nits between 400 to 500 nits seems to achieve adequate brightness.

Set the tone mapping curve to BT.2390.

Gamut mapping can be set to any of the comlex scientific modes or dumb mode - convert gamut late. It can be hard to immediately notice a difference between any of the gamut mapping algorithms, so this choice may not be critical to you.

Check the rest of the boxes at the bottom.

It is really that simple and not that hard to figure out. Adjust the target nits to your own tastes.

It is an adequate way to show HDR on a non-HDR screen if you accept the limitations of tone mapping. It is certainly a viable way to watch 4K UHD content.

As for the levels thing, I think this is a JVC projector oddity. I was trying to help someone with a JVC projector at AVSForums and his projector displays the strangest behavior. Every time he would fix something, something else would break. It is the most bizzare machine I have come across that runs madVR. His graphics card is a GTX 1050. He actually posted in this forum, so he might be reading this. I know you haven't had as many problems with your JVC, but it doesn't seem to like Windows or anything output from a GPU.

[ryrynz]

Is there a HDR test video that one could use for setting ideal target nits?

[sauma144]

In PCM mode PotPlayer just "cheats" by modifying the audio to perfectly match the video clock, ie. like ReClock. You could get it to match any refresh rate then. :)
Seriously? I never noticed.

[Manni]

As for the levels thing, I think this is a JVC projector oddity. I was trying to help someone with a JVC projector at AVSForums and his projector displays the strangest behavior. Every time he would fix something, something else would break. It is the most bizzare machine I have come across that runs madVR. His graphics card is a GTX 1050. He actually posted in this forum, so he might be reading this. I know you haven't had as many problems with your JVC, but it doesn't seem to like Windows or anything output from a GPU.

I was in touch with him by PM. This is because he was using a recent driver (39x.x). As I reported yesterday, each 39x version broke something new, at least here. The best driver to use with a JVC is 385.28. With this, you can get correct levels in RGB Full, 12bits in SDR and HDR, and he will only get the magenta bug (which can be fixed, as I told him, by disabling "Sending HDR metadata) at 4K60p.

With a recent driver, he can solve things if he disables "Send HDR Metadata" and uses 8bits in the GPU. But that's not an option for me at this stage (I need the metadata for the Vertex), so I went back to 385.28 for now.

The main downside of 385.28 is 3D (1 frame drop repeat every 3mn vs every 13mn with 397.93), and very minor banding in HDR passthrough (not sure when that was introduced by nVidia, but it's still here with 39x.x). You can solve most of the banding in passthrough using 9bits instead of 10bits dithering in MadVR, unfortunately that's not possible with the latest MadVR build, so you have to revert to the previous one.

The JVCs do have some quirks, but they can be used fine if you know how to drive them :)

[SuLyMaN]

Will madvr work with an intel HD 630 onboard graphics? Looking at the requirements, I'd say yes...but you never know. Anybody has tried it?

[madjock]

Will madvr work with an intel HD 630 onboard graphics? Looking at the requirements, I'd say yes...but you never know. Anybody has tried it?

Depends what you mean by work, since it is not a dedicated card with its own memory then you will be very limited on what you could do with madVR.

[Warner306]

I was in touch with him by PM. This is because he was using a recent driver (39x.x). As I reported yesterday, each 39x version broke something new, at least here. The best driver to use with a JVC is 385.28. With this, you can get correct levels in RGB Full, 12bits in SDR and HDR, and he will only get the magenta bug (which can be fixed, as I told him, by disabling "Sending HDR metadata) at 4K60p.

With a recent driver, he can solve things if he disables "Send HDR Metadata" and uses 8bits in the GPU. But that's not an option for me at this stage (I need the metadata for the Vertex), so I went back to 385.28 for now.

The main downside of 385.28 is 3D (1 frame drop repeat every 3mn vs every 13mn with 397.93), and very minor banding in HDR passthrough (not sure when that was introduced by nVidia, but it's still here with 39x.x). You can solve most of the banding in passthrough using 9bits instead of 10bits dithering in MadVR, unfortunately that's not possible with the latest MadVR build, so you have to revert to the previous one.

The JVCs do have some quirks, but they can be used fine if you know how to drive them :)

Well I'm glad you helped him. He was using 385.28 when I talked to him and was still having black screens and some oddities with 3D playback, so I'm not sure if it has all been ironed out.

[veggav]

Quick question

My TV has the following color spaces to choose from
sRGB/BT.709
DCI
Adobe RGB
BT.2020

And MadVR has the following options in "the display is calibrated to the following primaries / gamut:
BT.709
SMPTE C
EBU / Pal
BT2020
DCI-P3

I let madVR change my display resolution to 2160p23 for movies.
So my question is if I'm playing a blu-ray that is bt709 and have DCI on my display settings and DCI-P3 on MadVR, do I get better colors?


Also, when using the pure power curve option set to 2.40 would that translate to the gamma option -2 of the display.
I mean 2.30 = -1 and 2.20 = 0?

[Warner306]

Quick question

My TV has the following color spaces to choose from
sRGB/BT.709
DCI
Adobe RGB
BT.2020

And MadVR has the following options in "the display is calibrated to the following primaries / gamut:
BT.709
SMPTE C
EBU / Pal
BT2020
DCI-P3

I let madVR change my display resolution to 2160p23 for movies.
So my question is if I'm playing a blu-ray that is bt709 and have DCI on my display settings and DCI-P3 on MadVR, do I get better colors?


Also, when using the pure power curve option set to 2.40 would that translate to the gamma option -2 of the display.
I mean 2.30 = -1 and 2.20 = 0?

The calibration setting only applies to SDR content like 1080p Blu-ray. Yes, madVR will upconvert a BT.709 source to DCI-P3 or BT.2020 (which is the recommended setting). I'm not sure you will get better colors, but you will get different colors. It depends on whether you like this effect or not.

The gamma setting is only in effect when enable gamma processing is selected. It is generally advised to set the gamma at the display level rather than the media player.

[arcspin]

I was in touch with him by PM. This is because he was using a recent driver (39x.x). As I reported yesterday, each 39x version broke something new, at least here. The best driver to use with a JVC is 385.28. With this, you can get correct levels in RGB Full, 12bits in SDR and HDR, and he will only get the magenta bug (which can be fixed, as I told him, by disabling "Sending HDR metadata) at 4K60p.


Hi Manni,
I have a question regarding when I set the NVIDIA GPU Driver to 12 bits the green colors and blacks/whites are all messed up, when I switch back to 8 bits all is well.

I have tried this in Full screen exklusive mode (to take into account the missing 10 bit feature in the current MadVR).
I have, with a great deal of help from Asmodian, in another thread debugged my system and the end result is that I have to set NVIDIA GPU Driver to 8 bits to get the colors and blacks/whites to work properly.

The end result from our de bugging session is here:
https://forum.doom9.org/showthread.php?p=1841508#post1841508

I have my NVIDIA GPU Driver set to:
NVIDIA RGB Full 8bpc > Madvr custom level 16-255 > JVC Enhanced.
I get the same result in: NVIDIA RGB Full 8bpc > Madvr Tv level > JVC Standard
(My projector is professionally calibrated to JVC Enhanced)


This is what I use:
WIN 10 64-bit, version 1709 (no spring update) with NVIDIA GTX 1060 (385.28 driver)
I have also in NVIDIA control panel made a custom resolution for 3840 x 2160 23.978hz to get a low clock deviation in MadVR.
JRiver (24.0.20, 64-bit) with Madvr (0.92.14)
JVC RS420/X5500 projector (4K, capable of receiving 12-bit).



Do you have an idea why I cant get the green and blacks/whites to work in 12 bits?


Best regards,

//Peter

[Warner306]

Is there a HDR test video that one could use for setting ideal target nits?

A colorimeter would do the job of telling you how bright your display is. Maybe you could adjust the target nits with HDR grayscale test patches up to 10,000 nits, but I don't know how that would work. Such patterns might help with adjusting the brightness for lower nits.

[veggav]

The calibration setting only applies to SDR content like 1080p Blu-ray. Yes, madVR will upconvert a BT.709 source to DCI-P3 or BT.2020 (which is the recommended setting). I'm not sure you will get better colors, but you will get different colors. It depends on whether you like this effect or not.

The gamma setting is only in effect when enable gamma processing is selected. It is generally advised to set the gamma at the display level rather than the media player.

Thanks for the information.

About gamma there's no option to change it to disable on MadVR.
Only pure power curve and bt709.
At the tab color & gamma I have enable gamma processing unchecked.
Still I can see some difference changing pure power curve from 2.2 to 2.4 while watching a movie.
I guess if you set calibration to this diplay is already calibrated you need to set gamma.

The only other option I see is disable GPU gamma ramps, that is unchecked here. Is this what you are reffering?

[Manni]

Do you have an idea why I cant get the green and blacks/whites to work in 12 bits?


No idea. All is fine here with 385.28 in 12bits, but I do use RGB Full > MadVR 16-235 > HDMI Standard on the JVC. I calibrate the JVC with Calman using MadTPG as a pattern source (best as the patterns come from the source I'll be using) and it only works with video levels, not with enhanced levels.

The only other significant difference I can think of is that I use MadVR's refresh rate custom modes, not nVidia's or CRU. I use the EDID/CTA option and it gives me 50-60mn between a frame drop, which is not perfect but good enough for me.

At the moment, there is nothing to lose using 8bits though, so I'd just set the GPU to 8bits, MadVR to 8bits dithering and enjoy, as MadVR doesn't support 10bits in Windowed mode anymore, and Exclusive is not usable with the JVCs due to the time to do the HDMI resync everytime you use the player's interface.

[x7007]

For you guys every Windows restart the Dynamic Output Range revert back to FULL ? even when it was Limited before windows restart with 397.93 Also the Digital Audio always change to LG TV instead Turn off audio... 2 annoying bugs.

[arcspin]

No idea. All is fine here with 385.28 in 12bits, but I do use RGB Full > MadVR 16-235 > HDMI Standard on the JVC. I calibrate the JVC with Calman using MadTPG as a pattern source (best as the patterns come from the source I'll be using) and it only works with video levels, not with enhanced levels.

The only other significant difference I can think of is that I use MadVR's refresh rate custom modes, not nVidia's or CRU. I use the EDID/CTA option and it gives me 50-60mn between a frame drop, which is not perfect but good enough for me.

At the moment, there is nothing to lose using 8bits though, so I'd just set the GPU to 8bits, MadVR to 8bits dithering and enjoy, as MadVR doesn't support 10bits in Windowed mode anymore, and Exclusive is not usable with the JVCs due to the time to do the HDMI resync everytime you use the player's interface.

Ok, thanx for answering back.
Yup, I'm all good in 8 bits, it just annoys me a little bit not to know the cause.

I will test the MadVR refresh rate and see if that might do some good.
I got some great results with NVIDIAS custom refresh rates and only have 2 dropped frames in a 2h43m 1080p movie.


Question:
I quite don't understand where to set MadVR to 8bits dithering. The only place I can find to set bitdepth in MadVR is in devices (my JVC), properties and "the native display bitdepth is:"
What is improved between setting it to "8 bit" or "10 bit or higher", if GPU is set to 8 bit?

[Asmodian]

It is much better to set madVR to 8 bit with the GPU set to 8 bit, madVR would dither to 10 bit and then the GPU would dither to 8 bit. This is two dithering steps instead of one and madVR's dithering is better quality than the GPU's.

There is a separate settings page for dithering options. Never disable dithering for any reason (except testing). :p

[Polopretress]

But thats perfectly fine. The goal is to not have any frame drops or repeats, not to hit some special magical number. Its perfectly expected to require a slightly different refresh rate to compensate for the clock deviation.

The perfect refresh rate would be where the display refresh rate multiplied by the clock deviation would be 23.97602 (without software tricks enabled), so for example if you have a small clock deviation of 0.003, you would want a refresh rate of 23.9767 instead (because 23.9760 + 0.003% = 23.9767)

And as others have said, in PCM mode PotPlayer just "cheats" by modifying the audio to perfectly match the video clock, ie. like ReClock. You could get it to match any refresh rate then. :) But it does modify the audio, so its no longer "bit-exact". Its probably not something anyone can hear and it usually works just fine, but you need to be aware that your software works around the hardware problem in this manner. The clock deviation does not go away, its just "hidden" from madVR and compensated for on the audio side instead. And of course this does not work when bitstreaming.

The entire drop/repeat frame mechanic only exists because of audio. If we had no audio, we could just show the video at 23.977 instead of 23.976 and no person in the world would ever notice. But we do have audio, and the audio would lose sync with the video. So to maintain sync, the video renderer has to drop/repeat a frame when appropriate. Now the alternative solution is to change the audio instead, which is what PotPlayer is doing, and why its claiming a zero clock deviation - because it handles that, and madVR does not have to.

The only number that really matters is the number of dropped/repeated frames at the end of the movie. Everything else is just there as information.
Just thank you for this explanation.
I have developped a calculation sheet under excel to identify variante of trio [ total pixel V & H , pixel clock] that match perfect settings. Of course, with potplayer , when i have "no drop frame expected" i am at 23.97602 at the display and did notice this problem with clock deviation that i have , after that, tacking into account for some people using player with an existing clock deviation.

Then at that time, my question for this people was :
-do i need to give them the good setting to reach 23.97602 ?
or
- do i need to give them the good setting to reach "no drop frame expected" ?

I was pretty sure that it was the first solution but you give the information that i rather must choose the second solution.

Is that correct ?

I can trust you but it is a strange conclusion for me since for the same setting of GPU, if i compare potplayer (in pcm) without clock deviation and mpc-be (in pcm or also potplayer in bitstream) with a given clock deviation, i can see that value of display is the same (after stabilization)
Based on your answer, i would expect, that "no drop frame expected" would be displayed instead of the same "display" value.

means that with your assumption, if i have to target "no drop frame expected" in the calculation, i have a different setting depending on the player. It is very strange.


and also, i was not aware for the "reclock" of potplayer in PCM.
Strange also since i am set in wasapi bit perfect.

[Asmodian]

- do i need to give them the good setting to reach "no drop frame expected" ?

This, the audio clock is never perfect so you must always target a refresh rate that is perfect relative your audio clock, not true clock time.

wasapi bit perfect is bit perfect between the player and the sound card, it doesn't mean anything about what happens in the player.

[huhn]

the display HZ is relative to the system clock so it doesn't matter.

the clock deviation comes from the video clock and the audio clock so it kind of matters.

23.9702 is just a number that is totally worthless.

what you want is no frame drop the rest doesn't matter.

who the hell told you wasapi is bit perfect... as soon as you change the volume you are not bit perfect anymore and nothing stops you from running a couple filter on the audio before sending it to a wasapi end device.

[Warner306]

Thanks for the information.

About gamma there's no option to change it to disable on MadVR.
Only pure power curve and bt709.
At the tab color & gamma I have enable gamma processing unchecked.
Still I can see some difference changing pure power curve from 2.2 to 2.4 while watching a movie.
I guess if you set calibration to this diplay is already calibrated you need to set gamma.

The only other option I see is disable GPU gamma ramps, that is unchecked here. Is this what you are reffering?

If you changed the gamma, you would see a fairly significant change in brightness. This setting can't be disabled but can be ignored if you disabled gamma processing. You could also disable calibration controls if outputting at BT.709, as this is the default behavior without a selected calibration.

[Polopretress]

Ok, thank you.
Then i must change my conclusion and give result considering the time before to drop instead of the value of the display.
(but in this case, settings of the GPU card will be different depending on the player...)