madVR - high quality video renderer (GPU assisted)

[huhn]

@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.

i have the compiler issue not the pink issue and that's fixed with that build.

[octal9]

i was having the pink overlay problem with NNEDI3 (windows 7 64/hd 6870) and can confirm the test build has fixed this problem. thanks for the excellent new build!

[Hprd]

http://i.imgur.com/h3JRymY.png


NNEDI3 (applied anywhere) still crashing with this same error on the test version for me, MPC-BE x64 (Nvidia 352, win 8.1 blah blah). EDIT: Test version is only 32 bit?

[TobiMan]

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)

Does not matter for me, works in both cases. Small inconvenience: I have to restart the player software (DVB-Viewer) upon change, didn't need that before...

[huhn]

NNEDI3 (applied anywhere) still crashing with this same error on the test version for me, MPC-BE x64 (Nvidia 352, win 8.1 blah blah).

the test build is 32 bit only

[madshi]

madVR v0.88.10 released

http://madshi.net/madVR.zip

* fixed: some problems when using NNEDI3
* slightly modified "high" debanding preset, once more

[huhn]

madVR v0.88.10 released

http://madshi.net/madVR.zip

* fixed: some problems when using NNEDI3
* slightly modified "high" debanding preset, once more

nnedi3 results in a black screen with this build. 64 bit only. 32 bit works fine now.

update: black screen with chroma and luma nnedi3 scaling and a wired screen with luma only
nedi works fine

[Hprd]

88.10 fixed the nnedi3 issue, playback seems good again.

[MS-DOS]

madVR v0.88.10 released

Pink screen fixed.

[fluffy01]

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 can't get it to use the separate luma/chroma scaling. I tried playing both a UHD and a real 4K (4096 pixels wide) on my 1080p display, but no matter what I do, it is always showing "chroma > something" and "image < something".

I have tried both MPC-HC and MPC-BE (x64 versions only), and have tried both in FSE (10 bit) and windows mode.

Edit: Same problem for both v0.88.9 and v0.88.10

[huhn]

I can't get it to use the separate luma/chroma scaling. I tried playing both a UHD and a real 4K (4096 pixels wide) on my 1080p display, but no matter what I do, it is always showing "chroma > something" and "image < something".

I have tried both MPC-HC and MPC-BE (x64 versions only), and have tried both in FSE (10 bit) and windows mode.

can you make a screen of the OSD ?

[madshi]

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)
Yes, disabling anti-ringing for SoftCubic makes sense. But that would apply to Mitchell-Netravali, too, wouldn't it? Anti-ringing might not hurt Mitchell as much, but it also probably has not much benefit because Mitchell doesn't really ring (much), either. Or what do you think?

Linear light is a difficult problem, because if you upscale images with strong dithering patterns, using linear light is the only way to achieve proper colors. Although I do agree that for normal video playback it should not be used.

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.
Why do you prefer that? What advantage do you see in scaling chroma up, first, and then later down again (together with luma)? The only argument that would make sense to me is if downscaling in R'G'B' would produce better image quality than downscaling in Y'CbCr. Is that the case? I'm not sure, to be honest. If you can find a situation (a test pattern would suffice) where R'G'B' downscaling looks better than Y'CbCr downscaling, then I'd be willing to handle this as you suggest: With a trade quality option. But I rather guess that there's probably no visible difference between downscaling in R'G'B' or downscaling in Y'CbCr.

FWIW, if you enable linear light downscaling, then madVR does still upscale chroma to full luma resolution first. Because that's the only way linear light downscaling is possible, technically.

Nice install.bat!
Thanks! I hope it works for everyone now.

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 :)
Looking forward to the results of your further tests!

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.
Have changed this to 1.4 and 0.12 in v0.88.10 now.

I have better rendering times with your latest version
How much better (roughly)? Which GPU?

