madVR - high quality video renderer (GPU assisted)

[oldpainlesskodi]

With correctly functioning hardware (TV and GPU drivers), it still is.

Are you using an NVIDIA?
With some older driver branch - don't remember which one - I had kind of the same issue you have, with clipping. I had to set the GPU (and TV of course) to Limited to get it fixed permanently but of course you then lose in picture quality.
Is YCbCr the only mode that fixes it on your TV, or does RGB Limited works too?
Do you by any chance have another device to test with?
If you have an NVIDIA, try changing the "Content type reported to the display" setting and see if it changes something. When I had that issue with NVIDIA drivers, changing that option to literally anything else than the one currently selected fixed the problem until the next display resync, at which point I had to change it again.
The problem was then fixed in the following driver branch.

Thanks for sharing el Filou.

I'll look into your suggestions and compare ( yes, I'm Nvidia driver 352.83 - HDR switching working, Atmos etc etc) and report back as it may help others.

YCbCr444 produces a significantly different image in colour and luminance uniformity, and less image noise without an apparent degradation of sharpness or image quality (more film like, if you will) compared to RGB Limited, and as I mentioned, RGB full chain washes out the image slightly along with a different colour and gamma presentation, and has more noise - but I will do more tests with the combinations you mentioned and report back.

K

[huhn]

madshi this is maybe interesting if you want to add VFR support to madVR.

https://forums.blurbusters.com/viewtopic.php?f=10&t=3972&start=30#p31943

[70MM]

I keep reading on here that a number of people prefer YCbCr444 over RGB for whatever reasons. Yet madshi keeps saying we should use RGB @ 8 bits with dithering.

To those that do, why is 444 better for you than RGB?

[huhn]

it's inquestionable inferior if you have an end device that is not broken.

the benefit of YCbCr is the display know for sure if it is limited range or full range so you can't screw this up because it is always limited.

[70MM]

So huhn you are saying still RGB is far better?

[70MM]

When one is upscaling BD to 4K and using any image enhancements like sharpen edges and enhanance detail, who also uses the same two settings in upscaling refinement?

Can it be detrimental or cause artifacts if sharpening is used in both areas when upscaling from BD to 4K?

[ryrynz]

No it's fine, it's only a problem if you're over sharpening, in which case it highlights preexisting artifacts more than anything.. Just don't use sharpening so much you can see halos.

Doesn't hurt to evaluate a higher setting in either area before using sharpening in both in order to save performance.

[70MM]

ryrynz, do you sharpen in both areas or just in one?

[ryrynz]

I refine only after upscaling is complete.

[e-t172]

madshi this is maybe interesting if you want to add VFR support to madVR.

https://forums.blurbusters.com/viewtopic.php?f=10&t=3972&start=30#p31943

That's fascinating, especially the discussion that follows on that thread - people are discussing how to circumvent real-time Windows thread scheduling limitations to time Present() calls in the most accurate (least jittery) way possible, which is exactly the problem that madVR would have to solve if it were to leverage variable sync for smooth video presentation.

[Siso]

I refine only after upscaling is complete.

Same here :D

[HillieSan]

Hi, what do you mean you need the latest nightly, DIRECT3D 11 has been working for ages on my system, its required for HDR to work.

What does it fix?

Direct3D11 in MadVR didn't work well with the first version of LAV filter 0.71.0. The latest updates fixed the problem. Now Direct3D11 works again.

[ashlar42]

Edited. Not important enough. I lack the time to debate stuff like this on the internet. sorry.

[mclingo]

Direct3D11 in MadVR didn't work well with the first version of LAV filter 0.71.0. The latest updates fixed the problem. Now Direct3D11 works again.

I didnt notice any issues with it and dont remember anything being posted, so I know what to look out for should problems recurr with later updates which problems was it causing?

[strumf666]

D3D11 native and AMD drivers have (had?) its problems. CB not to my knowledge.

[oldpainlesskodi]

it's inquestionable inferior if you have an end device that is not broken.

