madVR - high quality video renderer (GPU assisted)

[Braum]

I was using upscaling refinement, but with the other option checked to do it only once. If I disable refinement, the double upscaling is gone.

It's using the right profile. NNEDI3 never worked on my computer, no matter the driver version, no matter if I reinstall Windows.

However... Jinc4 and Lanczos8 were removed, probably because NNEDI3 is a better alternative. But since I don't have NNEDI3, there are cases where Jinc4 and Lanczos8 serve me, so for now I'm better to stick to the old version.

I don't think it matters because your rig isn't powerfull enough to upscale with NNEDI.

I got a i5 3570@4,5Ghz and a 7870XT and to upscale 1280x720 to 1680x998 I can't use Double NNEDI 16x.

I can use NEDI in double and quadruple tough.

[huhn]

the file in question is 280p that pretty easy to double at least.

[rack04]

What aspects of a video card are important for madVR performance? I currently have a GTX 680 and get frame drops with NNEDI3, 64 neurons when upscaling 720p to 1440p. I'm considering upgrading to a GTX 970.

[aufkrawall]

This should work, I used it myself that way. With OpenCL 1.2 driver, performance is even said to be improved.
I'd not buy a Radeon for NNEDI3 because AMD hasn't fixed OpenCL -> D3D interop bug for ages now.

However, now with SuperRes, you can also achieve very good results without NNEDI3, as long as you aren't watching cartoons.

If you want to play games with the card, I'd wait for AMD's Fiji release which should make the 980 less expensive. VRAM of 970 is crippled in an odd way.

[nevcairiel]

VRAM of 970 is crippled in an odd way.

That is of no consequence for video. In fact, its of very little consequence in general.

[petran79]

Finally! Nvidia GTX660 Vsync issue on Windows XP has been solved with latest Madshi and Nvidia drivers 347.88
After almost 2 years wait!

After every Nvidia driver update on Windows XP and every new madshi release I tested videos but had the same issue:

June 2013:
http://forum.doom9.org/showpost.php?p=1631301&postcount=18951

Originally Posted by petran79
for a few seconds or even for 1 minute, at that said scene "display" goes at 0000000 Hz instead of 59

Madshi:
Oh, that. Yeah, sounds like a GPU driver issue. madVR highly depends on being able to get up-to-date vsync information all the time. If the display goes to 0000000 Hz that means that the GPU driver isn't reliably providing vsync information. There's probably not much I can do about it, sadly...


This time Vsync seems to be stable at 60 hz at full screen (no exclusive mode), sometimes 61.

In windowed mode it fluctuates from 52-55 hz before stabilizing at 59-60, but never at 0 hz, thus not dropping frames

I can finally watch movies in good quality and without tearing on Windows XP like 3 years ago. Windows 7 is too sluggish.

[aufkrawall]

