madVR - high quality video renderer (GPU assisted)

[ryrynz]

I would be surprised if it made a bit of difference whether you send them an 8-bit or a 10-bit input.
Perhaps the last generation or two of Panasonic sets might benefit from it, but I have my doubts.

I also wonder if it might be worthwhile to send them 60Hz and use SmoothMotion, because 60Hz is a marked improvement for gradation over 24/50Hz inputs on those displays.
The higher the refresh rate, the fewer steps of gradation a plasma has

Looking at the smallramp pattern in 8 bit output @ 60hz and 12/10 bit output at 24hz I can confirm that the greyscale pattern is indeed smoother at the 12/10 bit output setting on a Panasonic VT50.

I just wish I could have 12/10 bit output and smooth motion... oh well.

Would also be nice if madVR could change the bit depth for me as well as changing the refresh rate now that Nvidia has allowed user selection of this in their control panel.

I will mention that Nvidia's latest drivers handle 24Hz a lot better than previous ones, the mouse used to judder quite badly before.

Anyone had any issues with madVR jumping in and out of exclusive mode when right clicking using D3D11? Happens on both my PCs.

[James Freeman]

Exclusive mode should exit when right clicking.
The menu that appears is part of windows and can't be displayed in exclusive mode.

[yogibeezwax]

When I try to access madvr settings it shows older version of madvr (0.87.11). Only after opening settings through madHcCrl.exe in madVR folder does it continue to show correct version in settings window. Everytime I restart the PC it reverts back to the older version until I manually open madHcCrl.exe.

Seems weird seeing how I only installed v0.88.8 on a fresh win7 install. Might that be the reason why I'm missing things like 3D11(enabled under settings) under statistics?

[James Freeman]

yogibeezwax,
Is it really your first post?

[yogibeezwax]

Yes it is.

[huhn]

When I try to access madvr settings it shows older version of madvr (0.87.11). Only after opening settings through madHcCrl.exe in madVR folder does it continue to show correct version in settings window. Everytime I restart the PC it reverts back to the older version until I manually open madHcCrl.exe.

Seems weird seeing how I only installed v0.88.8 on a fresh win7 install. Might that be the reason why I'm missing things like 3D11(enabled under settings) under statistics?

and that's the first install of madVR right?

[yogibeezwax]

Well, I had to format my PC and make a clean install..downloaded v0.88.8. However I did backup my settings in jriver, which at the time was using the older version of madvr...might there be some residual effect of that when I restored my settings in jriver?

[huhn]

Well, I had to format my PC and make a clean install..downloaded v0.88.8. However I did backup my settings in jriver, which at the time was using the older version of madvr...might there be some residual effect of that when I restored my settings in jriver?


i guess so.

you only need to save the settings.bin the rest doesn't matter.

[yogibeezwax]

Thanks for the help huhn! Might opt for another format as my motherboard is giving me hell right now..

[luk008]

Is madVR's image doubling equivalent to nnedi3_rpow2 of avisynth?

[huhn]

Is madVR's image doubling equivalent to nnedi3_rpow2 of avisynth?

it's a port of the openCL version so "yes"

[madshi]

Would also be nice if madVR could change the bit depth for me as well as changing the refresh rate now that Nvidia has allowed user selection of this in their control panel.
There's no API available for that atm.

When I try to access madvr settings it shows older version of madvr (0.87.11). Only after opening settings through madHcCrl.exe in madVR folder does it continue to show correct version in settings window. Everytime I restart the PC it reverts back to the older version until I manually open madHcCrl.exe.

Seems weird seeing how I only installed v0.88.8 on a fresh win7 install. Might that be the reason why I'm missing things like 3D11(enabled under settings) under statistics?
JRiver MC comes with its own version of madVR. Probably you have that, and another madVR installation seperately to that? Make sure you update MC's version of madVR, too. Not sure if MC will keep your manually updated version of madVR, or it if will redownload the "official" madVR version shipping with MC? There's probably a setting somewhere in MC for that, but I don't know...

[6233638]

Interesting! Seems that your GPU driver doesn't support as many prepresented frames when 10bit output is active.