the benefit of YCbCr is the display know for sure if it is limited range or full range so you can't screw this up because it is always limited.

I think you might be correct - with the Samsung range of SUHD sets, there maybe an error in how it treats full range RGB vs 4.4.4, and using HDR+, further adds to the issue (even on the very latest firmware)

The problem with perfection.....oh, don't get me started :-)

As I have no intention of writing off my investment (I bought the set at peak), I'll live with 4.4.4 and use HDR+, but I do wish these manufacturers would get their act together ffs.

K

[huhn]

you have todo what you have todo...

i have to use smoothmotion even through i would like to match refreshrates but my screen has some dumb bug in this regard it is as it is and it doesn't change it would be better the other way.

[ui123]

Hello guys, quick question about HDR passthrough

Do i need to enable windows 10 HDR option ? My TV is switching to HDR i can see the HDR logo on my tv but when i go to windows 10 HDR option windows say it is disabled.

Thanks for the clarification :confused:

TV: SONY 4K HDR 10 Bits
MPC-HC v1.7.16
MadVR .12
GTX 1080
Windows 10 last update
HDR file : A Series of Unfortunate Events 2160p HDR Netflix WEBRip DD5.1 x265

http://www.imagebam.com/image/2ad241831726033

[Warner306]

madVR uses the private APIs provided by Nvidia and AMD. There is no need to use the Windows HDR switch.

You should probably use a better scaler than DXVA2 with that graphics card. Something in the NGU family would be preferable.

[Asmodian]

Do i need to enable windows 10 HDR option ? My TV is switching to HDR i can see the HDR logo on my tv but when i go to windows 10 HDR option windows say it is disabled.


No, do not enable the Windows HDR option. The (NV HDR) after the display mode tells you madVR is using Nvidia's API for displaying HDR. This is a good thing because the Windows HDR mode damages the video, it seems to assume you have a perfect 4000 nits HDR10 display or something (which no one has) and maps all content to that. I don't know what metadata it then sends to the TV. It seems like Microsoft has the resources to do HDR better... but they have always been amazingly dense when it comes to HTPC. :(

IMHO the OS HDR switch is pure evil, and should be avoided at all cost, until Microsoft gets off their high horse and finally learns how to do things right. But that's just my personal opinion, of course.

EDIT:
madshi this is maybe interesting if you want to add VFR support to madVR.

https://forums.blurbusters.com/viewtopic.php?f=10&t=3972&start=30#p31943

That is very interesting but it doesn't sound like it solves the problem madshi was worried about. This software event will not be as regular as the hardware events so even with madVR controlling the present() times as accurately as possible they would vary +/- Xms. We don't know what this variation would be and it would probably vary a lot system to system, depending on hardware, background tasks, etc. Windows is not a real time OS after all.

I think these small frame time variances would be unnoticeable and worth it to have 0 dropped or repeated frames for content with any frame rate, even mixed, without needing to tune custom refresh rates (and the drivers don't support custom refresh rates very well).

I do see madshi's point though. The work to implement a mode that is probably slightly worse than what is available currently, and only offers convenience as a benefit, could be spent on other things.

That said, I do have an extra G-sync monitor (Asus PG278Q) that I would be happy to ship to Europe if it would help. :D

Edit2: hmm.. reading the rest of that thread it does sound like there are a few ways to get very low jitter in frame times. :)

[ui123]

Thanks a lot Warner306 & Asmodian for your answers :sly:

[madshi]

OK, I just tested different subtitle types (DVD, blu-ray, SRT) and it makes no difference. Tested different files too, it's all very consistent.

With MPC-HC & its internal subtitle renderer (and a full LAV+madvr chain) no issues at all, on any file and with any type of subs. Completely negligible impact on performance.

Now, with XySubFilter (had to install that :p ) and MPC-HC, yes, I am seeing a performance hit (rendering times in madVR overlay), but it seems a bit smaller (about 4-5ms instead of 9-10).
Ok, it seems the way I render the subtitles does cost a noticeable chunk of performance on old/slow GPUs. I'm not exactly sure why. Maybe the combination of using a high bitdepth backbuffer (by default 16bit) and then asking the GPU to alpha blend subtitles onto it isn't too easy to do for such GPUs.

The performance hit with JRiver MC is probably higher because depending on the situation it sometimes renders to a higher resolution.

There's probably not much I can do to speed things up. At least I don't know how. I do wonder why the internal MPC-HC subtitle renderer doesn't seem to have the same performance hit, though. Hmmm... Is it possible it does have a similar hit and it's just not listed by madVR? I'm not sure right now if my rendering times measurement system successfully captures how much time the MPC-HC internal subtitle renderer spends.

PSA: 120 Hz FreeSync TVs are coming. (https://www.blurbusters.com/new-120hz-freesync-televisions-by-samsung-coming-this-year/)
Great! So we will probably be able to drive these TVs with 120hz *fixed*sync. Looking forward to that.

That's fascinating, especially the discussion that follows on that thread - people are discussing how to circumvent real-time Windows thread scheduling limitations to time Present() calls in the most accurate (least jittery) way possible, which is exactly the problem that madVR would have to solve if it were to leverage variable sync for smooth video presentation.
Exactly. See FAQ in the 2nd post of this thread.

[Asmodian]

Great! So we will probably be able to drive these TVs with 120hz *fixed*sync. Looking forward to that.

It is a 4K TV that can do 1080p at 120 Hz, just like last year's OLEDs from LG. The only thing new is Freesync support. :p;)

[madshi]

madVR v0.92.13 released

http://madshi.net/madVR.zip

* added 2 new RCA quality levels, with NGU fusion support
* if "activate RCA only if it comes for free" is active, NGU quality level isn't modified, anymore
* improved "preserve hue" tone mapping quality
* added "dynamic" mode for "luminance vs saturation reduction" option
* added "dumb" tone mapping algo, optionally with color correction
* added support for Arve custom tone mapping curves
* added "hdrOutput" information field
Didn't have much time, so only a few changes. No (important) bugfixes this time. Besides all the HDR changes (which are still a work in progress), the key changes in this build is as follows:

1) The former RCA "high" quality is now "very high" quality.

2) The former RCA "medium" quality is now "high" quality.

