madVR - high quality video renderer (GPU assisted)

[Dogway]

Remember the chroma is half the resolution of the luma so you need to upscale it before doubling somehow

I might be missing something but, can't you double chroma with nnedi3, then up to 4:4:4 target display resolution with the chroma upscaling kernel? Why do you need to do a mini-upscale first?

[huhn]

I think I understand what you mean, first line is converting to 4:4:4, then it upscales the whole thing with nnedi (hence image >, and not luma >), but in my opinion it shouldn't be doing that... it's not a good idea to use a a scaler before nnedi because you are amplifying artifacts, also you are adding one more step to chroma.

chroma > mitchell > nnedi (double) > resizer (for up or downscale to 1080)

has the behavior changed in last version?

edit: btw I don't think what you say is right, I disabled chroma nnedi and I get the same OSD output.

make new screen with disabled nnedi3 chroma doubling. there should be a new chroma line.

[ibius]

Issues with D3D11:
1. Going FSE is fine, but after first seek presentation glitches start piling up by the dozen every second during playback, enabling 'Present a frame for every v-sync' fixes it, but windowed FS mode works fine without. All queues apart from render queue (see below) are full at the time.
2. After going windowed FS or FSE, render queue is always only 3-5/8, other queues are full, and I get increased CPU usage, e.g. from ~7% to ~30% on my 3,6GHz Intel Core2Duo.
3. Sometimes after seeking/stopping playback video gets stuck in a loop, jumping between few frames.
4. Render times are better compared to D3D9, but present times are way worse, e.g. going from 0.12ms to 0.9x/1.xx ms in windowed mode, in windowed FS or FSE they are even higher (although only chroma is scaled).

I did more tests and figured out that disabling smooth motion fixes first issue.
Fun fact, without 'Present a frame for every v-sync' enabled, FSE starts piling up presentation glitches right after going into FSE, with smooth motion all was well until I tried to seek.

[Dogway]

make new screen with disabled nnedi3 chroma doubling. there should be a new chroma line.

yep, now chroma uses another scaler (third line), problem is it uses lanczos which I only set for luma upscaling... instead of mitchell

[huhn]

yep, now chroma uses another scaler (third line), problem is it uses lanczos which I only set for luma upscaling... instead of mitchell

working as intended. the image upscaler was used in that version.

[XMonarchY]

madshi
Ok, good to hear. Is this with Jinc3 AR selected for image upscaling?

BTW, there's one difference between v0.87.x and v0.88.x that I forgot to mention: The setting for image quadrupling is now also applied for "octadrupling" and "hexadrupling". Meaning, NNEDI3 doubling is used as long as upscaling is needed. v0.87.x used NNEDI3 max twice, v0.88.x doesn't have this limit. Is it possible that NNEDI3 is used with v0.88.x on your PC more than twice? You can see that in the debug OS.

Yes, with Jinc 3 tap AR for Image Upscaling.

In OSD I just see this..:
Chroma>NNEDI32
Luma X>NNEDI32<Catmull-ROM AR
Chroma X> Catmull-ROM AR

I can even set Chroma Upscaling to NNEDI3 128 neurons and keep both Doubling and Quadrupling @ NNEDI3 32 neurons without any frame drops.

I have 2 separate questions:
- Is it worth disabling desktop composition?
- What is a good Shiandow's Deband setting for low/medium-low quality content? I know the original debanding settings for such content should be at least medium for strength and high for fade in/out
- I assume both algorithms can be used together (the original and Shiandow's?)

ALSO, 3DLUT organization is plain buggy. I have content specifically labeled SMPTE C In Ctrl+J menu is says SMPTE C), but if I place Rec.709 3DLUT into madVR Rec.709 line and place Rec.601 3DLUT into Rec.601 line, then madVR will actually use Rec.709 line and Rec.709 3DLUT to render content specifically labeled SMPTE C. The only way to use 3DLUT's accurately is to place all/any 3DLUT's into Rec.709 line in madVR, regardless of whether those 3DLUT's are Rec.601 or Rec.709. madVR will use Rec.709 line (and whichever 3DLUT in it) to render ANY content, regardless of whether that content is labeled Rec.709 or SMPTE C. I used the latest HCFR to test Rec.601 3DLUT in Rec.709 line and it came out just right - very accurate Rec.601 results. Someone stated that Rec.601 3DLUT in Rec.709 line in madVR would produce inaccurate/wrong results, but my HCFR testing proved otherwise. Its like madVR actually alters the 3DLUT in any way. It can only decide which 3DLUT to use, but that feature does not work.

[Asmodian]

I might be missing something but, can't you double chroma with nnedi3, then up to 4:4:4 target display resolution with the chroma upscaling kernel? Why do you need to do a mini-upscale first?

Isn't that the same thing?

1920x1080p 4:2:0 source.

step 1) 960x540 chroma to 1920x1080 using 'chroma upscaling'. This is the only step 'chroma upscaling' is used for. This converts the 4:2:0 to 4:4:4.
step 2) 1920x1080 chroma to 3840x2160 with NNEDI3 (chroma doubling) or, if not doubled, to the target resolution with 'image upscaling'.