nnedi3 results in a black screen with this build. 64 bit only. 32 bit works fine now.
:( Can't reproduce that on my PC, though, neither with NVidia nor AMD (win8.1, GeForce 650).

I can't get it to use the separate luma/chroma scaling. I tried playing both a UHD and a real 4K (4096 pixels wide) on my 1080p display, but no matter what I do, it is always showing "chroma > something" and "image < something".
Do you have linear light downscaling activated? Linear light downscaling is impossible without upscaling chroma to luma resolution first.

[fluffy01]

Do you have linear light downscaling activated? Linear light downscaling is impossible without upscaling chroma to luma resolution first.

Ha! That was it. Thank you :)

I think I activated it for performance reasons. My HTPC is quite old and not very powerful, and with it activated, I was able to use a higher quality scaler, than I was otherwise able to use.

[madshi]

Nah, linear light downscaling costs *more* performance when activated.

[huhn]

:( Can't reproduce that on my PC, though, neither with NVidia nor AMD (win8.1, GeForce 650).

could be a windows 10 only issue.
64 bit version only.

nnedi3 chroma upsacling: -resetting direct3d device failed (8876086c)
image doubling.
luma nnedi3 doubling results in black luma.
luma and chroma doubling in a black screen.

windows 10 10122 nvidia 760 GTX 352.84 mpc hc 64

let's see if someone else reports this.

[madshi]

But you didn't have these problems with v0.88.8?

[fluffy01]

Nah, linear light downscaling costs *more* performance when activated.

Hmm. Ok. It was a long time ago, so I guess I remembered wrong. It has better quality, then?

[huhn]

But you didn't have these problems with v0.88.8?

chroma upscaling is still -resetting direct3d device failed (8876086c)
but doubling works with 0.88.8.
so there is something very fishy in my system or with windows 10.

i come back with this when widnows 10 is released. i guess i'm kind of disqualified for testing now X-). at least on this system. Hmm. Ok. It was a long time ago, so I guess I remembered wrong. It has better quality, then?

that was the idea of it when it was added. but no was use this for upscaling the results wasn't that good...

but feel free to test this your self.

[Shiandow]

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 :)

Glad it's better now. For that previous test picture you might want to try setting "margin" to a high value (like 0.5 or 1.0) that might work better for lower quality sources, it shouldn't be used for high quality sources though.

Shame that the grain is too strong, in theory it should add exactly as much grain as was removed by the banding algorithm (if the original was dithered). Did the grain improve the image at all, or was it just "grainier"?

[huhn]

ok now things getting interesting.

i updated to 0.88.10 again and tried 64 bit first and it was working for both 32 and 64 bit again but don't worry i found a way to break 64 bit again.

after this i installed 0.88.8 again and than back to 0.88.10 again and started 32 bit first this time. now it is broken again for 64 bit.

so i guess it has something to do with the 32 bit version of openCL that is now used.

[ryrynz]

On my HD4000 I get some black screen blinking and frame judder when changing going fullscreen windowed or FSE pretty sure it's been that way since D3D 11 options came out.
For some reason my Jinc, Mitchell & Catmull drop down box options have completely disappeared, there's only a grey box, this is for both luma and chroma upscaling.

[huhn]

On my HD4000 I get some black screen blinking and frame judder when changing going fullscreen windowed or FSE pretty sure it's been that way since D3D 11 options came out.
For some reason my Jinc, Mitchell & Catmull drop down box options have completely disappeared, there's only a grey box. I reset the options but it didn't change anything.

jinc 4 and 8 where removed so the drop down menu is pointless now and mitchell & catmull never got a drop down box.

[6233638]

But that would apply to Mitchell-Netravali, too, wouldn't it? Anti-ringing might not hurt Mitchell as much, but it also probably has not much benefit because Mitchell doesn't really ring (much), either. Or what do you think?I don't remember it causing problems for Mitchell-Netravali.
Though it is a low-ringing algorithm, there is still some ringing which persists that AR took care of.