3) Added new faster (and worse quality) "medium" and "low" RCA presets.

4) Basically now RCA has the same quality levels as NGU (low, medium, high, very high). And now the fusing of NGU+RCA happens with the same quality level names. Which should make the fusion logic slightly easier to understand (I hope).

5) If you enable the option "activate only if it comes for free", in older builds madVR used whatever quality was "higher". So basically if you used NGU High + RCA Very High (formerly known as RCA High), madVR actually "upgraded" NGU to Very High quality. This still happens if you have "activate only if it comes for free" disabled. But if you enable it, the new build now never changes NGU quality level, anymore. Instead NGU quality will stay exactly as you selected it, and RCA is simply added via fusion, regardless of which RCA quality level you've selected.

P.S: In order to use custom Arve curves for tone mapping, you need to use a special patched version of that tool. The original tool doesn't work for madVR, because the original tool has too low precision for my taste. You can download the custom version of the tool for madVR here:

http://madshi.net/jvcprojectortools.zip

[ABDO]

another great released, thank you madshi for your hard work <as always> :):thanks:

[ABDO]

madshi, the new RCA quality levels is great, i can now use it easily with 1080p video at my (gtx 650ti boost), amazing.

[huhn]

120 UHD will come with HDMI 2.1 most likely next year.

[leeperry]