Can you confirm that the madVR default settings for the queue sizes and prepresented frames (but with DX11 activated, of course) work fine?Yes, the default (of 8) works fine. That's actually what I've been using the past few days without any problem.
In my brief testing it looked as though 10 would also work, but I just wanted to watch something, so when I found a value that I knew was working, I've stuck with it.

This could be attributed to the dithering algo (error diffusion vs ordered dithering), but it could also mean that your display doesn't handle 10bit input as well as it should. Might require some tests to find out which is which, once I've allowed error diffusion to be used for 10bit output again.After doing further testing, I think it is just that the smoother image is allowing this error to be more visible.
The gradient is, overall, much smoother but there are one or two bands which become more visible with a 10-bit output.
Those areas seem to be more defined in the 8-bit output as well, but the additional noise hides it better. I guess it's just an imperfect internal LUT for the display.

Try the first post of this thread. "madTestPatternSource" is what you want.
Oh I thought that was supposed to generate a >8-bit gradient.
I have used it for testing in the past, but wanted to be sure that it was specifically an undithered 8-bit image as a demonstration of why debanding may still be necessary regardless of the quality of the source, if that source is still 8-bit.

[madshi]

Oh I thought that was supposed to generate a >8-bit gradient.
All the madTestPatternSource test patterns are simple 8bit test patterns. However, if you zoom the test patterns, the upscaling algorithm turns them into a higher bitdepth ramp. That's especially true for the "smallramp.ytp".

[madshi]

madVR v0.88.9 released

http://madshi.net/madVR.zip

* optimized lots of HLSL pixel shaders -> performance improvements
* added a dedicated downscaling render path to speed up 4K playback etc
* removed "bad" scaling algos (Lanczos8, Jinc4, Jinc8)
* modified "high" deband preset to also use gradiant angle analyzation
* updated to latest Shiandow deband script
* error diffusion now also supports 10bit output
* modified D3D11 refresh rate behaviour
* optimized rendering time averaging logic
* rewrote "install.bat" and "uninstall.bat" once more
* SMPTE 170M and SMPTE 240M are now using the SMPTE C 3dlut
* sRGB now uses the BT.709 3dlut
* fixed: JRiver MC20 crashed when stopping FSE 10bit playback
Please note that the performance optimizations *may* have introduced some new bugs. I hope not, but it's hard to be sure. There are so many combination of settings/paths that it's hard to test everything. Don't expect miracle performance improvements. The improvements are relatively small, somewhere between 0% and 30% on my Intel HD4000. Generally the Anti-Ring variants benefit less. Without Anti-Ring the improvements are larger. Haven't tested on NVidia/AMD. I think they should see some performance improvements, too, not sure how much. There are no improvements for NNEDI3 and error diffusion, though, but everything else might see a small performance boost.

4K playback on FullHD monitors should be noticeably faster now. Basically the new build now handles chroma separately from luma, if the video is downscaled by a relatively large factor. This way chroma doesn't have to be upscaled to the full luma resolution first, which saves some time. You can see this in the OSD: If chroma is upscaled to luma resolution and then both are downscaled to the target resolution, then you should see "chroma > something" and "image < something" in the OSD. If chroma is not upscaled to full luma resolution, you should instead see "chroma > something" (or even "chroma < something", if you downscale *a lot*) and "luma < something". In the first case luma and chroma are merged and converted to RGB before scaling. In the latter case chroma and luma are scaled separately and only merged and converted to RGB after scaling (to save performance).

[madshi]

madVR v0.88.9 comes with a new version of Shiandow's deband algorithm. And it also has a slightly modified "high" preset of the original deband algorithm. The new "high" preset now makes use of the gradient angles analyzation, too (just as "low" and "medium" have always done). You can activate the trade quality option "don't analyze gradient angles" to get the old "high" preset.

Please once again compare the deband algos and let me know which you prefer, for all "high", "medium" and "low". I would like to finish the comparison soon and finally decide which algorithm to keep and which to drop. Thanks!

[huhn]

* removed "bad" scaling algos (Lanczos8, Jinc4, Jinc8)

i'm pretty sure someone will complain about this sooner or later.
removing options...

but i agree they are not good.

[6233638]

i'm pretty sure someone will complain about this sooner or later.
removing options...
but i agree they are not good.I would hope not, because none of those are options that people should be using.
Worse, anti-ringing may give the initial impression that it is OK to use Lanczos8 (higher numbers are better, right?)