[madshi]

I could list the modes which are in the edit fields for display mode switching
Yes, this would be great.
Well, to be honest, I don't think this is a good time to add this feature. The whole refresh rate changing will be rewritten sooner or later and work quite differently to how to works now. It makes more sense to wait until then.

Btw, can we get dithering for every frame presented? With Dx11 path and "present every vsync" option that should beat any FRC.
For high quality junkies I would strongly recommend to match refresh rate to movie frame rate. If you do that, you already get a changing dithering for each frame right now. Of course it would be possible to change the dither pattern for repeated frames, too, if the refresh rate is higher than the movie framerate. But it would increase GPU power consumption, and to be honest, I have a *lot* of things to do which hopefully bring a bigger image quality improvement than that would bring. Just my 2cents, of course.

I guess it's a known issue with Madvr 88.4 and 88.5 because I have an issue watching any movie with some random presention error and Renderer queue and all others are not full.
I'm not sure what you mean. There are known issues with 88.4 and 88.5, but not those you're describing.

What is the differences between Font Renderer : Vector Text Renderer and Bitmap Text Renderer ?
I have no idea. madVR doesn't have any such options.

1. Going FSE is fine, but after first seek presentation glitches start piling up by the dozen every second during playback, enabling 'Present a frame for every v-sync' fixes it, but windowed FS mode works fine without. All queues apart from render queue (see below) are full at the time.
You will have to use "present a frame for every v-sync" then. Driver bug or D3D11 bug, not my fault.

2. After going windowed FS or FSE, render queue is always only 3-5/8, other queues are full, and I get increased CPU usage, e.g. from ~7% to ~30% on my 3,6GHz Intel Core2Duo.
This is exactly the effect you would get with "Nvidia control panel 'Max. pre-rendered frames'" set to a fixed low value. So my best guess is that either the GPU uses a different setting for this behind your back, or there are profiles active somehow which set a low value for this, or there's some GPU driver bug, or something.

3. Sometimes after seeking/stopping playback video gets stuck in a loop, jumping between few frames.
Doesn't occur on my PC. Please try again with the next build.

4. Render times are better compared to D3D9, but present times are way worse, e.g. going from 0.12ms to 0.9x/1.xx ms in windowed mode, in windowed FS or FSE they are even higher (although only chroma is scaled).
Again this points to "Max. pre-rendered frames" not being set correctly. Or the GPU ignoring that settings.

I noticed that ordered dithering is a very noisy process. I found it fun lately to turn on 1bit output and see very obviously some algorithmic patterns. It appears not dithering at all gives the most "stable" unnoisy picture while error diffusion is more stable and 'random' is a total mess.

I'm surprised, but it appears no dithering at all is a viable choice.
"No dithering" is not a viable choice *at all*. Testing with 1bit is not a good test for this. Try 2bit. See here:

http://madshi.net/2bitNoDithering.png
http://madshi.net/2bitOrderedDithering.png

(CAUTION: Please zoom the images in the browser to 100%, otherwise the dither pattern will look ugly.)

I think no sane human could possibly prefer the image with no dithering there.

You will *always* need dithering, because its about the mathematical process, not about the quality of the source. In fact, its entirely independent of that (although its going to be more obvious in some sources than in others, of course)
If such a perfect source would exist, then dithering also wouldn't add noise, since dithering, by definition and design, is only used to spread the rounding error to multiple pixels, instead of accumulating it all in one. If there wouldn't be a rounding error, there would be no "noise".

At the end of the day, movies are all going to be in YUV, and YUV needs to be converted to RGB. This conversion process (if done right) results in floating point values, which need to be converted to 8-bit (or recently, 10-bit) on output. If you don't use dithering, you will effectively cut off data. Thats also were your analogy goes wrong, dithering isn't about hiding flaws, its about preserving data when converting to a lower bitdepth (ie. from 16/32-bit float, to 8/10-bit integer for output)

Of course you are free to use whatever settings you like, but please don't spread them as advice.
QFT.

I'm a bit confused when you ask "what mode my PC is", where should I look that? Control panel just said (roughly) 1080 native, 60Hz.

Anyways I had a look and I don't find any video that turns my TV to 1080p60 mode, it stays always in PC mode which is fine and bad at the same time... I would expect a bit more consistency for these things (I should be able to treat 60fps sources as every other non-PC source, TV settings wise). 1080p59 is also defaulting to PC mode.

Then I played a 50fps video and screen turned to 50p mode, so here the story does apply.
Anyways I removed the 1080p50 entry and it defaulted to 1080p60 now seemingly and oddly enough "PC mode" (I still think passthrough should be a better idea?).
Sounds all good to me?

My playback is fine (no dropped frames, no glitches).

Anyway, just for info .. when I watch movie 24.000 and refresh rate fix is active, render queue and present queue are low (render queue 3-5/8 and present queue 2-3/8. Average stats present 31.00 ms which is abnormally high, usually 0.05 ms.)
Sounds like you have "Nvidia control panel 'Max. pre-rendered frames'" set to a fixed low value. Set it to "application control".