Mitchell-Netravali (http://abload.de/img/mn7rqtx.png)
Mitchell-Netravali AR (http://abload.de/img/mn-arbyo3q.png)

SoftCubic is where it was really detrimental though.

Linear light is a difficult problem, because if you upscale images with strong dithering patterns, using linear light is the only way to achieve proper colors. Although I do agree that for normal video playback it should not be used.True. Some kind of warning against using it for upscaling video might be a good idea.

Why do you prefer that? What advantage do you see in scaling chroma up, first, and then later down again (together with luma)?Because the goal of chroma scaling is to try and have the chroma image match the luma image as much as possible so that it does not bleed out the lines etc.
If you always scale it up 2x to match the luma resolution, and then scale that resulting image as one, then your chroma scaling results will always be the same.

If you scale chroma to an arbitrary resolution, rather than matching it to the luma resolution first, the results will vary depending on your source resolution (I suppose that could be handled via presets now) and output resolution.

FWIW, if you enable linear light downscaling, then madVR does still upscale chroma to full luma resolution first. Because that's the only way linear light downscaling is possible, technically.Well I do use linear light downscaling, so perhaps that could be the "quality override" for this rather than having a separate preference, since the main reason to disable it when downscaling is for performance reasons.

If this change only affects chroma when the image is displayed at something less than 100%, and using linear light scaling overrides it, I have no problem with that.

In theory, if I'm watching 4K with linear light scaling disabled, would that mean the chroma image is basically being displayed unscaled?

[ryrynz]

jinc 4 and 8 where removed so the drop down menu is pointless now and mitchell & catmull never got a drop down box.

That's right... just seemed odd at the time, think I've gotten used to seeing options in MPDN for those.. anyway.
Probably should've re-read the Jinc removal change I thought it was just 8.. but 4 too? =/ Was nothing wrong with 4 IMO.

Madshi are the scaling options in madVR displayed in that particular order for a reason? Front page needs updating for 88.10

[Asmodian]

Thanks for the update madshi! New performance tweaks now, getting closer to the fabled 1.0. :D

I do appreciate you removing the bad scaling options, they did seem to be getting used a lot. What setting others use shouldn't bother me but it did. :o

I also like the idea of disabling AR when it shouldn't be used.

madVR v0.88.9 released4K 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.

Would you be willing to define "relatively large factor"? It is easier to explain with a precise cutoff point. :)

[avinab]

could be a windows 10 only issue.
64 bit version only.

nnedi3 chroma upsacling: -resetting direct3d device failed (8876086c)
image doubling.
luma nnedi3 doubling results in black luma.
luma and chroma doubling in a black screen.

windows 10 10122 nvidia 760 GTX 352.84 mpc hc 64

let's see if someone else reports this.

same thing is happening in mine.madvr is crasing(latest version and also previous version).my gpu is gtx 980 and driver version is 352.84

[baii]

.88.10
AMD win10 with win8.1 driver, everything works, NNEDI3 etc

and the performance gain is real. :thanks:

For superres and lumasharpen, are we expecting to have low-mid-high option?

[webs0r]

I have an AMD 5850 GPU.
Depending on the source video/profile chosen I am getting a 0.5 to 2ms improvement in rendering times with v88.10 (vs. v88.8).
I have now gotten some headroom to upgrade my high fps profiles to use better scaling algos.

Thanks madshi!

[ryrynz]

I have an AMD 5850 GPU.
Depending on the source video/profile chosen I am getting a 0.5 to 2ms improvement in rendering times with v88.10 (vs. v88.8).


What is your GPU usage like in comparison though?

[Anime Viewer]

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 encountered that error when I didn't copy over the developers and legal stuff folders. Did you not extract/copy those folders? If not copy them over, and see if it works afterward. Do you only encounter it when expanding to full screen?

[huhn]

I encountered that error when I didn't copy over the developers and legal stuff folders. Did you not extract/copy those folders? If not copy them over, and see if it works afterward. Do you only encounter it when expanding to full screen?

have you tried 088.10 that was build to fix this issue?

[Anime Viewer]

have you tried 088.10 that was build to fix this issue?

That was the build I encountered the issue with, but as I wrote (you may have misinterpreted it) I encountered the problem because I hadn't extracted/copied those folders over into my madVR directory. Once I did (copy those folders over) the problem was solved. I made my post asking if the other people who have reported the error had also not copied the folders over, and recommending they do so if they hadn't already.

[huhn]

i see and i didn't see anyone reporting this with 0.88.10 yet that's why i didn't think about it.

only one person with 0.88.9test was reporting it but with the x64 version that was still 0.88.9 not the test version.

interesting is that you get the same issue with the "older" version of theses folders.

0.88.9test was only the 32 bit madVR.ax nothing else and that should fixed the issue.

[webs0r]

What is your GPU usage like in comparison though?

Looks like 2-3% difference - on a 720p 60fps test file, I get 43% load with v0.88.8 vs 40-41% with v0.88.10.

[shaolin95]

I am confused with my test today! :/
So I installed the latest Nvidia Driver which has the Color Depth option but I am only getting 8bcp option. So does that mean my BenQ only can do 8bco not 10?
My confusion is because when I was doing the 10bit test with madvr, when I disabled dithering and set the output to 8 bit, I can clearly see the "bands" on the ramp but when I change it to 10 bit, the ramp becomes very smooth so is it madvr applying some dithering even when disabled or the video card or something else? Or is it possible my display does handle 10 bit.
I am trying to figure out why is my output with madvr at 10bit clearly better.

[Asmodian]

I think I found a bug in the new independent chroma scaling mode. If I enable SuperRes for chroma when chroma is only upscaled to the target resolution and luma is downscaled I get pink & green video.

edit: Interestingly this still happens when scaling below the chroma resolution. Tested with Catmull-Rom+AR downscaling, Mitchell-Netravali or Jinc+AR chroma upscaling. Win 8.1 x64, Nvidia 352.86, madVR v0.88.10, GK110.

Would you be willing to define "relatively large factor"? It is easier to explain with a precise cutoff point. :)