:thanks: for the new build but I used to have the "activate only if free" RCA checkbox enabled so it would keep 1080p untouched and allow me to combo medium RCA + "very high" NGU, but this isn't an option anymore apparently? This new change has made the checkbox useless for me, I don't see why you won't allow us to change the RCA level if it's free-ish :(

[HillieSan]

I didnt notice any issues with it and dont remember anything being posted, so I know what to look out for should problems recurr with later updates which problems was it causing?

I think it was fixed in version 0.71.0-1, a few days after version 0.71.0-0 was released.

D3D11 native and AMD drivers have (had?) its problems. CB not to my knowledge.

That was a long time ago. FSE was/is problematic. I am not sure if it was a pure AMD driver problem. Microsoft also broke/fixed a few things in Windows 10.

[Warner306]

I found a bug. If you enable "restore details in compressed highlights" under hdr, the image becomes corrupted and turns purple.

This is with SDR content, not HDR, so this option shouldn't do anything. Tested with Nvidia and Intel drivers.

[Warner306]

I have some questions about the new release:

1) I understand the concept about fix too bright & saturated pixels with regards to illegal RGB values but less about gamut mapping. Do all pixels falling within the gamut (those above 0 to 100 nits) require hue and saturation adjustments after tone mapping, or does this only apply to mapping BT.2020 to BT.709?

2) What happened to diffuse white?

3) Does BT.2390 clip anything, or does it preserve all highlights?

4) Does the strength setting do anything with the free variant of RCA?

That is all...

[Asmodian]

5) If you enable the option "activate only if it comes for free", in older builds madVR used whatever quality was "higher". So basically if you used NGU High + RCA Very High (formerly known as RCA High), madVR actually "upgraded" NGU to Very High quality. This still happens if you have "activate only if it comes for free" disabled. But if you enable it, the new build now never changes NGU quality level, anymore. Instead NGU quality will stay exactly as you selected it, and RCA is simply added via fusion, regardless of which RCA quality level you've selected.

Much more straight forward and it seems ideal behavior, nice upgrade. Thanks!

I used to have the "activate only if free" RCA checkbox enabled so it would keep 1080p untouched and allow me to combo medium RCA + "very high" NGU, but this isn't an option anymore apparently? This new change has made the checkbox useless for me, I don't see why you won't allow us to change the RCA level if it's free-ish :(

I don't understand. If you are running NGU very high why would you want to run RCA medium? That would cost more performance than running RCA very high (for free) wouldn't it? :confused:

That option used to change the NGU level to match the RCA level or the RCA level to match the NGU level (whichever was higher), not allow you to run RCA for free at a different quality level.

[toniash]

I get a purple image :scared: with last version

[Asmodian]

I found a bug. If you enable "restore details in compressed highlights" under hdr, the image becomes corrupted and turns purple.

This is with SDR content, not HDR, so this option shouldn't do anything. Tested with Nvidia and Intel drivers.

I get a purple image :scared: with last version

I can reproduce this too. It happen if I have "restore details in compressed highlights" enabled on the "hdr -> convert HDR content to SDR by using pixel shader math" page even if I have the hdr setting on "passthrough HDR content to the display" but not if I have it on "let madVR decide" (this is while watching SDR or HDR content). It looks like a cool debug mode to me. ;)

Interestingly it also doesn't happen if I am actually watching HDR using "convert HDR content to SDR by using pixel shader math". :confused:

[toniash]

I can reproduce this too. It happen if I have "restore details in compressed highlights" enabled on the "hdr -> convert HDR content to SDR by using pixel shader math" page even if I have the hdr setting on "passthrough HDR content to the display" but not if I have it on "let madVR decide" (this is while watching SDR or HDR content). It looks like a cool debug mode to me. ;)

Thanks!:thanks:

[leeperry]

That option used to change the NGU level to match the RCA level or the RCA level to match the NGU level (whichever was higher), not allow you to run RCA for free at a different quality level.
OK fair enough, I guess I'll never check this box ever again and try my luck enabling low RCA for NGU Medium 720p30@1080p60 as the "free" checkbox only worked up to 720p25 huh.

[madshi]

I used to have the "activate only if free" RCA checkbox enabled so it would keep 1080p untouched and allow me to combo medium RCA + "very high" NGU, but this isn't an option anymore apparently? This new change has made the checkbox useless for me, I don't see why you won't allow us to change the RCA level if it's free-ish
I don't really understand what you're saying, but my impression is that you either misunderstood how it worked before, or how it works now, or both... :p Why don't you give it a try and observe if anything doesn't behave the way you would want it to. If that's the case, report it here.