Your fix never worked for me even before but this time it works! Thanks, great work.
Cool! I did improve it a bit, hoped it might work better in some exotic cases now.

ALSO, 3DLUT organization is plain buggy. I have content specifically labeled SMPTE C In Ctrl+J menu is says SMPTE C), but if I place Rec.709 3DLUT into madVR Rec.709 line and place Rec.601 3DLUT into Rec.601 line, then madVR will actually use Rec.709 line and Rec.709 3DLUT to render content specifically labeled SMPTE C.
How do you know it uses the BT.709 3dlut? If that is really the case, it's a bug and then please enter it to the madVR bug tracker.

[madshi]

madVR v0.88.6 released

http://madshi.net/madVR.zip

* fixed: D3D11 rendering sometimes got stuck (e.g. when minimizing player)
* fixed: NNEDI3 quadrupling with SuperRes didn't work properly (NVidia only)
* fixed: refresh rate fix didn't work in 64bit
* added D3D11 refresh rate fix (proper support for 23p vs. 24p etc)
* added option "octuple luma/chroma resolution"
* re-added NNEDI3 chroma doubling options
* removed limitation to double chroma with Catmull-Rom
* updated Shiandow deband algorithm to latest version
* double clicking tray icon now opens the settings dialog
Please note that image/luma octupling is only applied if you use any of the "upscaling refinement" options. Otherwise this option will be ignored because without "upscaling refinement" the image becomes so soft after quadrupling that there's no use using expensive octupling at that point. Octupling can be useful for upscaling DVDs to 4K (640 > 1280 > 2560 > 5120 < 3840).

Shiandow's deband algorithm was updated to the latest version. Could everyone please re-test? Please note that the defaults have changed, but the settings dialog will remember your previous values. So please manually change the values to threshold 0.2 and detail level 1, and start testing with those values. Your vote counts in deciding whether I'll keep using the "old" debanding algorithms or whether I'll replace some or all of the old algos with the new one. If you're not sure which one you like better, please say just that, instead of randomly picking one. If you do like one clearly better than the other, please let me know - thanks!!

Edit: Shiandow has released yet another fine tuned version of his Deband algorithm. Please copy the code from the following post into the file "madVR\legal stuff\Shiandow\Deband.hlsl", then madVR will immediately use the new Deband version:

http://forum.doom9.org/showthread.php?p=1721949#post1721949

[aufkrawall]

Thanks a lot for these changes and fixes.

Could it be that Shiandow's deband doesn't work as intended with this version? I can't see any positive effect.
As a reminder, madVR's and Shiandow's old deband filters:
http://forum.doom9.org/showpost.php?p=1721014&postcount=29510

Shiandow new (new default values):
http://abload.de/thumb/shiandowdef9rom5.png (http://abload.de/image.php?img=shiandowdef9rom5.png)

Threshold changed to 2.0:
http://abload.de/thumb/shiandow2.0zlpae.png (http://abload.de/image.php?img=shiandow2.0zlpae.png)

Changing detail levels doesn't change much.

I also quickly benchmarked performance impact of Jinc3 chroma scaling over C-R (both AR) when doing NNEDI3 64 luma quadrupling.
GPU usage was pretty much totally identical (and clocks too):
http://abload.de/img/abm2o01.png (http://abload.de/image.php?img=abm2o01.png)

[Shiandow]

Thanks a lot for these changes and fixes.

Could it be that Shiandow's deband doesn't work as intended with this version? I can't see any positive effect.
As a reminder, madVR's and Shiadow's old deband filters:
http://forum.doom9.org/showpost.php?p=1721014&postcount=29510

[...]



Hmm, that's not quite what's supposed to happen. For now could you try placing a file called "Deband.hlsl" in the MadVr/legal stuff/Shiandow folder, with the code below? Since madshi has been so kind to conform to the LGPL requirements this should replace the internal shader. In the code below I've removed one of the steps in the algorithm that may have been causing those problems.


// This file is a part of MPDN Extensions.
// https://github.com/zachsaw/MPDN_Extensions
//
// This library is free software; you can redistribute it and/or
// modify it under the terms of the GNU Lesser General Public
// License as published by the Free Software Foundation; either
// version 3.0 of the License, or (at your option) any later version.
//
// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
// Lesser General Public License for more details.
//
// You should have received a copy of the GNU Lesser General Public
// License along with this library.
//
sampler s0 : register(s0);
sampler s2 : register(s2);
float4 infoConsts1 : register(c0);
float4 infoConsts2 : register(c1);
#define size1 (infoConsts1)
#define ppx (infoConsts1[2])
#define ppy (infoConsts1[3])
#define acuity (infoConsts2[0])
#define threshold (infoConsts2[1])
#define sqr(x) dot(x,x)
#define norm(x) (rsqrt(rsqrt(sqr(sqr(x)))))
#define Get(x,y) (tex2D(s2,float2(ppx,ppy)*(pos + 0.5 + float2(x,y))).xyz)
static const float3x3 YUVtoRGB_709 =
{1.0, 0.0000000000000000, 1.5748000000000000,
1.0, -0.1873242729306488, -0.4681242729306488,
1.0, 1.8556000000000000, 0.0000000000000000};