Never mind, it was too easy to test. ;)
It looks like chroma is only upscaled to the target resolution if downscaling to below 65% when chroma upscaling is set to anything but Jinc or NNEDI3. When set to Jinc or NNEDI3 the threashold is 85%.

[Orf]

I've tried, and I see some DXGI messages, but no complaints from D3D11. Do I need to do something specific to make these appear?
If device creation with debug flag is ok, then debug layer is present. But this checking is done by debug runtime at point when entire process terminate (player process in my case). So you need to check debug output after player process terminates under debugger. Another option is to use DebugView utility (never try it myself). And this messages is useless in terms to help you find what is not released exactly, they only indicate the fact that it happens, so most simple way is the same old method to double check code in place where your release D3D11 stuff (textures, render target views etc), may be you just forget to release something

[Zachs]

I think I found a bug in the new independent chroma scaling mode. If I enable SuperRes for chroma when chroma is only upscaled to the target resolution and luma is downscaled I get pink & green video.

I don't think that's a valid usage of SuperChromaRes - FWIW MPDN prevents this from happening by applying SuperChromaRes before scaling the whole image down to target size. I'd imagine it's a madVR bug.

[James Freeman]

DEBANDING

I find that High is much too aggressive and removes the overall shape of the banded "thing" (ahem...); in a word, it blends too much.
Shiandows keeps the overall shape better and does this in a less destructive way (0.50, 0.0, grain off).
I find the default settings of shiandows are somewhere between Mid and High.
Comparing Mid to Shiandows (0.5) looks much closer one to the another. When on 0.8, it is comparable to High.

Basically what I'm (everybody else?) doing here is trying to match the two algo's to one another... I think it is pointless.
In the end they are practically the same if set correctly.

[Anima123]

With the latest 0.88.10, weird things happened. When using NEDI + SuperRes for upscaling to playing back 765p videos, the screen suddenly became brighter and dropped frames pop up. I started the video again by quitting and restart mpc-hc64, and finished the rest video.

After quitting player and a few minutes later, the screen recovered to the original.

I guess there's something odd with Optimus system, the gig I am using is nVidia 880M + HD 4600 Optimus.

[Xaurus]

I get the compiler error with the latest 88.10, Win 7 x64 running 32-bit madvr. Nvidia drivers 350.12.

[madshi]

ok now things getting interesting.

i updated to 0.88.10 again and tried 64 bit first and it was working for both 32 and 64 bit again but don't worry i found a way to break 64 bit again.

after this i installed 0.88.8 again and than back to 0.88.10 again and started 32 bit first this time. now it is broken again for 64 bit.