1) I understand the concept about fix too bright & saturated pixels with regards to illegal RGB values but less about gamut mapping. Do all pixels falling within the gamut (those above 0 to 100 nits) require hue and saturation adjustments after tone mapping, or does this only apply to mapping BT.2020 to BT.709?
It's really complicated. In theory a near black pixel could produce negative RGB values. Such a pixel would require some hue and saturation adjustment, too. Pixels above 100nits or even 1000nits may or may not fit into the gamut, depending on hue. On the other hand, even pixels below 100nits can already be out of gamut (after tone mapping). A lot depends on which hue and saturation each pixel has.

2) What happened to diffuse white?
It was only available in the test builds. I've removed it because it didn't really bring anything useful to the table. E.g. if you had peak=100 and diffuseWhite=20, you can achieve the exact same output by using peak=500 now. Basically diffuseWhite just scaled the peak number, nothing else.

3) Does BT.2390 clip anything, or does it preserve all highlights?
If madVR knows the correct video peak (no matter how), BT.2390 doesn't clip anything. But if madVR believes the video peak to be lower than it actually is, then there will be some clipping.

4) Does the strength setting do anything with the free variant of RCA?
When using the free "NGU+RCA fusion" variant, the RCA strength setting is still in full effect. But you can't choose the RCA quality, anymore, because the quality is now defined by the NGU quality. Obviously this only applies if you told madVR that you want to use RCA only if it comes for free. Otherwise both RCA strength and quality settings will be fully honored in any case.

[madshi]

madVR v0.92.14 released

http://madshi.net/madVR.zip

* fixed: activated HDR option "restore details in compressed highlights" broke SDR playback

[Klaus1189]

madVR v0.92.14 released

Thank you :)

[leeperry]

I don't really understand what you're saying, but my impression is that you either misunderstood how it worked before, or how it works now, or both... :p Why don't you give it a try and observe if anything doesn't behave the way you would want it to. If that's the case, report it here.
True :p
All I know is that it used to be free-ish but now appears truly free and I can finally use RCA+NGU Medium on 720p30@1080p so that's perfect :thanks:

[theDongerr]

It was only available in the test builds. I've removed it because it didn't really bring anything useful to the table. E.g. if you had peak=100 and diffuseWhite=20, you can achieve the exact same output by using peak=500 now. Basically diffuseWhite just scaled the peak number, nothing else.

So moving forward from the old method peak=100 divided by diffuseWhite=20 is 5. The 5 is your multiplier on a base of 100nits and that's how you get 500.

So if I was doing peak=100 diffuseWhite=40 before, my new peak=250?


Thanks for all you do madshi.

Cheers,

-donger

[MrDVader]

What should I enter for "Target peak nits" when converting HDR to SDR?

I have a JVC DLA-RS400, 126" screen, 170 lamp hours, dark room.

According to webprojectorcalculator.com I have:

79 nits in low lamp mode
106 nits in high lamp mode

I'm using the latest madvr version.

Edit:
Also, my projector has not been calibrated (except basic gray scale by eye) but is set to BT.2020 color space. Nevertheless, should I set madvr to calibrated to BT.2020, or DCI-P3, and power curve 2.40?

I tried DCI-P3 but the colours went too red, BT.2020 with 2.40 appears to look very good, as does my current peak nits of 100 - if I up the peak nits, it just appears to produce increasing black crush AND somewhat over exposed whites. I have manual iris fully open and auto iris on 2 (which apparently is more graduated that the other more contrasty setting)

[Asmodian]

BT.2020 with 2.40 appears to look very good, as does my current peak nits of 100 - if I up the peak nits, it just appears to produce increasing black crush AND somewhat over exposed whites.

BT.2020 with a peak nits of 100 it is then. :)

Seriously though, HDR processing is not very uniform right now so we would need experiance with your projector and a meter to be sure. 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. Gamma is very much user preference and madVR's settings only have an effect when using madVR to change the gamma.