With all the new options we have available, there really doesn't seem to be any reason for those to exist.
I'd also argue that Bicubic 100 should go, but that was put in as a request and I suppose some people may still be using it.
It's not harmful like Lanczos8 is, just not the best option to use.

Everything else I'd recommend leaving in.
There are reasons that someone may prefer any one of the remaining options.

If the goal here is to simplify the options, if it's possible to enable/disable options selectively, changes I might also suggest would be to disable the anti-ringing option for SoftCubic upscaling (degrades image quality) and perhaps remove the linear light option for upscaling altogether. (though not downscaling - or at least, not downscaling with Catmull-Rom)

madVR v0.88.9 comes with a new version of Shiandow's deband algorithm. And it also has a slightly modified "high" preset of the original deband algorithm. The new "high" preset now makes use of the gradient angles analyzation, too (just as "low" and "medium" have always done). You can activate the trade quality option "don't analyze gradient angles" to get the old "high" preset.

Please once again compare the deband algos and let me know which you prefer, for all "high", "medium" and "low". I would like to finish the comparison soon and finally decide which algorithm to keep and which to drop. Thanks!For what it's worth, I really like your debanding algorithm, and the fact that it is monochrome, unlike shiandow's.
However I have really not done enough testing to do a proper comparison between them.

One of the things I like with your debanding algorithm is that I can quickly hit a hotkey on my keyboard to switch the strength between low/med/high depending on what the source requires. I have profiles which generally get it right (disc-based media gets low debanding, downloaded media gets med/high depending on the source resolution) but sometimes I have a source which requires something other than the default and it's nice to have the option to quickly switch between them.

What I might suggest is that the decision be between either both options remaining, or sticking to your debanding algorithm.

It's true that the options are starting to get a bit overwhelming, but I think that can be rectified with some UI changes (more "friendly" presentation that explains why a user may wish to use one or the other) rather than having to strip these options out - unless everyone concludes that there's no need for the shiandow deband to be there, I suppose.

4K playback on FullHD monitors should be noticeably faster now. Basically the new build now handles chroma separately from luma, if the video is downscaled by a relatively large factor. This way chroma doesn't have to be upscaled to the full luma resolution first, which saves some time. You can see this in the OSD: If chroma is upscaled to luma resolution and then both are downscaled to the target resolution, then you should see "chroma > something" and "image < something" in the OSD. If chroma is not upscaled to full luma resolution, you should instead see "chroma > something" (or even "chroma < something", if you downscale *a lot*) and "luma < something". In the first case luma and chroma are merged and converted to RGB before scaling. In the latter case chroma and luma are scaled separately and only merged and converted to RGB after scaling (to save performance). I have reported one bug which seems related to this, but this seems like it goes back to the days of scaling chroma independently of the source, rather than scaling it to the luma resolution and then scaling both by the same algorithm.
The reason for that was because it means that chroma scaling quality is unaffected by your source and output resolutions.

If you start doing something other than 2x scaling for chroma, the source and output resolution can affect the quality of chroma scaling.

I understand that this makes sense for 4K where you could in theory not scale chroma at all for output on a 1080p display (4:2:0 4K = 1080p chroma channel) and as a trade quality for performance option it makes perfect sense.
Though I don't have much 4K content yet, I'd still prefer the option of upscaling chroma first and then downscaling - even if it's going from "1080p" 4:2:0 to 4K RGB and back to 1080p RGB.

[Tanis138]

NNEDI3 image doubling is not working in 0.88.9
MPC-HC x64 (1.7.8.225) shows error:
http://i.imgur.com/h3JRymY.png
DX11, Windowed mode.
0.88.8 - everything is OK.
When I uncheck "double luma resolution" everything is also OK.
Win 7 x64, GeForce GTX 660, Driver 352.86

[huhn]

I would hope not, because none of those are options that people should be using.
Worse, anti-ringing may give the initial impression that it is OK to use Lanczos8 (higher numbers are better, right?)

trust me i see lanczos 8 or jinc 8 a whole lot on screens...

[michkrol]

@madshi, thanks for the continued work on madVR :)