so i guess it has something to do with the 32 bit version of openCL that is now used.
And what happens if you go back to v0.88.8 and test that with the 32bit madVR first? I suppose probably you'll get a black screen then, too?

On my HD4000 I get some black screen blinking and frame judder when changing going fullscreen windowed or FSE pretty sure it's been that way since D3D 11 options came out.
I think that's a bug in the Intel GPU driver. Doesn't happen with AMD or NVidia. However, it doesn't happen on my HD4000, either. So it's hard for me to work on this. I'll get a newer laptop with Intel GPU later this year, though, then I can investigate this in depth.

I don't remember it causing problems for Mitchell-Netravali.
Though it is a low-ringing algorithm, there is still some ringing which persists that AR took care of.
Ah, thanks. So I'll keep it for Mitchell.

Because the goal of chroma scaling is to try and have the chroma image match the luma image as much as possible so that it does not bleed out the lines etc.
If you always scale it up 2x to match the luma resolution, and then scale that resulting image as one, then your chroma scaling results will always be the same.
There's nothing in madVR that tries to match the chroma channel to the luma channel atm, except if you use SuperRes for chroma. So I see no quality benefit to be had by scaling chroma to luma resolution first. Except if downscaling in R'G'B' produces better results than downscaling in Y'CbCr, which I'm not 100% sure about.

But please do try to find a difference via screenshots! You can use v0.88.8 and v0.88.10 to compare. If you can find a quality difference in a screenshot, I'll definitely adjust my code accordingly. (Please don't test with exactly 50% right now, though, see below).

If you scale chroma to an arbitrary resolution, rather than matching it to the luma resolution first, the results will vary depending on your source resolution (I suppose that could be handled via presets now) and output resolution.
I'm not sure I agree. Can you show a difference in screenshots?

In theory, if I'm watching 4K with linear light scaling disabled, would that mean the chroma image is basically being displayed unscaled?
An exact 50% downscale is a special case. Currently in that situation I'm just shifting the chroma channel by 0.5 pixel by using bilinear interpolation. I've on my to do list to revisit this special case, probably I'll shift the image by using the selected chroma upscaling algorithm instead, or something like that.

That's right... just seemed odd at the time, think I've gotten used to seeing options in MPDN for those.. anyway.
Probably should've re-read the Jinc removal change I thought it was just 8.. but 4 too? =/ Was nothing wrong with 4 IMO.
There was no real quality advantage using Jinc4. It didn't have much stronger ringing, but it also wasn't really noticeably sharper or less aliased. Basically Jinc4 looks almost identical to Jinc3, while being noticeably slower. That's why I removed Jinc4. Makes no sense to waste performance on Jinc4 if it looks (virtually) identical to Jinc3.

If you have a different opinion, please show me a screenshot comparison where Jinc4 looks noticeably better than Jinc3, and I'll add Jinc4 back in immediately. If it's just a minor improvement in sharpness, though, maybe using LumaSharpen with very low values would get an even bigger quality improvement with less performance loss?

Madshi are the scaling options in madVR displayed in that particular order for a reason?
The algos are sorted for performance. Up: Fast. Down: Slow. And those that perform the same are sorted for logic. E.g. Catmull-Rom is the same as Bicubic50, IIRC, so they are next to each other. And SoftCubic and Bicubic are closely related, so they're next to each other.

For superres and lumasharpen, are we expecting to have low-mid-high option?
Yes, definitely. But we'll need to do some serious testing first to find proper presets for low/mid/high.

Looks like 2-3% difference - on a 720p 60fps test file, I get 43% load with v0.88.8 vs 40-41% with v0.88.10.
So performance has improved by roughly 6% for you. Not dramatic, but better than nothing...

I am trying to figure out why is my output with madvr at 10bit clearly better.
Might be that your driver is dithering. I don't know.

@huhn, at some point you said you knew registry tweaks to force the driver to not dither, didn't you? Can you write up a small summary on those registry keys? Do you know that only for NVidia or also for AMD and Intel? Thanks!