[suanm]

I wonder whether Mr. madshi has a plan to integrate the Open GL renderer with madvr .When I play 4K HDR movies in Open GL rendering mode,i can get better image quality in open gl mode than i do in D3D11 rendering mode of Madvr.Better color images at least.I look up the parameters in the format in Open GL mode of potplayer.
The orders is :NV12(INPUT)-->RGBA(video)-->XRGB(backbuffer-->display).Due to RGBA(video) conversion,my TV set displays lifelike color images.Unfortunately,there is no 60fps feature to be available as the Open GL rendering mode of potplayer runs. So i hope Mr. madshi integrate the Open GL renderer in madvr . Thanks in advance,Mr.madshi

[Warner306]

What should I enter for "Target peak nits" when converting HDR to SDR?

I have a JVC DLA-RS400, 126" screen, 170 lamp hours, dark room.

According to webprojectorcalculator.com I have:

79 nits in low lamp mode
106 nits in high lamp mode

I'm using the latest madvr version.

Edit:
Also, my projector has not been calibrated (except basic gray scale by eye) but is set to BT.2020 color space. Nevertheless, should I set madvr to calibrated to BT.2020, or DCI-P3, and power curve 2.40?

I tried DCI-P3 but the colours went too red, BT.2020 with 2.40 appears to look very good, as does my current peak nits of 100 - if I up the peak nits, it just appears to produce increasing black crush AND somewhat over exposed whites. I have manual iris fully open and auto iris on 2 (which apparently is more graduated that the other more contrasty setting)

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.

[Warner306]

I wonder whether Mr. madshi has a plan to integrate the Open GL renderer with madvr .When I play 4K HDR movies in Open GL rendering mode,i can get better image quality in open gl mode than i do in D3D11 rendering mode of Madvr.Better color images at least.I look up the parameters in the format in Open GL mode of potplayer.
The orders is :NV12(INPUT)-->RGBA(video)-->XRGB(backbuffer-->display).Due to RGBA(video) conversion,my TV set displays lifelike color images.Unfortunately,there is no 60fps feature to be available as the Open GL rendering mode of potplayer runs. So i hope Mr. madshi integrate the Open GL renderer in madvr . Thanks in advance,Mr.madshi

I believe Kodi uses OpenGL. I don't see how this is an advantage. Kodi converts any 10-bit input to 8-bit sRGB before outputting to the target gamut. So this is a lossy process. I notice the colors in Kodi are slightly different but not more lifelike. They look wrong and probably are wrong.

[nevcairiel]

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.

[suanm]

I believe Kodi uses OpenGL. I don't see how this is an advantage. Kodi converts any 10-bit input to 8-bit sRGB before outputting to the target gamut. So this is a lossy process. I notice the colors in Kodi are slightly different but not more lifelike. They look wrong and probably are wrong.
There is no conversion of HDR to SDR in KODI.So i have to abandon KODI.My video&audio decoders are LAV.The output format is NV12 after decoding,i use OpenGL as renderer in potplayer instead of D3D11 or madvr.By D3D11 or madvr i feel the color of images doesn't look lifelike or natural on my tv set.for example,i do not distinguish their skin color between orientals and westerners by D3D11 or Madvr.it's so to easy to distinguish their differences by OpenGL renderer,though.This is why i prefer OpenGL render.

[Asmodian]

Something is wrong then. I have an i1 Pro 2 and i1 Display Pro which I regularly use to measure the color generated by madVR. madVR is very accurate and able to perfectly display any in gamut color. I have never used PotPlayer but it seems obvious that it is doing some saturation enhancement or something.

As nevairiel said, any differences are due to processing, not the API used to get the video into the GPU.

[Warner306]

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.

I am fairly certain OpenGL is limited to 8-bit processing. At least, it is on Linux. Kodi has been waiting for updates to support 10-bit passthrough. The rest of the processing likely comes down to the algorithms chosen. The poster noted the input is also converted to sRGB, like Kodi, so maybe this is also standard or the preferred method of rendering in OpenGL.