float4 main(float2 tex : TEXCOORD0) : COLOR0
{
float4 c0 = tex2D(s0, tex);
float2 pos = tex * size1.xy - 0.5;
float2 offset = frac(pos);
pos -= offset;
float4x3 X = {Get(0,0), Get(1,0), Get(0,1), Get(1,1)};
float3x4 LinFit = {{-2, 2, -2, 2}, {-2, -2, 2, 2}, {1, 1, 1, 1}};
float4 w = 0.25*mul(float1x3(offset-0.5,1), LinFit);
float3 avg = mul(float1x4(w), X) / dot(w, 1);
float3 diff = avg - c0;
diff -= clamp(diff, -0.5 / acuity, 0.5 / acuity);
float str = smoothstep(0, threshold, length(diff*acuity));
c0.xyz = lerp(avg, c0, str);
c0.rgb = mul(YUVtoRGB_709, c0.xyz - float3(0.0, 0.5, 0.5));
return c0;
}

[aufkrawall]

Yes, issue is gone. But the result is probably not better than with the previous madVR versions?

[Shiandow]

Yes, issue is gone. But the result is probably not better than with the previous madVR versions?

Is that a question or are you not seeing any improvement? In theory it should still be better than the previous one.

[x7007]

Thanks for the fixes, will check it at home, works fine for now

[aufkrawall]

Is that a question or are you not seeing any improvement? In theory it should still be better than the previous one.
It was an assumption, based on a quick look.
I will do a direct comparison with the same parameters like with the previous version once I'm done with sleeping.

[Shiandow]

It was an assumption, based on a quick look.
I will do a direct comparison with the same parameters like with the previous version once I'm done with sleeping.

Well, when you're back, I made some additional changes to improve the interpolation somewhat. So please update the code of Deband.hlsl with the edited code from my previous comment before you do any testing.

Although, maybe madshi could replace the internal shaders before then? Just don't forget to remove "Deband.hlsl" if you update MadVR.

By the way, well done finding that sample. For some reason I didn't encounter such problems in the other files I tested.

[leeperry]

Oh my, thanks for the daily updates and killer features :)

If I check and then uncheck "octuple luma/chroma resolution", I can't uncheck "double chroma resolution" and "quad chroma resolution" anymore, bug?

This said, 8X is complete overkill for 1080p, I still would like to try it coz there used to be a feature in Avisynth where you would massively upscale, process and then downscale at the very last stage. NEDI is so GPU efficient than why not giving it a shot on 360*288@1080p+NEDI/SuperRes :devil:

I guess 8X luma only isn't possible due to the pixel shifts? I'm not too keen on wasting GPU cycles on chroma.

[cvrkuth]

My playback is fine (no dropped frames, no glitches).

Anyway, just for info .. when I watch movie 24.000 and refresh rate fix is active, render queue and present queue are low (render queue 3-5/8 and present queue 2-3/8. Average stats present 31.00 ms which is abnormally high, usually 0.05 ms.)
When I watch movie 23.976 and refresh rate fix is not active, everything is fine with numbers (render queue 7-8/8 and present queue 6-7/8. Average stats present is 0.05 ms.)

Hope this help,
Regards


Sounds like you have "Nvidia control panel 'Max. pre-rendered frames'" set to a fixed low value. Set it to "application control".


No, I have ATI card (Sapphire Radeon HD 5670 Ultimate 1GB, Catalyst™ 14.12)

[x7007]

I still have issue with my 970 windows 7 at home. it still doesn't use the whole render queue when using D3D11 . without D3D11 it is ok. anyone knows why it happens or how to fix it ? with my laptop G751 970m windows 8 it doesn't happen with it enabled.

Should I enable everything on Upscaling refinement ?

FineSharp
LumaSharpen
SuperRes - Error upscaling quality - high
Refine the image after every ~2x upscaling step

[James Freeman]

I still have issue with my 970 windows 7 at home. it still doesn't use the whole render queue when using D3D11 . without D3D11 it is ok. anyone knows why it happens or how to fix it ? with my laptop G751 970m windows 8 it doesn't happen with it enabled.


It's a known issue with 0.88.x versions in windows 7.


Should I enable everything on Upscaling refinement ?


I hope you are kidding...:rolleyes:

No, you should not.
You should at least have a basic knowledge of what each of these do.

[pirlouy]

That's the reason why madshi wants to remove options. People like him (or me) just don't understand if it's good or bad. :D

