View Full Version : madVR - high quality video renderer (GPU assisted)
huhn
5th January 2020, 22:32
you should fix that at your display device.
WuNgUn
5th January 2020, 22:35
you should fix that at your display device.I'm not able to at the display... https://uploads.tapatalk-cdn.com/20200105/0690ecf7afbebed1c32129eaf2b2f830.jpg
WuNgUn
5th January 2020, 22:42
"Custom" size is an option when not at 60Hz...
But selecting it doesn't reveal size/position option on the TV.... Still greyed out.
At 60Hz, only factory resolution is available. https://uploads.tapatalk-cdn.com/20200105/72231778cd9e6fd5d09ec47419c6bcf4.jpghttps://uploads.tapatalk-cdn.com/20200105/22db3a71cea5aee015c39c6a04d37309.jpg
Klaus1189
5th January 2020, 23:08
The OSD looks like Samsung and there is an issue with PC mode
Go from here on:
https://forum.doom9.org/showthread.php?p=1892212#post1892212
WuNgUn
5th January 2020, 23:30
It is a Sammy, and the firmware is on 1335...newer than the update mentioned in the link you sent to avoid...
Still isn't fixed obviously.
shimarin
6th January 2020, 07:54
Especially true of NGU high and very high, NGU low is less impressive. Medium is a definite improvement over Jinc but NGU high or very high are the 'real' NGU algorithms in my opinion. :o
what differences do you see between medium and high?
Asmodian
6th January 2020, 08:39
Do test it for yourself, if medium looks the same to you do not pay for extra electricity and run your PC hotter only because I said I liked high or very high more. :)
High looks more natural and detailed, with 'naturalness' being more of an issue with NGU sharp or standard than AA but they all noticeably improve. I do use NGU AA high for chroma upscaling and AA or sharp very high for image doubling when watching 1080p -> 2160p. :o
Alexkral
6th January 2020, 20:32
FYI, AA has the lowest PSNR, even lower than DXVA or Bilinear. It's the same with other similar metrics that account for distortion. Obviously when you compare them visually, DXVA and Bilinear are noticeably more blurry, so I don't know the reason for this.
Visually, AA is only slightly less sharp than Jinc.
huhn
6th January 2020, 21:00
you should never use DXVA for comparison for anything it can be different with driver version it is different between amd, intel and nvidia and it could be different between generations of GPUs from the same vendor.
Mano
6th January 2020, 22:31
Is there a more updated version of madshi XySubfilter (https://forum.doom9.org/showpost.php?p=1830772&postcount=48420)?
huhn
7th January 2020, 02:50
the version on git is newer:
https://github.com/Cyberbeing/xy-VSFilter/releases
oldpainlesskodi
7th January 2020, 10:54
Re the RX 5700 xt, I have to say Kodi Matrix 19.0 HDR Windows API does a great job with HDR. Not a keeper for me though, as without MadVr it's a blur fest lol. Oh well.
Sorry if off topic, but just wanted to share.
mclingo
7th January 2020, 12:49
sadly I agree, what workaround for the low SAT/BT2020 issue are you using for HDR / MADVR on your RX5700XT at the moment then?
oldpainlesskodi
7th January 2020, 12:51
Just manually using the windows HDR toggle before starting a HDR movie.
Klaus1189
7th January 2020, 12:52
I downloaded the Kodi HDR 19 rc3 because I want to test it but I don't get HDR at all and the image is very grey. Did I miss a setting that must be enabled to get HDR passthrough working?
mclingo
7th January 2020, 13:06
Just manually using the windows HDR toggle before starting a HDR movie.
cool, thats you best option, yours is a pretty decent HDR TV so its worth using proper HDR.
mclingo
7th January 2020, 13:09
I downloaded the Kodi HDR 19 rc3 because I want to test it but I don't get HDR at all and the image is very grey. Did I miss a setting that must be enabled to get HDR passthrough working?
make usre you've got the latest version, one version didnt work, he's made quite a few recently for different python versions, I installed and tested Kodi-HDR-Edition-4.0-rc3-Python2.exe - working fine for me.
DMU
7th January 2020, 14:11
I installed and tested Kodi-HDR-Edition-4.0-rc3-Python2.exe - working fine for me.
This version has been removed.
Klaus1189
7th January 2020, 14:37
I have downloaded Kodi-HDR-Edition-4.0-rc3-Python3.exe
Right, I wanted to download the Python2.exe but all versions of 4.0 rc 3 have been removed, strange :confused:
But now end here since its offtopic, probably better in a dedicated thread or does one exist already in any form?
sorry for offtopic :p
mclingo
7th January 2020, 15:13
here:
https://forum.kodi.tv/showthread.php?tid=345566
Klaus1189
7th January 2020, 15:49
The downloads links were all removed from here:
https://forum.kodi.tv/showthread.php?tid=345566
I downloaded 3.0.1 and again it doesn't work. Video plays, but no HDR in OSD of TV and very greyisch. I don't know what I am doing wrong.
oldpainlesskodi
7th January 2020, 16:25
Sorry guys for starting something offtopic.
Klaus1189 - you want the windows api version, which is here: https://forum.kodi.tv/showthread.php?tid=349861
Suggest any further support question should be on that thread.
tyguy
7th January 2020, 18:36
Setting custom resolutions just isn't working for me. It allows me to adjust timings, I pick one that is highly compatible that says it will repeat a frame once a day or once every 6 hours or so, but when I select it i'm still repeating frames every 4 minutes.
chros
7th January 2020, 18:53
Setting custom resolutions just isn't working for me. It allows me to adjust timings, I pick one that is highly compatible that says it will repeat a frame once a day or once every 6 hours or so, but when I select it i'm still repeating frames every 4 minutes.
Where do you select it: nvidia control panel or in Windows? Do you use CRU as well?
Atak_Snajpera
7th January 2020, 19:44
Has default tonemapper been tweaked/replaced? New version is noticeable different in terms of saturation
Older MadVR (sorry I do not remember version number)
https://i.postimg.cc/DZnqZXYt/a-madvr.png
Latest MadVR 0.92.17
https://i.postimg.cc/kgSW-8rcC/Sony-4-K-HDR-Camp-mp4-snapshot-01-38-431.png
el Filou
7th January 2020, 19:56
From changelog:madVR v0.92.17:
* small HDR tone mapping saturation improvement
madVR v0.92.15:
* HDR: improved overall tone mapping quality
* HDR: added trade quality option "compromise on tone & gamut mapping accuracy"There have also been a lot of changes in the HDR test builds from the AVS Forum projector thread (still a work in progress)
Atak_Snajpera
7th January 2020, 20:13
Does not look like tone mapping saturation improvement to me ;) But Who am I to judge...
Update: Unchecking option "compromise on tone & gamut mapping accuracy" fixes this issue. Old good tonemapping is back :)
https://i.postimg.cc/Cxg77Hx9/Sony-4-K-HDR-Camp-mp4-snapshot-01-38-431.png
el Filou
7th January 2020, 20:56
Yes, ideally that shouldn't be checked by default imho as it's quite detrimental to quality and you're not the first person to notice it, but otoh tone mapping needs quite a lot of processing power and I suspect madshi did that so madVR runs OK with default settings even on really low-end (i.e. iGPU) hardware.
Atak_Snajpera
7th January 2020, 22:15
I do not think that tonemapping itself is very demanding on GPU. IT works fine on ultra low end geforce gt 710
4k image scaling is much more demanding. I have to select less intensive algorithm for that pathetic 1 CU GPU ;)
huhn
7th January 2020, 23:26
the current in progress version killed 1080 by just tonemapping with a version to saying it will be released like that but still.
nevcairiel
8th January 2020, 00:48
Its not the tone mapping itself that kills your GPU, but analyzing the image to decide how to tonemap, since the new in-development test versions are basically doing dynamic tonemapping without having metadata to drive it - with great success, at that. And of course since the algorithm is still being actively changed, it may be in a more change-friendly format rather then overly optimized.
Alexkral
8th January 2020, 06:54
Does not look like tone mapping saturation improvement to me ;) But Who am I to judge...
Update: Unchecking option "compromise on tone & gamut mapping accuracy" fixes this issue. Old good tonemapping is back :)
Checking "compromise on tone & gamut mapping accuracy" means that the tone mapping is done in RGB instead of ICtCp. That means changes in hue and saturation. Since ICtCp is a perceptually uniform color space, using it for tone mapping is usually considered more accurate. However, as you can see for yourself, the matter is not so simple.
mclingo
8th January 2020, 14:26
tone mapping was pretty much unusable on my old RX580 without that selected, hoping MADSHI can come up with something else for lower end users that doesnt compromise saturation, he may have already done this though, hoping to get a final release soon.
el Filou
8th January 2020, 14:54
Did you by any chance enable highlight recovery? That can put a heavy hit on the GPU too.
A solution to gain a few ms with 4K HDR is to use measurement files, and D3D11 native decoding if it doesn't have any downside for you (e.g. Blu-ray menus in JRiver).
I can do tone mapping for 24p without any quality compromise and with highlights recovery and SSIM2D downscaling to 1080 on a 1050 Ti with measurement files, so surely an RX580 that is 2 times more powerful can do it too. Maybe switching to a lower quality chroma upscaling could help.
aufkrawall
8th January 2020, 15:53
There is some kind of "basic expenses" with madVR that already is really much for Polaris, unfortunately. Some jinc scaling, HFR video and the better tone mapping really fries the GPU already.
huhn
8th January 2020, 16:10
polaris has only problems with ngu nothing else.
mclingo
8th January 2020, 18:28
Did you by any chance enable highlight help.
Indeed yes, however that switch got me from over 60ms to under 30ms where enabling highlights didnt really change it that much for me.
I actually tried lots of things, changing Chroma and stuff, this switch made the biggest different and didnt seem to do anything to the image until it was broken in the later versions.
mclingo
8th January 2020, 20:15
just had another look when I got home. My rendering times are just over 30 ms but I have chroma and upscaling set to NGU high. If I select dont measure peak frame I just get a black screen, I think this is known bug so I just have compromise on luminescence selected.
This is on my 5700 msi OC which is a lot faster than my RX580 and a bit slower than the 5700XT stock overall.
I'm not seeing any glitches or frame drops at 30ms so I dont mind it being that high for now, hoping the next version will be better optimised.
Alexkral
8th January 2020, 22:59
this switch made the biggest different and didnt seem to do anything to the image until it was broken in the later versions.
I'd say that hasn't changed, it's just that depending on the image the difference is sometimes not noticeable at all.
mclingo
9th January 2020, 11:24
cheers, i'll have another look tonight then, hoping AMD will get the HDR issue fixed soon though :)
mclingo
9th January 2020, 14:37
do you know is this problem occurs for both outputting in HDR format and non HDR format for tone mapping, i'm not outputting in HDR format at the moment due to the AMD BT2020 APi issue.
Alexkral
9th January 2020, 20:08
The switch works the same when outputting in HDR, but the problem with AMD HDR will be the same as well.
Magik Mark
11th January 2020, 12:42
Guys,
Can you see a difference between NGU AA and Nvidia AA? Need you thought on this. Thanks
Sent from my iPhone using Tapatalk
huhn
11th January 2020, 13:51
i'm pretty sure everyone can see the difference between an image scaler and an video game anti aliasing algorithm. they are fundamental different.
Siso
11th January 2020, 16:04
I read in a few forums that enabling 10 bit (8 bit+frc) in nvidia control panel, could affect madvr's dithering. Is it true, and will it affect a calibration with displaycal?
huhn
11th January 2020, 18:39
I read in a few forums that enabling 10 bit (8 bit+frc) in nvidia control panel, could affect madvr's dithering. Is it true, and will it affect a calibration with displaycal?
yes there are settings that effect madVR dithering but you don't have have an option for 8 bit+FRC in NV control center.
and yes your end device could behavior differently when a 10-12 bit signal is send instead of a 8 bit signal but that should be rare very rare. this would effect your calibration.
Siso
11th January 2020, 18:59
In short, I'll stay to 8 bit.
ryrynz
11th January 2020, 21:28
In short, I'll stay to 8 bit.
No need to quote here, if you're not answering a question (thus notifying them of a reply) and their post is directly above yours, there's no point. You're increasing the thread space for nothing.
shimarin
13th January 2020, 03:28
No need to quote here, if you're not answering a question (thus notifying them of a reply) and their post is directly above yours, there's no point. You're increasing the thread space for nothing.
that’s good to know.
ryrynz
13th January 2020, 04:35
Personally I find education is most useful when put into practice.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.