I think I found a bug in the new independent chroma scaling mode. If I enable SuperRes for chroma when chroma is only upscaled to the target resolution and luma is downscaled I get pink & green video.

edit: Interestingly this still happens when scaling below the chroma resolution. Tested with Catmull-Rom+AR downscaling, Mitchell-Netravali or Jinc+AR chroma upscaling. Win 8.1 x64, Nvidia 352.86, madVR v0.88.10, GK110.
Ah yes, will have to look at that. When downscaling below chroma resolution, SuperRes should be disabled for chroma. When chroma is upscaled, SuperRes is supposed to still work.

If device creation with debug flag is ok, then debug layer is present. But this checking is done by debug runtime at point when entire process terminate (player process in my case). So you need to check debug output after player process terminates under debugger. Another option is to use DebugView utility (never try it myself). And this messages is useless in terms to help you find what is not released exactly, they only indicate the fact that it happens, so most simple way is the same old method to double check code in place where your release D3D11 stuff (textures, render target views etc), may be you just forget to release something
I had tried to stop the media player and I had tried both the MSVC++ debugger debug log and also DebugView, but got no complaints. But now I've double checked the code and there really was something I forgot to release. I've no idea why the debug stuff doesn't seem to work on my PC. Anyway, thanks for your report, the problem should be fixed in the next build.

I don't think that's a valid usage of SuperChromaRes - FWIW MPDN prevents this from happening by applying SuperChromaRes before scaling the whole image down to target size. I'd imagine it's a madVR bug.
Applying SuperChromaRes if the downscaling factor is so large that even the chroma channel is downscaled makes no sense, of course. However, if luma is downscaled, but chroma is upscaled, SuperChromaRes should still work ok, I think. In any case, both situations seem to be buggy in madVR right now, will fix that for the next build.

I find that High is much too aggressive and removes the overall shape of the banded "thing" (ahem...); in a word, it blends too much.
Shiandows keeps the overall shape better and does this in a less destructive way (0.50, 0.0, grain off).
I find the default settings of shiandows are somewhere between Mid and High.
Comparing Mid to Shiandows (0.5) looks much closer one to the another. When on 0.8, it is comparable to High.

Basically what I'm (everybody else?) doing here is trying to match the two algo's to one another... I think it is pointless.
In the end they are practically the same if set correctly.
Ok, thanks.

[madshi]

With the latest 0.88.10, weird things happened. When using NEDI + SuperRes for upscaling to playing back 765p videos, the screen suddenly became brighter and dropped frames pop up. I started the video again by quitting and restart mpc-hc64, and finished the rest video.

After quitting player and a few minutes later, the screen recovered to the original.

I guess there's something odd with Optimus system, the gig I am using is nVidia 880M + HD 4600 Optimus.
Strange. Can you reproduce that reliably by following certain steps?

I get the compiler error with the latest 88.10, Win 7 x64 running 32-bit madvr. Nvidia drivers 350.12.
Can I see a screenshot of the complaint, please?

[Ver Greeneyes]

It looks like chroma is only upscaled to the target resolution if downscaling to below 65% when chroma upscaling is set to anything but Jinc or NNEDI3. When set to Jinc or NNEDI3 the threshold is 85%.I'm having kind of a hard time parsing your sentence :) So say you're downscaling 1080p to 720p, a factor of 66.67%, not using Jinc or NNEDI3, would the new path kick in? What about with Jinc/NNEDI3?

[michkrol]

Thanks for the new version.
Image doubling is working again on my Geforce 750Ti (I had compiler errors with v0.88.9).
No bugs in v0.88.10 for me in my (somewhat limited) testing :)

[ryrynz]

If you have a different opinion, please show me a screenshot comparison where Jinc4 looks noticeably better than Jinc3, and I'll add Jinc4 back in immediately.


After taking another look, yeah fair call. Jinc 4 taps can look worse than 3 and at best offer a very minor difference. 8 taps offers more but the cost is very high, both do worse with low res content than 3 taps surprisingly.

[Orf]

I've no idea why the debug stuff doesn't seem to work on my PC
Just a guess. It comes with MS Win SDK. Mine is 8.1 version. Maybe yours is older and not have that feature ?