@x7007: If you're unsure of these options, don't enable them now. For now, madshi only wants feedback on debanding (http://forum.doom9.org/showthread.php?p=1721944#post1721944). So if you want to test something, test only what he said in his post. You'll do tests on Upscaling refinement later.

[a8213711]

RGBA

red green blue and alpha channel.
it "is" 24 bit or 8 bit per channel.
So can I safely say it doesn't support 10bit simply looking at that image?




Another thing:
since I found some trade-off already enabled on a clean install (right after a format), I wonder how madVR detects which settings to apply (are these restrained only to trade-off?) and how are calculated.

[luk008]

Madvr 0.88.6 is not using the whole render in FSE with D3D11. I'm using 8.1 x64.

[GCRaistlin]

Well, to be honest, I don't think this is a good time to add this feature. The whole refresh rate changing will be rewritten sooner or later and work quite differently to how to works now. It makes more sense to wait until then.
It is surely up to you but I'd be really grateful if you add this feature independently of rewriting the refresh rate changing - its current implementation works OK, and this means that rewriting will be rather "later" than "sooner".

[pirlouy]

@luk008: Answer is 3 posts earlier: known issue :confused:

[aufkrawall]

Shiandow, your new algorithm gives some interesting results.

madVR high:
http://abload.de/thumb/madvrhighqrr8x.png (http://abload.de/image.php?img=madvrhighqrr8x.png)

Shiandow 0.2; 1:
http://abload.de/thumb/0.21shiandow2krxv.png (http://abload.de/image.php?img=0.21shiandow2krxv.png)

Shiandow 0.7; 2:
http://abload.de/thumb/0.72shiandown4plv.png (http://abload.de/image.php?img=0.72shiandown4plv.png)

Shiandow 1.0; 1:
http://abload.de/thumb/1.01shiandow2rqgt.png (http://abload.de/image.php?img=1.01shiandow2rqgt.png)

0.2; 1 vs madVR high:
I'd say madVR high hardly vanishes any detail (Shiandow neither), but it looks much better with the upper blue gradient.

This is still the case with setting Shiandow threshold to 1.0: Upper gradient still looks better with madVR deband high, but now Shiandow's algorithm already reduces quite an amount of detail (e.g. the jacket is less sharp).
However, the blue gradient in the lower half of the image isn't processed well by madVR deband, there Shiandow now looks much better.

Detail loss can be prevented by highering the detail level. But the behavior for the upper image half needs to be improved.
It'd be great if your algorithm could cover it as well as the lower one, then it'd be probably better than madVR's older one.

[huhn]

So can I safely say it doesn't support 10bit simply looking at that image?

this is the desktop bit deep. the windows desktop can't do 10 bit.
so you will learn nothing about this topic in this place. you have to try and see it for your self.

Another thing:
since I found some trade-off already enabled on a clean install (right after a format), I wonder how madVR detects which settings to apply (are these restrained only to trade-off?) and how are calculated.

they are just checked my default the same on any PC.

[aufkrawall]

this is the desktop bit deep. the windows desktop can't do 10 bit.

Are you sure? DWM is always 8 bit, even if e.g. in the CCC 10 bit is selected?

[huhn]

Oh my, thanks for the daily updates and killer features :)

If I check and then uncheck "octuple luma/chroma resolution", I can't uncheck "double chroma resolution" and "quad chroma resolution" anymore, bug?

This said, 8X is complete overkill for 1080p, I still would like to try it coz there used to be a feature in Avisynth where you would massively upscale, process and then downscale at the very last stage. NEDI is so GPU efficient than why not giving it a shot on 360*288@1080p+NEDI/SuperRes :devil:

I guess 8X luma only isn't possible due to the pixel shifts? I'm not too keen on wasting GPU cycles on chroma.


i can't get octuple to work what so ever.

and the pixel shift shouldn't matter at all it's not like you have to shift the picture in the same direction every time.

[huhn]

Are you sure? DWM is always 8 bit, even if e.g. in the CCC 10 bit is selected?

of cause.
you need FSE to get 10 bit.
this may change with windows 10.

[ibius]

Issues with D3D11:
2. After going windowed FS or FSE, render queue is always only 3-5/8, other queues are full, and I get increased CPU usage, e.g. from ~7% to ~30% on my 3,6GHz Intel Core2Duo.
3. Sometimes after seeking/stopping playback video gets stuck in a loop, jumping between few frames.
4. Render times are better compared to D3D9, but present times are way worse, e.g. going from 0.12ms to 0.9x/1.xx ms in windowed mode, in windowed FS or FSE they are even higher (although only chroma is scaled).


This is exactly the effect you would get with "Nvidia control panel 'Max. pre-rendered frames'" set to a fixed low value. So my best guess is that either the GPU uses a different setting for this behind your back, or there are profiles active somehow which set a low value for this, or there's some GPU driver bug, or something.


I never used profiles, and to be sure none were created by an application I double-checked in Nvidia control panel and in NvidiaInspector. Also, I tried two different driver versions besides the one I was on, I uninstalled previous driver and clean-installed new ones each time, didn't help.

So, I tried actually setting 'Max. pre-rendered frames' to a fixed value to see how madVR would behave, I had a choice between 1-4 frames.

With max. 4 pre-rendered frames my render queue was 2-4/8 and now also present queue wouldn't fill up staying at 4-5/8, with still unusually high CPU usage in fullscreen.

With max. 1 pre-rendered frame my render and present queues were both at 1-2/8, but without unusually high CPU usage in FS.

Note: in both tests I only got those queue values after going into FSE, in windowed/FS modes render queue was 3-5/8 and present queue was full.


I also did some tests with flush settings, where I found something interesting.

Note: Before these tests I had them all at 'Dont flush'.

First I set them to defaults: Flush, Flush and wait (sleep), Don't Flush and Don't Flush - nothing changed.