That is of no consequence for video. In fact, its of very little consequence in general.
I was explicitly referring to games, and consequences can be enormous (I tested this myself).
But not for video, sure. GTX 970 is a very reasonable card for madVR, probably the best (if you don't need native HEVC decoding).

[MysteryX]

I don't think it matters because your rig isn't powerfull enough to upscale with NNEDI.

I got a i5 3570@4,5Ghz and a 7870XT and to upscale 1280x720 to 1680x998 I can't use Double NNEDI 16x.

I can use NEDI in double and quadruple tough.

I won't use NNEDI3 for 720p videos, but will definitely for 288p videos! Then I'd have to test whether it would also work on 480p content.

I'm curious. Why were Jinc4, Jinc8 and Lanczos8 deemed "bad" algorithms?


Btw, kind of off-topic, but yesterday I realized that in a video game (with latest Catalyst driver), performance was *higher* when using full-screen windowed mode than when in exclusive mode! Not sure why. I tried that in madVR. There doesn't seem to be any performance difference between windowed mode and exclusive mode; but switching into full screen is much faster.

[Thunderbolt8]

is anyone able to tell if windows 10 has positive or negative impact on madvr (nvidia (mobile)) performance?

[iSunrise]

is anyone able to tell if windows 10 has positive or negative impact on madvr (nvidia (mobile)) performance?
Personally, I would not risk it just yet, at least wait for RTM. For desktops Win10 might be ok already, but mobiles have their own weird problems, even on an already stable and feature-complete OS.

[huhn]

i have issue on windows 10 and i will report issue with the RTM version which will be available soon.

[RainyDog]

You are using Catmull-Rom for downscaling, right? With other algorithms, linear light might not look correct, its only really recommended for CR.

I've always used Spline3 for downscaling as I prefer the slightly sharper look to CR.

So I shouldn't be downscaling in linear light if using Spline?

[aufkrawall]

imho one shouldn't use it at all. There's a reason why usually gamma corrected is considered as the desired result (or better said: gamma correction gives the desired result in the end).
I just played some desktop capture videos and fonts look totally awful with linear light downscaling.

[6233638]

imho one shouldn't use it at all. There's a reason why usually gamma corrected is considered as the desired result (or better said: gamma correction gives the desired result in the end).
I just played some desktop capture videos and fonts look totally awful with linear light downscaling.I really don't think that looking at computer graphics is a good test for downscaling.
You should be using photographs or movies.
Something that was filmed instead of rendered.

With that, linear light downscaling should be better - at least if your display is properly calibrated.

http://forum.doom9.org/showpost.php?p=1675410&postcount=25427 (note: this is a macro image of a fly)
View the comparison images here at 100% in your browser and switch tabs.

The image scaled in linear light should look very close to the source, only lower resolution.
The image without linear light scaling is quite a bit darker than the source image, and finer details are lost.

I've always used Spline3 for downscaling as I prefer the slightly sharper look to CR.
So I shouldn't be downscaling in linear light if using Spline?Catmull-Rom with the anti-ringing filter enabled is the only option which does not result in ugly ringing or aliasing artifacts when linear light scaling is enabled.
I don't recommend enabling the linear light scaling option with anything else.
An old example comparing Catmull-Rom and Lanczos. (http://www.abload.de/img/catrometjna.gif)

[aufkrawall]

I really don't think that looking at computer graphics is a good test for downscaling.
You should be using photographs or movies.
Something that was filmed instead of rendered.

I did with that grass picture:
http://upload.wikimedia.org/wikipedia/commons/d/dc/Hermosa_beach_chip_trail.jpg


http://forum.doom9.org/showpost.php?p=1675410&postcount=25427 (note: this is a macro image of a fly)
View the comparison images here at 100% in your browser and switch tabs.

The image scaled in linear light should look very close to the source, only lower resolution.
The image without linear light scaling is quite a bit darker than the source image, and finer details are lost.

What is the point of this nearest neighbor upscaling?
It introduces tons of aliasing.
It would be better if the source's resolution would be high enough to have a realistic result in a common native resolution.

[cyberscott]

The first log makes sense, but the 2nd doesn't. The 2nd log indicates that it wasn't from the build 2 I intended you to test. Either I uploaded the wrong file, or you tested with the wrong file. To be safe, I've uploaded the 2nd build again:

http://madshi.net/madVR8810test4.rar

Could you please test this build again? Thanks!
It is very possible I messed the 2nd one up, was short on time and tried to do it quick. :(
I ran test 4 and same behavior with the queues. Here is the log.
http://s000.tinyupload.com/?file_id=00499522210065716807

[6233638]

What is the point of this nearest neighbor upscaling?
It introduces tons of aliasing.
It would be better if the source's resolution would be high enough to have a realistic result in a common native resolution.To keep the image the same size so that you can tab through all of them in your browser and make an accurate comparison.
Though fine details are better preserved by using linear light scaling, it is the overall brightness/appearance of the image which is important.

Linear light scaling preserves the "silvery" appearance of the eyes, while scaling without that option shifts the tone more towards brown.
If you wear glasses, you may even want to take them off when comparing the three if you find the aliasing distracting. Resolution should not be a factor in this comparison.

And please ensure that the images are not being scaled at all, they must be displayed at 100% size.

[baii]

In general, is there a consent on using higher needi3 neurons vs using SuperRes/ more pass SuperRes?

I have some 480p DVD that is like 0.5% of the content I watch, but I really like those~. My eye test seem to favor more neuron(32->64) compare than more pass, or even activating SR, but then there is the pixel shift which make the comparison kind of weird/hard ?

[huhn]

in my test more passes with SR is very harmful to the picture unlike nnedi3 with more neurons so hard to compare.

[Anima123]

The effect of SuperRes with madVR is not exactly the same as the one with MPDN for some reason, I don't know why.

I'd prefer the MPDN version, quality speaking. Maybe madshi have some idea to tweak the SuperRes a little bit, or there's some kind of bug when SuperRes and NEDI were included within madVR?

[madshi]

I meant P8 state, sorry.
madshi did something to fix NNEDI3 quadrupling in the past with image enhancement because there was a similar issue.
I suppose it's still related to NNEDI3 quadrupling + image enhancement.
Driver gets totally stuck in P8 state, thus it drops lots of frames if it's too slow. It's not able anymore to enter a higher P-state unless the driver is restarted.
I had fixed a bug, but that had nothing to do with power states. I have zero influence on which power states the GPU switches to.

Thanks a lot. Its very easy with that example indeed so I got a good idea now of how they behave. With Blurays though telling the difference is another story. :D
Differences are hard to see in most scenes. However, there are some scenes in which differences can be visible. It's usually when there's lots of red and black.

Hi madshi, found a bug with mVR 88.10 that is not occurring with 88.7. Whenever I try to play the attached link two AVC clips Zoom Player immediately crashes when I use either LAV or ffdshow as the AVC video decoder, whether software decoding, CUDA or Quicksync is selected. I duplicated the problem using PotPlayer and setting the same external AVC decoders as the video decoder. Oddly when I select PotPlayer's AVC built-in decoder the clips don't crash so perhaps that may help with figuring out what is wrong. Like I mentioned, this is new prob, the clips play fine with mVR 88.7. Please let me know what other info I can provide.
I think this will probably be fixed in the next build.

I have some more info for those of us having issues with D3D11 and PotPlayer.

I use a 72 Hz refresh rate for 23.976 playback (with ReClock) and a 60 Hz refresh rate for 29.970/59.940.... PotPlayer's onscreen info (TAB) will show 23.976-->72 (actually starts a little above 72, then falls to 72 and stays there). When the video is paused (or something else pulls focus away) there is a flicker (like going out of FSE) however ctrl-J still says FSE... and now the OSD of PP will show 23.976-->70 (and the 70 keeps falling until it hits 24)... ctrl-J shows empty queues (with no dropped frames, oddly enough) and playback gets super jittery. I have been racking my brains trying to find a way for this to work, but no setting in PP, ReClock or madVR allows me to pause the video and resume without this very very odd behavior. Playback is awesome as long as nothing interrupts it, but many times a video can be paused (can't miss anything for a beer run or to take a leak!!) and having to stop and restart each time is not an option. So I keep going back to D3D9.

To me, it seems that once the stream is interrupted, the refresh that is being reported gets altered in some way to that of the video and not the target... I just tried without ReClock, and everything I described above happens except the playback seems smooth, even with the last two queues not filling up. It's all very odd
Those PotPlayer frame rate reports don't have a lot of meaning.

Does this problem only occur with PotPlayer? Or also with e.g. MPC-HC? I think there is a setting in PotPlayer which causes madVR to rerender frames all the time in paused state, causing rather high GPU consumption in paused state. I'm not very familiar with PotPlayer, though. If you disable that feature (in case you know which it is), does that make the problem go away?

Could it be that downscaling in linear light can totally shift an image in an unwanted way?
Some time ago, I did some tests with downscaling game sreenshots, and with linear light everything seemed to be getting too bright.
Linear light should produce the "correct" result, unlike gamma light. The reason is that blending pixels together in gamma light is mathematically not correct. And downscaling blends a lot of source pixels together for each target pixel. For upscaling it's a bit different. In theory linear light should produce more correct results for upscaling, too, but it adds so much ringing that the positive benefits are outweighed.

You are using Catmull-Rom for downscaling, right? With other algorithms, linear light might not look correct, its only really recommended for CR.
All 2-tap algos should be fine. However, 3-taps and more produce a lot of ringing when using linear light which the anti-ringing filter doesn't completely erase. Other than the ringing, using 3-taps/4-taps for linear light downscaling is ok, too. It's really only the ringing which is the key problem.

FWIW you can actually prove mathematically that using linear light (with a gamma > 1) will make the image brighter. For more information see Jensen's inequality (https://en.wikipedia.org/wiki/Jensen%27s_inequality).
Hmmmm... Isn't that backwards? I mean don't we have to think of linear light as a straight line, and of gamma light as a curve? Jensen's inequality should prove that *gamma light* produces incorrect results, not linear light. Or am I missing something? You seem to suggest that gamma light is a straight line and that linear light is a curve. But I think it's exactly the other way round? Images/videos are using gamma light because that's how CRTs used to work, and also because it happens to approximate the way our eyes perceptually work. But nature/physics really is linear light, not gamma light.

Is it possible to have an option to use D39 overlay in windowed mode and D311 in exclusive mode?
Possible yes. But too much work.

I know this is the madVR thread but since Shiandow's debanding algorithm is being tested along side madVR's, I hope the thread will forgive me for the following.
In my tinkering with the deband algorithm's this weekend I have confirmed for myself a rather happy alternative use for Shiandow's algorithm set at 1.00 strength and .01 margin with grain. It does an excellent job of deblocking and denoising my old dvr rips at sub 480p resolution without totally killing detail (in tandem with nnedi3) and making it a fuzzy mess. Well more fuzzy than it already was.
This is just my opinion, but I think it would really be beneficial (for me and possibly even a small minority of users) if Shiandow might be able to optimize his debanding algorithm further down that path and possibly madshi could use it as a denoiser/general deblocker for madVR somewhere in the near future.
Deblocking should be handled separately from debanding, IMHO. Why? Because a deblocking algorithm can actually assume that blocks appear at typical distances (e.g. at 8x8 pixel boundaries). This information should allow a deblocking algorithm to work more efficiently than trying to make a debanding algorithm remove block compression artifacts.

That said, yes, maybe Shiandow's debanding algorithm could be used as a starting point for a new deblocking algorithm. But there's no room in my time schedule at least for that anytime soon.

With v0.88.9 and v0.88.10 Average stats > rendering never stabilize, it jumps up and down and i've have frame drops. It applies to Jinc and jumps from 6ms to 22ms. If I choose Bicubic it settles at around 18ms after a few seconds.
In older versions rendering times were averaged "forever". That means you got nicely stable times after a while. *However*, directly after switching algos or changing zoom factors or things like that, rendering times are usually much higher than a couple of seconds later. This means that old way of long-time averaging often started too high and needed a looooong time to settle down to the correct values. The new method averages rendering times over just 1 second of playback. So naturally the rendering times can jump quite a bit. However, if the rendering times over multiple consecutive measurement periods are relatively near to each other, madVR averages them together again. So as long as the jumps are not too large from one measurement second to the next, the times should calm down over time, too, and then get much quicker to the correct end result compared to before.

Finally! Nvidia GTX660 Vsync issue on Windows XP has been solved with latest Madshi and Nvidia drivers 347.88
After almost 2 years wait!
FWIW, I don't think it's the drivers. I've added a number of changes for Optimus systems, and I think those probably have helped with your specific problem, too. The drivers are probably still as buggy as ever, but madVR has added a number of driver workarounds to be more forgiving with bad drivers.

In general, is there a consent on using higher needi3 neurons vs using SuperRes/ more pass SuperRes?

I have some 480p DVD that is like 0.5% of the content I watch, but I really like those~. My eye test seem to favor more neuron(32->64) compare than more pass, or even activating SR, but then there is the pixel shift which make the comparison kind of weird/hard ?
in my test more passes with SR is very harmful to the picture unlike nnedi3 with more neurons so hard to compare.
The effect of SuperRes with madVR is not exactly the same as the one with MPDN for some reason, I don't know why.

I'd prefer the MPDN version, quality speaking. Maybe madshi have some idea to tweak the SuperRes a little bit, or there's some kind of bug when SuperRes and NEDI were included within madVR?
There are small differences in the SuperRes implementation. But you guys are too fast. We're still discussing debanding atm. We'll get to SuperRes soon enough.

I find Shiandows 0.80, 0.0, Grain On; vs High, identical in terms of detail loss and shape retention.

IMO, They are so close, any one of them will do perfectly.
As the old saying goes, if it's working don't touch it.
On debanding:
"Add grain". It adds grain, yes, but it's 10x stronger than madVRs/f3kdb's and I don't really feel it being useful. In some cases it even makes an opposite effect and makes banding more visible.
Overall I still strongly prefer madVR debanding over Shiandow's (on anime sources).
Thank you for your feedback, once again!

Any more votes about debanding?

[madshi]

It is very possible I messed the 2nd one up, was short on time and tried to do it quick. :(
I ran test 4 and same behavior with the queues. Here is the log.
http://s000.tinyupload.com/?file_id=00499522210065716807
Ok, thanks. One more try, if you don't mind:

http://madshi.net/madVR8810test5.rar

Please activate debug mode first (by double clicking "activate debug mode.bat"), then afterwards drop in the new madVR.ax. If you do it the other way round, but you're replacing the "wrong" madVR.ax file and you're testing with the official v0.88.10 again. I know, it's a bit confusing. Basically, after you dropped the replacement madVR.ax file into the madVR folder, don't double click any batch files, until you've completed testing. Thanks!

[Shiandow]

Hmmmm... Isn't that backwards? I mean don't we have to think of linear light as a straight line, and of gamma light as a curve? Jensen's inequality should prove that *gamma light* produces incorrect results, not linear light. Or am I missing something? You seem to suggest that gamma light is a straight line and that linear light is a curve. But I think it's exactly the other way round? Images/videos are using gamma light because that's how CRTs used to work, and also because it happens to approximate the way our eyes perceptually work. But nature/physics really is linear light, not gamma light.


Jensen's inequality doesn't really care about which one is "correct" or "linear". It just uses the fact that the function used to go from gamma light to linear light is convex. If you go the other way around then the function you use is concave, so the inequality will be the other way around. You can really only use it to show that the values will (always) be higher when you use linear light, you can't use it to show whether this is better or not.

[Aleksoid1978]

Hi madshi.
I have question for you. How you(what API function use) change resolution/refresh rate ?? In MPC-BE/MPC-HC use ChangeDisplaySettingsEx(). But - after buy new GTX 960 i have some trouble with 24fps mode - after use ChangeDisplaySettingsEx() my TV info that use 24p, but in MPC-BE EVR Custom i see that fps ~23.976(and it's true). If i try use madVR with auto-refresh - i give "true" 24p mode. You do not know what could be wrong ?? :)

[nevcairiel]

Hi madshi.
I have question for you. How you(what API function use) change resolution/refresh rate ?? In MPC-BE/MPC-HC use ChangeDisplaySettingsEx(). But - after buy new GTX 960 i have some trouble with 24fps mode - after use ChangeDisplaySettingsEx() my TV info that use 24p, but in MPC-BE EVR Custom i see that fps ~23.976(and it's true). If i try use madVR with auto-refresh - i give "true" 24p mode. You do not know what could be wrong ?? :)

Its the same API, but you have to cheat it.
Call ChangeDisplaySettingsEx with the new mode and CDS_UPDATEREGISTRY | CDS_NORESET once, and then a second time without a new mode and without the flags (it'll use the new mode you set in the previous call then)

[Aleksoid1978]

Its the same API, but you have to cheat it.
Call ChangeDisplaySettingsEx with the new mode and CDS_UPDATEREGISTRY | CDS_NORESET once, and then a second time without a new mode and without the flags (it'll use the new mode you set in the previous call then)

It's not necessary. Even call ChangeDisplaySettingsEx() only with CDS_UPDATEREGISTRY or CDS_FULLSCREEN or 0 - it's work. But something wrong with new mode - TV info that 24p, but in fact - 23.976. All other mode working as it should.

[madshi]

Jensen's inequality doesn't really care about which one is "correct" or "linear". It just uses the fact that the function used to go from gamma light to linear light is convex. If you go the other way around then the function you use is concave, so the inequality will be the other way around. You can really only use it to show that the values will (always) be higher when you use linear light, you can't use it to show whether this is better or not.
Ah, I see. The basic question that was discussed earlier in this thread was whether linear or gamma light was "correct". I had thought that you had tried to answer that question. Now I see that your reply didn't mean to judge about which is right (or even better).

It's not necessary. Even call ChangeDisplaySettingsEx() only with CDS_UPDATEREGISTRY or CDS_FULLSCREEN or 0 - it's work. But something wrong with new mode - TV info that 24p, but in fact - 23.976. All other mode working as it should.
nevcairiel has it right. If you use ChangeDisplaySettingsEx() the normal way, it will switch to 23.976, even if you specify 24.000. You have to call ChangeDisplaySettingsEx() twice, in a very specific way (see nevcairiel's post), to get true 24.000.

[Vegeak]

Since the last 2 versions (0.88.9/0.88.10) if I set debanding as high it drops a lot of frames, I'm using 0.88.8 and it plays fine, my graphic card isn't good at all (GT 610), but I can play 720p files fine. This seems to happen since high debanding was modified, can I get a version with all the new changes but without this change specifically?

[sneaker_ger]

New versions enabled gradient analyzing for "high" debanding. Go "rendering"->"trade quality for performance" and tick "don't analyze gradient angles for debanding". Then test again. (I don't know if it really needs much performance. Maybe it's just a coincidence and real problem is something else?)

That said, debanding might change again in the very near future according to the user reports here so this might only be a temporary option.

[Vegeak]

Thank you! This fixed my problem.

[XMonarchY]

Whoever advised that using the High Speed HDMI cable would allow me to get 12bit not only @ 23Hz, but also at 60Hz was dead on right! I just got one of these cables and I can select 60Hz + 12bit in nVidia CP with no artifacts! I hope games will look better now!


BTW, is it a placebo effect that my games (Withcer 3) look better in 12bit mode than in 8bit mode? I know transitions are better, especially since I use a 1D LUT, but colors also seem richer! I tested my calibration done in 8bit with 12bit mode and there was no difference anywhere, and yet 12bit seems to produce richer colors...

[XMonarchY]

Also, I noticed an odd problem. I am getting an occasional stutter during my SMPTE 170M content playback that I have not had before... I can't seem to narrow down which setting causes it. There are no frame drops or glitches or delayed frames for 25-30 minutes and suddenly there is this stutter where the screen shakes for a second and then all is fine for the next 30 minutes. GPU is fine, all is stable. I did update MPC-HC to the latest nightly build, do you think that may be reason?

[Sunset1982]

Also, I noticed an odd problem. I am getting an occasional stutter during my SMPTE 170M content playback that I have not had before... I can't seem to narrow down which setting causes it. There are no frame drops or glitches or delayed frames for 25-30 minutes and suddenly there is this stutter where the screen shakes for a second and then all is fine for the next 30 minutes. GPU is fine, all is stable. I did update MPC-HC to the latest nightly build, do you think that may be reason?

Had this too yesterday...

[huhn]

here is my opinion on debanding.
i used a BD with a on of banding encoded with VC-1 with about 14 mbit combined with bad mastering.

untouched: http://abload.de/img/untouchednwsn8.png
madVR high: http://abload.de/img/madvrhighqesn8.png
shiandow 1.0 0.0: http://abload.de/img/madvrnew1.00.036sp3.png
shiandow 1.0 1.0: http://abload.de/img/madvrnew1.01.0wds61.png

madVR high is stronger in debanding than shiandow 1.0 with margin 0.0 but a little bit more harmful too.
margin 1.0 has a very bad effect on moving scene this effect is still visible with 0.0 margin but not visible with madVR high.

so i give madVR high a clear edge in moving scenes.

here a screen with the problem i call it clouding on the blue car it is way worse in moving.

untouched: http://abload.de/img/untouched2xpuk6.png
shiandow 1.0 1.0: http://abload.de/img/clouding61ucd.png
shiandow 1.0 0.2: http://abload.de/img/clouding1.00.274ukn.png
shiandow 1.0 0.0: http://abload.de/img/clouding1.00.0neuas.png
madVR high: http://abload.de/img/cloudingmadvr5nux5.png

a deblock filter before debanding may help shiandow's algorithm a lot.

[cyberscott]

Ok, thanks. One more try, if you don't mind:

http://madshi.net/madVR8810test5.rar

Please activate debug mode first (by double clicking "activate debug mode.bat"), then afterwards drop in the new madVR.ax. If you do it the other way round, but you're replacing the "wrong" madVR.ax file and you're testing with the official v0.88.10 again. I know, it's a bit confusing. Basically, after you dropped the replacement madVR.ax file into the madVR folder, don't double click any batch files, until you've completed testing. Thanks!

Ok, still change in the queues in this test. Hopefully I got the log correctly generated. Here it is...:
http://s000.tinyupload.com/?file_id=32868104695651332179

[madshi]

Also, I noticed an odd problem. I am getting an occasional stutter during my SMPTE 170M content playback that I have not had before... I can't seem to narrow down which setting causes it. There are no frame drops or glitches or delayed frames for 25-30 minutes and suddenly there is this stutter where the screen shakes for a second and then all is fine for the next 30 minutes. GPU is fine, all is stable. I did update MPC-HC to the latest nightly build, do you think that may be reason?
I've no idea. When this stutter occurs, do you have frame drops or glitches or delayed frames then?

here is my opinion on debanding.
i used a BD with a on of banding encoded with VC-1 with about 14 mbit combined with bad mastering.

untouched: http://abload.de/img/untouchednwsn8.png
madVR high: http://abload.de/img/madvrhighqesn8.png
shiandow 1.0 0.0: http://abload.de/img/madvrnew1.00.036sp3.png
shiandow 1.0 1.0: http://abload.de/img/madvrnew1.01.0wds61.png

madVR high is stronger in debanding than shiandow 1.0 with margin 0.0 but a little bit more harmful too.
margin 1.0 has a very bad effect on moving scene this effect is still visible with 0.0 margin but not visible with madVR high.

so i give madVR high a clear edge in moving scenes.

here a screen with the problem i call it clouding on the blue car it is way worse in moving.

untouched: http://abload.de/img/untouched2xpuk6.png
shiandow 1.0 1.0: http://abload.de/img/clouding61ucd.png
shiandow 1.0 0.2: http://abload.de/img/clouding1.00.274ukn.png
shiandow 1.0 0.0: http://abload.de/img/clouding1.00.0neuas.png
madVR high: http://abload.de/img/cloudingmadvr5nux5.png

a deblock filter before debanding may help shiandow's algorithm a lot.
Good feedback - thank you! :)

Ok, still change in the queues in this test. Hopefully I got the log correctly generated. Here it is...:
http://s000.tinyupload.com/?file_id=32868104695651332179
Ok, I've finally found what causes the queues to not fill:

When madVR tries to copy the rendered frame to the backbuffer, exactly one out of four times it takes ca. 150-200ms. Every other time it takes 0ms (meaning no measurable time).

I've no idea why copying to the backbuffer sometimes is so slow and sometimes so fast, and why it seems to have a certain rhythm. It could either be a bug in the GPU drivers, or it could be a misconfiguration of some sort. You already tried lowering the number of pre-presented frames without success, right? And you already double checked the NVidia GPU control panel to make sure that the number of pre-rendered frames is set to application control, correct? Have you changed the madVR flush settings at some point? Have you tried restoring the madVR default settings at some point, just in case? Are you running some background process which might access the GPU (e.g. GPU-Z, or similar)? Try closing all processes which are not strictly needed, including the browser.

There's one more thing: In the original log I could see that madVR had to reset the VSync Direct3D device sometimes, because Direct3D reported it was "occluded". Which suggests that maybe some window might have covered the media player, at least for a short time. Does that make any sense to you? The test build you've tested with now doesn't reset the VSync device, anymore. I had hoped this would make a difference, but seemingly it doesn't.

[Aleksoid1978]

nevcairiel has it right. If you use ChangeDisplaySettingsEx() the normal way, it will switch to 23.976, even if you specify 24.000. You have to call ChangeDisplaySettingsEx() twice, in a very specific way (see nevcairiel's post), to get true 24.000.

Thanks - i try :)

[cyberscott]

Ok, I've finally found what causes the queues to not fill:

When madVR tries to copy the rendered frame to the backbuffer, exactly one out of four times it takes ca. 150-200ms. Every other time it takes 0ms (meaning no measurable time).

I've no idea why copying to the backbuffer sometimes is so slow and sometimes so fast, and why it seems to have a certain rhythm. It could either be a bug in the GPU drivers, or it could be a misconfiguration of some sort. You already tried lowering the number of pre-presented frames without success, right? And you already double checked the NVidia GPU control panel to make sure that the number of pre-rendered frames is set to application control, correct? Have you changed the madVR flush settings at some point? Have you tried restoring the madVR default settings at some point, just in case? Are you running some background process which might access the GPU (e.g. GPU-Z, or similar)? Try closing all processes which are not strictly needed, including the browser.

There's one more thing: In the original log I could see that madVR had to reset the VSync Direct3D device sometimes, because Direct3D reported it was "occluded". Which suggests that maybe some window might have covered the media player, at least for a short time. Does that make any sense to you? The test build you've tested with now doesn't reset the VSync device, anymore. I had hoped this would make a difference, but seemingly it doesn't.

Glad you were able to isolate the cause, that is a good thing. As far as .88.10, I always started testing at madVR's default settings, only changing the up-scaling to bilinear.
All the flush settings are at default, I never had need to touch them, and If I had, it would be corrected when I reset to default settings.

nVidia's control panel is set globally for "application control" for frames. I had hoped nVidia's new 353.06 drivers might have an effect but it appears to have made no difference.

I don't have gpu-z running nor any type of gpu overclocking/monitoring software running. I have tried closing processes to bare minimum with no changes.

I messed around a little more with the new .ax tonight
One thing I noticed that on the untouched, original .88.10 .ax, changing the exclusive mode present frames in advance didn't change the behavior of the queue, it would stay at 1-4/X until I set it below that. Even then, it would stay 1-4, 1-3, 1-2, etc. The latest madVRtest5.ax, the presented frames will completely fill if set to 4. (4-4/4).

With some more queue adjustments, I currently have all the queues filling up, using .88.10 and MadVRtest5.ax

Decoder queue: 14-15/15
Upload queue: 8-9/9
Render queue: 8-9/9
Present queue: 4/4-4 (lower than I like but the highest setting that works)


Also, remember me mentioning that the Decoder queue (in exclusive mode) would always show one more than it should, such as 14-16/15? When I set the exclusive mode to 4 frames or below, it will show correctly, 14-15/15. Not sure if that has anything to do with this issue, though.

The "occluded" D3D you saw was most like me tinkering with things at one point with the log running and I unintentionally sent you a log with my messing around. Sorry about that. :(

I always can use .88.8 if I want use 10 bit output with higher " presented frames in advance" settings in 10 bit DSD11 mode but of course I couldn't play with the added /changed features in .88.10.

I do appreciate you taking extra time troubleshooting this issue with me even though I'm the only one to have reported it up to now. :thanks:

Here is the log for the full queues if you want to take a look.
http://s000.tinyupload.com/?file_id=48016178447616236926

[Della]

I replied earlier, I too have seen the unfilled queues when using 10 bit exclusive. You're not alone & thanks much for all your investigative work.

[har3inger]

The newest MPC-HC official release for June 1st causes my render and present queues to bounce around zero despite having render times of around 28-30ms for 24p content. Dropped frame count is surprisingly fine, with only a couple frames per minute, but clearly something isn't working as it was before.

Anyone have a link to a copy of 1.7.6.156 I could revert to? That was the tweaked 64 bit build to support 64 bit madvr. The old one on dropbox from weeks/months back is dead.

Hmm, with further testing to isolate the problem, it went away without me doing anything. Go figure.

[MysteryX]

Hey I have a very simple suggestion that would make the usage much simpler.

Why are downscaling algorithms like Catmul in the upscaling pages, and why are upscaling algorithms like Lanczos in the downscaling page?

You could remove downscaling algorithms from the upscaling page and upscaling algorithms from the downscaling page. That would make the interface simpler and make it easier for new users.

Also, someone mentioned that Scale in Linear Light shouldn't be used when downscaling except for Catmul when also using Anti-Ringing. If it's a bad choice for others, it could be removed for other algotirhts.

[ryrynz]

Why are downscaling algorithms like Catmul in the upscaling pages, and why are upscaling algorithms like Lanczos in the downscaling page?

You could remove downscaling algorithms from the upscaling page and upscaling algorithms from the downscaling page. That would make the interface simpler and make it easier for new users.

Also, someone mentioned that Scale in Linear Light shouldn't be used when downscaling except for Catmul when also using Anti-Ringing. If it's a bad choice for others, it could be removed for other algotirhts.

They're algorithms for upscaling and downscaling, nothing needs to be removed. There are common preferences for upscaling and downscaling and sometimes different from each other, that's fine.

With regards to scaling in linear light it's a case of only enabling it if you you need it. Some options may move to advanced section but I suspect this rejigging if it occurs will happen closer to 1.0.

[madshi]

Glad you were able to isolate the cause, that is a good thing. As far as .88.10, I always started testing at madVR's default settings, only changing the up-scaling to bilinear.
All the flush settings are at default, I never had need to touch them, and If I had, it would be corrected when I reset to default settings.

nVidia's control panel is set globally for "application control" for frames. I had hoped nVidia's new 353.06 drivers might have an effect but it appears to have made no difference.

I don't have gpu-z running nor any type of gpu overclocking/monitoring software running. I have tried closing processes to bare minimum with no changes.

I messed around a little more with the new .ax tonight
One thing I noticed that on the untouched, original .88.10 .ax, changing the exclusive mode present frames in advance didn't change the behavior of the queue, it would stay at 1-4/X until I set it below that. Even then, it would stay 1-4, 1-3, 1-2, etc. The latest madVRtest5.ax, the presented frames will completely fill if set to 4. (4-4/4).

With some more queue adjustments, I currently have all the queues filling up, using .88.10 and MadVRtest5.ax

Decoder queue: 14-15/15
Upload queue: 8-9/9
Render queue: 8-9/9
Present queue: 4/4-4 (lower than I like but the highest setting that works)


Also, remember me mentioning that the Decoder queue (in exclusive mode) would always show one more than it should, such as 14-16/15? When I set the exclusive mode to 4 frames or below, it will show correctly, 14-15/15. Not sure if that has anything to do with this issue, though.

The "occluded" D3D you saw was most like me tinkering with things at one point with the log running and I unintentionally sent you a log with my messing around. Sorry about that. :(

I always can use .88.8 if I want use 10 bit output with higher " presented frames in advance" settings in 10 bit DSD11 mode but of course I couldn't play with the added /changed features in .88.10.

I do appreciate you taking extra time troubleshooting this issue with me even though I'm the only one to have reported it up to now. :thanks:

Here is the log for the full queues if you want to take a look.
http://s000.tinyupload.com/?file_id=48016178447616236926
The VSync reset stuff might have had a part in this, as well. Here's a new test build:

http://madshi.net/madVR8810test6.rar

This time it's a release mode build. So please double click "activate release mode.bat" first, then replace the madVR.ax file. Then please just double check if this test build still fills the queues with your current settings (4 frames pre-presented). If it does, as is well. If it doesn't, the VSync reset stuff is still a problem. I don't need a log this time. Just the information whether this build still fills the queues for you, or not. Thanks.

[Aleksoid1978]

nevcairiel has it right. If you use ChangeDisplaySettingsEx() the normal way, it will switch to 23.976, even if you specify 24.000. You have to call ChangeDisplaySettingsEx() twice, in a very specific way (see nevcairiel's post), to get true 24.000.

I try ... and it's don't help. Maybe something wrong with system ?? I do clean install latest Nvidia drivers. But - i create custom mode that work "true" 23.976 mode, maybe it's broken 24p mode ??

[madshi]

How does your code look like? Should be something like this:

LONG res = ChangeDisplaySettingsExA(MonitorInfo->szDevice, &devMode, 0, CDS_UPDATEREGISTRY | CDS_NORESET, NULL);
if (res == DISP_CHANGE_SUCCESSFUL)
res = ChangeDisplaySettingsEx(NULL, NULL, 0, 0, NULL);
This is at least what madVR is doing.

[Aleksoid1978]

How does your code look like? Should be something like this:

LONG res = ChangeDisplaySettingsExA(MonitorInfo->szDevice, &devMode, 0, CDS_UPDATEREGISTRY | CDS_NORESET, NULL);
if (res == DISP_CHANGE_SUCCESSFUL)
res = ChangeDisplaySettingsEx(NULL, NULL, 0, 0, NULL);
This is at least what madVR is doing.

This code from MPC-BE:

ChangeDisplaySettingsEx(DisplayName1, &dmScreenSettings, NULL, CDS_UPDATEREGISTRY | CDS_NORESET, NULL);
ChangeDisplaySettingsEx(NULL, NULL, NULL, 0, NULL);

[nevcairiel]

If you create a custom 23.976 mode on NVIDIA, it can break the 24.000 mode. Delete your custom mode, and both should work fine.

[madshi]

But why does it work with madVR then? At least that's how I understood Aleksoid1978's original comment.

We're talking about windowed mode playback, not FSE mode, right? In FSE mode things can be more complicated because Direct3D itself can also try to change/set the display mode...

[Aleksoid1978]

If you create a custom 23.976 mode on NVIDIA, it can break the 24.000 mode. Delete your custom mode, and both should work fine.

Well, what then watch a movie with a frequency 23.976 ??
Nvidia don't have a mode for 23.976 fps ))

P.S. we are talking about FSE.

[madshi]

How about windowed mode then? Does it work there?

And in FSE mode, are you changing the display mode after or before you enter FSE mode? If you change the display mode, after the switch to FSE has fully completed, your ChangeDisplaySettingsEx() call should overwrite whatever Direct3D has done before. If you change the display mode too early, Direct3D might switch it again during the windowed -> FSE mode transition.