NNEDI3 image doubling is not working in 0.88.9
MPC-HC x64 (1.7.8.225) shows error:
http://i.imgur.com/h3JRymY.png
DX11, Windowed mode.
0.88.8 - everything is OK.
When I uncheck "double luma resolution" everything is also OK.
Win 7 x64, GeForce GTX 660, Driver 352.86
I'm experiencing the same problem with both NEDI and NNEDI3 doubling on Windows 8.1 x64, Geforce 750Ti, same drivers (352.86).

[tobindac]

Nice install.bat!

PS. I know those things are trivial to some but I think they are great for everyday life because additively they save a lot of time to users if done correctly.

[VenomousNinja]

Same OpenCL error for me. Win 7x64 madVR 32 bit + MPC-BE. driver 352.86 (GTX970)

http://i57.tinypic.com/2ajx7yb.png

[MS-DOS]

For me, NNEDI just produces a pink'ish image.

[huhn]

For me, NNEDI just produces a pink'ish image.

nvidia like the rest?

[MS-DOS]

AMD 5870 with cat 13.12

[Anima123]

@madshi, thanks for the continued work on madVR :)


I'm experiencing the same problem with both NEDI and NNEDI3 doubling on Windows 8.1 x64, Geforce 750Ti, same drivers (352.86).

Wasn't NEDI implemented by shaders instead of OpenCLs? How can it trigger OpenCL compile error?

[ThurstonX]

For me, NNEDI just produces a pink'ish image.
Same here: video is visible (barely), but with a severe pink/purplish pink overlay. Fine when reverting to 0.88.8.

D3D11 exclusive (8 bit)
NNEDI3 Luma Doubling forced

Win7 x64 Ultimate
R7 250

[MS-DOS]

Wasn't NEDI implemented by shaders instead of OpenCLs?

It wasn't. I wonder if it's ever possible.

EDIT: Sorry, misread it as "NNEDI", which is the one on OpenCL.

[fairchild]

Same here: video is visible (barely), but with a severe pink/purplish pink overlay.

Same here NNEDI3 luma doubling producing pink overlay

Win7 x64 on AMD 7870 with 14.12 drivers (latest MPC-HC and LAV nightly)

[TobiMan]

Same here: video is visible (barely), but with a severe pink/purplish pink overlay. Fine when reverting to 0.88.8.

D3D11 exclusive (8 bit)
NNEDI3 Luma Doubling forced

Win7 x64 Ultimate
R7 250

I can confirm this. Made me miss the 0:1 in the UEFA-Cup Final (just kidding...).

The pinkish overlay appears when enabling image doubling and seems independent from other options.

D3D11 exclusive (10 bit)
NNEDI3 Luma Doubling

Win 8.1
Radeon 7850

Edit: works with 0.88.8, not with 0.88.9

[nevcairiel]

It wasn't. I wonder if it's ever possible.

NEDI is shaders, NNEDI3 is OpenCL.

[TobiMan]

NEDI is shaders, NNEDI3 is OpenCL.

Oh... didn't know that. By the way, the pinkish overlay does not appear with NEDI.

[leeperry]

:thanks: for the new version.

NEDI/NNEDI3 work fine in 88.9 with DX9 on W7SP1/HD7850/13.12

[TobiMan]

:thanks: for the new version.

NEDI/NNEDI3 work fine in 88.9 with DX9 on W7SP1/HD7850/13.12

Mhhh... no difference on my side, no matter if I use DX9 or DX11.

[huhn]

windwos 10 10122:
nvidia 760 GTX 352.84 : issue
amd r9 270 15.4.1: works fine

[MS-DOS]

NEDI is shaders, NNEDI3 is OpenCL.

Doh... I should learn to remember there's also NEDI in MadVR now. I mistook it for good old NNEDI3.

[JPulowski]

NVIDIA GeForce GTX690, 352.86, Windows 8.1 64-bit.
After the installation of 0.88.9, if I enable anything related with NNEDI3 I get the following error:
http://i.imgur.com/QjigkfN.png

[SecurityBunny]

NVIDIA GeForce GTX690, 352.86, Windows 8.1 64-bit.
After the installation of 0.88.9, if I enable anything related with NNEDI3 I get the following error:
http://i.imgur.com/QjigkfN.png