Then after experimenting with each one individually I found out that 'Flush and wait (sleep) after copy to backbuffer' lowers present times back down a little (from ~0.90ms to ~0.22ms), and no more high CPU usage, but render queue still remains at 3-5/8.

Also, setting 'after copy to backbuffer' to 'Flush' or 'Flush and wait (loop)', I get high CPU usage even in windowed mode, without going FS or FSE.


PS: I think issue 3 is fixed with 0.88.6 build, at least I didn't encounter it during my tests today, usually it happend at least once during 1-2 tests when seeking/pausing/stopping the video.

[aufkrawall]

of cause.
you need FSE to get 10 bit.
this may change with windows 10.
What the heck is then the option for bitdepth in the CCC for?

[iSunrise]

When doing tests, one should always re-test with madVR defaults. That would make configuration-based problems a lot faster to catch for madshi.

Also, I wonder since a lot of people are using >350 drivers, whether the newest Quadro ones (348.07) still show the same problems. I always use the newest Quadro release and besides crashes and apparent madVR bugs (which can be ruled out by returning to the last madVR release) they served me very well.

Also, I never once had driver-related crashes with them, not once. Every crashes that I had, clearly were a madVR bug which madshi fixed instantly.

[huhn]

What the heck is then the option for bitdepth in the CCC for?

what is send over HDMI/DP/DVI/otherstuff.
it's not that complicated. you can send 8 10 and 16 bit to a GPU using something like d3d11 FSE.
without d3d11 madVR is "only" outputting 8 bit to the GPU driver and the GPU driver is than outputting that as set in the GPU driver.
10 bit is for specialized software. on windows 7 adobe photo disabled aero to output 10 bit using openGL.
not sure how that works with windows 8 and newer but even windows 7 overlay doesn't care about DWM.

one thing is clear.
to get 10 bit out of madVR you need d3d11 10 bit mode with FSE.

[Dogway]

Isn't that the same thing?

1920x1080p 4:2:0 source.

step 1) 960x540 chroma to 1920x1080 using 'chroma upscaling'. This is the only step 'chroma upscaling' is used for. This converts the 4:2:0 to 4:4:4.
step 2) 1920x1080 chroma to 3840x2160 with NNEDI3 (chroma doubling) or, if not doubled, to the target resolution with 'image upscaling'.

it's not, you are describing a best scenario example.
this is what happens currently with 720p as far as I have been told here:

1280x720p 4:2:0 source.

step 1) 640x360 chroma to 1280x720 using 'chroma upscaling'. This converts source to 4:4:4
step 2) 1280x720 chroma doubling to 2560x1440 using NNEDI3.
step 3) 2560x1440 to target display resolution using chroma upscale/downscale kernel (a question is this one the same as step 1? this was the question I asked in my last post)

As you see this involves 3 resizes for chroma (not counting the resizes the source suffered first from rip)
I think a better approach -2 resizes- would be the next, although I know there might be obvious reasons not to do like this.

step 1) 640x360 chroma doubling to 1280x720 using NNEDI3. This converts source to 4:4:4
step 2) 1280x720 to target display resolution using chroma upscale/downscale kernel

[ibius]

Also, I wonder since a lot of people are using >350 drivers, whether the newest Quadro ones (348.07) still show the same problems. I always use the newest Quadro release and besides crashes and apparent madVR bugs (which can be ruled out by returning to the last madVR release) they served me very well.

Also, I never once had driver-related crashes with them, not once. Every crashes that I had, clearly were a madVR bug which madshi fixed instantly.

Same here, I also never had driver-related crashes. I don't play games so I don't bother with 'Game Ready' drivers, but I did test latest 350.12 to be sure. Before, I was on 340.52 which is one of the most stable drivers for the Fermi family, it also comes recommended from Windows Update on Win8.1, at least for my GTX 550Ti. I also tried 331.82 version, which with 314.22 (supports up to Win8 only) are the other stable drivers, and 331.82 gives me even lower render times (only by ~0.10-20ms) than 340.52.

[huhn]

it's not, you are describing a best scenario example.
this is what happens currently with 720p as far as I have been told here:

1280x720p 4:2:0 source.

step 1) 640x360 chroma to 1280x720 using 'chroma upscaling'. This converts source to 4:4:4
step 2) 1280x720 chroma doubling to 2560x1440 using NNEDI3.
step 3) 2560x1440 to target display resolution using chroma upscale/downscale kernel (a question is this one the same as step 1? this was the question I asked in my last post)

As you see this involves 3 resizes for chroma (not counting the resizes the source suffered first from rip)
I think a better approach -2 resizes- would be the next, although I know there might be obvious reasons not to do like this.

step 1) 640x360 chroma doubling to 1280x720 using NNEDI3. This converts source to 4:4:4
step 2) 1280x720 to target display resolution using chroma upscale/downscale kernel

madVR always converts to RGB first for debanding and other stuff that needs RGB.

so yes there are reasons for this.

[nevcairiel]

it's not, you are describing a best scenario example.
this is what happens currently with 720p as far as I have been told here:

1280x720p 4:2:0 source.