[SecurityBunny]

Ran into a bug with v0.88.10.

When using D3D11 for presentation with present a frame for every VSync, rendering queues idle at very low numbers.

decoder queue: 22-25 / 24
subtitle queue: 21-24 / 24
upload queue: 17-20 / 20
render queue: 1-5 / 20
present queue: 1-9 / 15
Average rendering time ~9ms.

Unchecking Direct3D 11 for presentation and restarting MPC-HC, going fullscreen all queues are stable.

decoder queue: 23-24 / 24
subtitle queue: 23-24 / 24
upload queue: 19-20 / 20
render queue: 19-20 / 20
present queue: 15-16 / 16
Average rendering time ~18ms.

10 bit bitdepth set
deband high/high
Chroma Upscaling: Jinc AR
Image Upscaling: Jinc AR
Image Downscaling: Catmull-Rom AR/LL
fullscreen exclusive mode
CPU queue size: 24
GPU queue size: 20
frames in advance: 16
smooth motion: only if
ordered dithering
No trade quality options checked.

Windows 10 build 10122
Nvidia 350.12
madVR 0.8.8.10
MPC-HC 1.7.8.230
XySubFilter 3.1.0.741

[madshi]

I'm having kind of a hard time parsing your sentence :) So say you're downscaling 1080p to 720p, a factor of 66.67%, not using Jinc or NNEDI3, would the new path kick in? What about with Jinc/NNEDI3?
The factor depends on the chroma upscaling algorithm. You can test it out yourself by playing a video and then zooming down step by step until the madVR OSD changes from "image <" to "luma <".

After taking another look, yeah fair call. Jinc 4 taps can look worse than 3 and at best offer a very minor difference. 8 taps offers more but the cost is very high, both do worse with low res content than 3 taps surprisingly.
Good to hear we agree.

Just a guess. It comes with MS Win SDK. Mine is 8.1 version. Maybe yours is older and not have that feature ?
The D3D11 documentation says that if the proper SDK is not installed, device creation with the DEBUG flag fails. But it succeeds for me. So according to the doc that should mean that I have the proper SDK installed. Anyway, I think I found the bug.

Ran into a bug with v0.88.10.

When using D3D11 for presentation with present a frame for every VSync, rendering queues idle at very low numbers.

decoder queue: 22-25 / 24
subtitle queue: 21-24 / 24
upload queue: 17-20 / 20
render queue: 1-5 / 20
present queue: 1-9 / 15
Average rendering time ~9ms.

Unchecking Direct3D 11 for presentation and restarting MPC-HC, going fullscreen all queues are stable.

decoder queue: 23-24 / 24
subtitle queue: 23-24 / 24
upload queue: 19-20 / 20
render queue: 19-20 / 20
present queue: 15-16 / 16
Average rendering time ~18ms.

10 bit bitdepth set
deband high/high
Chroma Upscaling: Jinc AR
Image Upscaling: Jinc AR
Image Downscaling: Catmull-Rom AR/LL
fullscreen exclusive mode
CPU queue size: 24
GPU queue size: 20
frames in advance: 16
smooth motion: only if
ordered dithering
No trade quality options checked.

Windows 10 build 10122
Nvidia 350.12
I think this only occurs with 10bit and only on some NVidia drivers. From what other users wrote, you can avoid this problem by reducing the number of prepresented frames to 8 (or maybe 10).

[SecurityBunny]

I think this only occurs with 10bit and only on some NVidia drivers. From what other users wrote, you can avoid this problem by reducing the number of prepresented frames to 8 (or maybe 10).

That seems to be it, thanks. Changing the bit-depth to 8 bit fixed the rendering queues. Alternatively, reducing the prepresented frames to 6 allowed the queues to fill again (8+ didn't work). Hopefully won't be an issue in the later geforce drivers.

Two quick questions.

I don't suppose it is possible to have 10 bit output with windowed mode? To my eyes, fullscreen windowed mode seems to be smoother for video playback and is more responsive.

Is there any significant benefit to higher cpu/gpu queues and presenting more video frames in advance over something small like 4/4/4?