Can confirm I'm also experiencing the issue, but it seems to be related to NNEDI3 being used in Chroma Upscaling. NNEDI3 in Luma Doubling with Jinc Chroma Upscaling, playback is fine.

[madshi]

Ok, seems there are 2 different issues when using NNEDI3:

1) pink screen
2) OpenCL compiler error (seemingly only NVidia)

I can reproduce the first problem, but not the 2nd. Anyway, I've changed something, and hope that both bugs are fixed in this text build. Can you please confirm?

http://madshi.net/madVR889test.rar

[yok833]

Hello, the fix doesn t work with my GTX970 ... If I replace NNEDI3 by JINC everything goes back to normal...

[Werewolfy]

madVR v0.88.9 comes with a new version of Shiandow's deband algorithm. And it also has a slightly modified "high" preset of the original deband algorithm. The new "high" preset now makes use of the gradient angles analyzation, too (just as "low" and "medium" have always done). You can activate the trade quality option "don't analyze gradient angles" to get the old "high" preset.

Please once again compare the deband algos and let me know which you prefer, for all "high", "medium" and "low". I would like to finish the comparison soon and finally decide which algorithm to keep and which to drop. Thanks!

Shiandow's debanding is a lot better now! On some scenes it beats the high preset but still not on the picture I sent. It's a difficult choice, I can't decide now I need to do more tests.
On the other side, the "add grain" option is not very convincing, it adds a LOT of grain everywhere and where it's not necessary. I really don't like it.
But thanks Shiandow for all your work, you improved a lot your algo since the first version I tested :)

I saw you set Angleboost at 1.5 and Maxangle at 0.14 in the high preset. I wouldn't set Angleboost any higher than 1.4 because I found a scene where 1.5 harms more than it helps, I think 1.4 is the threshold here. In my initial post I set Maxangle at 0.10 and I agree it's a little bit to low, I would raise it to 0.12 but not 0.14. I don't really find a scene where 0.14 is better than 0.12 but we do lose more details.

I have better rendering times with your latest version but NNEDI 3 doesn't work, same error as people mentioned earlier.

Test build just fixed the issue :)

[madshi]

Hello, the fix doesn t work with my GTX970 ... If I replace NNEDI3 by JINC everything goes back to normal...
As I said, there were two different problems. So "the fix doesn't work" doesn't help me. Which of the two problems did you have, or do you still have, with the test build?

[huhn]

Ok, seems there are 2 different issues when using NNEDI3:

1) pink screen
2) OpenCL compiler error (seemingly only NVidia)

I can reproduce the first problem, but not the 2nd. Anyway, I've changed something, and hope that both bugs are fixed in this text build. Can you please confirm?

http://madshi.net/madVR889test.rar

i still have the openCL bug with nvidia.

[madshi]

What is the exact error message now?

[TobiMan]

Ok, seems there are 2 different issues when using NNEDI3:

1) pink screen
2) OpenCL compiler error (seemingly only NVidia)

I can reproduce the first problem, but not the 2nd. Anyway, I've changed something, and hope that both bugs are fixed in this text build. Can you please confirm?

http://madshi.net/madVR889test.rar

Cool... works for me now!

D3D11 exclusive (10 bit)
NNEDI3 Luma Doubling

Win 8.1
Radeon 7850

[fairchild]

I can reproduce the first problem, but not the 2nd. Anyway, I've changed something, and hope that both bugs are fixed in this text build. Can you please confirm?

http://madshi.net/madVR889test.rar

If I leave only double luma enabled, then I still have a pink screen.

If I also also enable double chroma, then it works.

D3D9 exclusive (8-bit)

[6233638]

Ok, seems there are 2 different issues when using NNEDI3:
1) pink screen

I can reproduce the first problem, but not the 2nd. Anyway, I've changed something, and hope that both bugs are fixed in this text build. Can you please confirm?

http://madshi.net/madVR889test.rarSeems to have fixed the pink screen here.
EDIT: But it's crashing in JRiver again.

[huhn]

What is the exact error message now?

your test build is only 32 bit need a sec to do a real test sorry didn't see that.

EDIT: this build fixed the openCL issue for me.

[madshi]

@huhn, we're talking about the OpenCL compiler error message box, right? Just need confirmation that both problems are fixed, pink screen *and* compiler error.