step 1) 640x360 chroma to 1280x720 using 'chroma upscaling'. This converts source to 4:4:4
step 2) 1280x720 chroma doubling to 2560x1440 using NNEDI3.
step 3) 2560x1440 to target display resolution using chroma upscale/downscale kernel (a question is this one the same as step 1? this was the question I asked in my last post)

As you see this involves 3 resizes for chroma (not counting the resizes the source suffered first from rip)
I think a better approach -2 resizes- would be the next, although I know there might be obvious reasons not to do like this.

step 1) 640x360 chroma doubling to 1280x720 using NNEDI3. This converts source to 4:4:4
step 2) 1280x720 to target display resolution using chroma upscale/downscale kernel

"Chroma Upscaling" is only ever performed in the first step, 4:2:0 to 4:4:4. Its not used for anything else. This allows the chroma upscaler to be somewhat specialized, since it always does a flat 2x upscale, and will never do anything else.

All other scale operations that affect chroma are performed using the image up/down scaling algorithms, because scaling is usually performed in RGB (with the exception of NNEDI3, were Luma and Chroma can be split)

.. and the whole process is only a 2 step process, unless you use NNEDI3 and a final scale is required. If you don't want that, then don't enable NNEDI3 chroma doubling!

1) Chroma scaling 4:2:0 -> 4:4:4 using the "chroma upscaling" algorithm (which might be NNEDI3 if you set that, note however that this is not "chroma doubling", but "chroma upscaling"!)
(optional) 2) NNEDI3 chroma doubling
3) Scaling to final output size using image scaling algorithm

If you don't use NNEDI3, then its the two steps that you want, except that it uses different algorithms than you think.
Its important to note that you can also simply select NNEDI3 as a "chroma upscaling" algorithm, if thats something you want.

[aufkrawall]

what is send over HDMI/DP/DVI/otherstuff.

So, if 8 bit are selected in the CCC, it will output a signal with this bitdepth, even though applications in FSE used 10 bit?


not sure how that works with windows 8 and newer but even windows 7 overlay doesn't care about DWM.

Well, this was exactly my question, which remains open. :(


one thing is clear.
to get 10 bit out of madVR you need d3d11 10 bit mode with FSE.
Why? Does madVR D3D11 automatically convert and dither in windowed mode, even if there was true 10 bit desktop output with DWM?

[nevcairiel]

Why? Does madVR D3D11 automatically convert and dither in windowed mode, even if there was true 10 bit desktop output with DWM?

It probably would, but there is no 10-bit desktop output in Windows. Once there is, madshi will probably support that for us.
It may be something MS is secretly working on for Windows 10, as some signs have hinted at that, but nothing is confirmed.

[aufkrawall]

Alright, thanks.

[yok833]

Hello

Is someone could explain me what is the interest to upscale a good 1080p source on a full HD display?
Regarding the sharpening on a good source, in theory, is it then better to apply it before or after the upscaling (or both)?

[Dogway]

"Chroma Upscaling" is only ever performed in the first step, 4:2:0 to 4:4:4. Its not used for anything else. This allows the chroma upscaler to be somewhat specialized, since it always does a flat 2x upscale, and will never do anything else.

All other scale operations that affect chroma are performed using the image up/down scaling algorithms, because scaling is usually performed in RGB (with the exception of NNEDI3, were Luma and Chroma can be split)

yeah, as it is currently exposed the settings layout is very misleading, as if "chroma upscaling" and "image upscaling" were performing the same function, which is clearly not.

I gave in to nnedi3 (general image) doubling when I tested on my TV, so all my discussion is with this option in mind. It really makes a great difference when scaling ratio is very big (> 2x) as it happens when I watch content (films specially) at 720x304 in a 1080p display. NNEDI3 can create some plastic like look so you need to disable all other types of filters specially sharpeners (also on the TV side). For that reason I use spline instead of lanczos after NNEDI3, lanczos strengthens the "bad" NNEDI look. The same reason I don't use NNEDI quadruple.

At this point I'm wondering what is RGB required for (so early in the process chain). This is what forces a format change to YCbCr 4:4:4 (chroma pre-scale), as a preparation to convert to RGB. As I said I'm the type of not using any of the so called image enhancement post filters so I wonder if an image quality boost could be possible when not using any of those. I find no reason not to resize in YCbCr, besides a chroma pre-scale we also save two color format conversion steps RGB->YCbCr->RGB.

edit:

Sounds all good to me?
so far...

[madshi]

If I check and then uncheck "octuple luma/chroma resolution", I can't uncheck "double chroma resolution" and "quad chroma resolution" anymore, bug?
Actually, no. The "octuple" option had nothing to do with that. You can't uncheck "double/quad chroma resolution" if you have NEDI selected because NEDI handles luma+chroma at the same time.

I guess 8X luma only isn't possible due to the pixel shifts?
It is possible. You just got confused due to the above mentioned NEDI vs. NNEDI3 difference.

You see, there was a reason why I had removed the chroma doubling options. Things are simply more confusing with the options as they are now, although everything behaves as intended.

Shiandow, your new algorithm gives some interesting results.

0.2; 1 vs madVR high:
I'd say madVR high hardly vanishes any detail (Shiandow neither), but it looks much better with the upper blue gradient.

This is still the case with setting Shiandow threshold to 1.0: Upper gradient still looks better with madVR deband high, but now Shiandow's algorithm already reduces quite an amount of detail (e.g. the jacket is less sharp).
However, the blue gradient in the lower half of the image isn't processed well by madVR deband, there Shiandow now looks much better.

Detail loss can be prevented by highering the detail level. But the behavior for the upper image half needs to be improved.
It'd be great if your algorithm could cover it as well as the lower one, then it'd be probably better than madVR's older one.
Thanks for your tests! It might be a good idea to test with more than just one image/source, though, just to get a broader perspective on how the different debanding algos react in different circumstances/conditions. E.g. one algo might be better at bright scenes, the other at dark scenes. One might be better with lots of grain in the image, the other with grain-less images etc...

i can't get octuple to work what so ever.
As mentioned in the v0.88.6 release notes, octupling is only performed if you activate one of the "image refinement" options at the same time. If you don't do that, octupling would be a waste of power.

-------

Good news, btw, I've found a bug which caused the D3D11 rendering queue not to fill up in Windows 7. Should hopefully be fixed in the next build.

[mark0077]

madshi, I think it was already reported, it doesn't effect anything but I get exactly 1 presentation glitch after I pause / unpause or seek when using DX11 for presentation (either in FSE or windowed mode). (Nvidia GTX 980 - Windows 8.1 64bit, 32bit mpc-be)

[sneaker_ger]

@aufkrawall
Do you have the trade for quality option "don't analyze gradient angles for debanding" un-ticked?


Personally, I don't like Shiandow better than the "classic" madvr debanding so far. I'm a user of "high" + the trade for quality option disabled and overall it is working good. I don't notice quality loss but sometimes it isn't strong enough. Shiandow matches "high" at about treshold=1.6, detail=3 but I didn't find any scene where it surpasses the classic algo, most of the time they were equally good. On scenes were classic wasn't strong enough I didn't find any Shiandow setting that could do it better. Shiandow is faster, though. (14.4ms vs 13.5ms rendering)
For now my vote would be to keep the more tested/proven classic algo unless Shiandow can be further improved to handle stronger banding.

I used this trailer for testing, it has all kinds of banding, dark, light, static, moving:
https://mega.co.nz/#!cxlGiABA!vxZMlqpY8FX3dt414eQoYnnebXjHFAFB0rtqpwpi6M4

[zveroboy]

madshi
It does not work "Disable desktop composition" @ v.0.88.6
Could you fix this bug?

(Win7x86 GF 560Ti FW 347.88)

[mark0077]

also not sure if this is expected behaviour, but madVR when paused seems to keep rerendering the image, ie I can see the rendering times updating all the time, and cpu usage shows mpc-be is not at 0. I guess this is expected or is the intention that it truly does use 0 when paused?

[pirlouy]

@zveroboy: can't say on Windows 8, but you can use Windows properties of your application (MPC-HC for example): right-click on mpc-hc.exe > Properties > 2nd tab > Disable desktop composition.

[madshi]

I think it was already reported, it doesn't effect anything but I get exactly 1 presentation glitch after I pause / unpause or seek when using DX11 for presentation (either in FSE or windowed mode). (Nvidia GTX 980 - Windows 8.1 64bit, 32bit mpc-be)
Glitches/drops at seeking or pause/play don't matter, never did.

Personally, I don't like Shiandow better than the "classic" madvr debanding so far. I'm a user of "high" + the trade for quality option disabled and overall it is working good. I don't notice quality loss but sometimes it isn't strong enough. Shiandow matches "high" at about treshold=1.6, detail=3 but I didn't find any scene where it surpasses the classic algo, most of the time they were equally good. On scenes were classic wasn't strong enough I didn't find any Shiandow setting that could do it better. Shiandow is faster, though. (14.4ms vs 13.5ms rendering)
For now my vote would be to keep the more tested/proven classic algo unless Shiandow can be further improved to handle stronger banding.

I used this trailer for testing, it has all kinds of banding, dark, light, static, moving:
https://mega.co.nz/#!cxlGiABA!vxZMlqpY8FX3dt414eQoYnnebXjHFAFB0rtqpwpi6M4
Thanks for your feedback - appreciated!

Any more opinions about madVR vs. Shiandow debanding quality anyone?

It does not work "Disable desktop composition" @ v.0.88.6
Could you fix this bug?

(Win7x86 GF 560Ti FW 347.88)
You probably have D3D11 enabled? If you do that, madVR cannot disable desktop composition, because the D3D11 windowed mode used by madVR requires desktop composition to be enabled. Nothing I can do about it, sorry.

also not sure if this is expected behaviour, but madVR when paused seems to keep rerendering the image, ie I can see the rendering times updating all the time, and cpu usage shows mpc-be is not at 0. I guess this is expected or is the intention that it truly does use 0 when paused?
If you enable the debug OSD, then madVR will update it every second or so. If you disable the debug OSD, madVR should not rerender in paused mode, unless the media player asks it to.