madVR - high quality video renderer (GPU assisted)

[Sunset1982]

Windows Update will automatically re-install 353.54 which breaks it again.

If you dont know already: you can disable automatic driver updating in windows 10

[huhn]

AFAIK madVR uses cl_nv_d3d9_sharing for nvidia. so it can't work with these drivers.

nvidia removed this extension nothing you can do about you can only hope the next WHQL driver have them again so nvidia user can use nnedi3 with windows 10 if not you have to hope madshi is spending time on it. which could be a huge waste of time.

CL_KHL_d3d10_sharing could have the same copyback issue like AMD cl_khl_dx9_media_sharing. and who know if nvidia isn't removing cl_nv_d3d11_sharing too? i mean it looks like they have nothing better to do right now them crippling there own drivers.

there are workarounds to stop the windows updates for nvidia driver but wrong thread.

[leeperry]

It's an interesting test picture because even NNEDI3-256 still has noticeable aliasing in some image areas. Of course SuperRes doesn't improve on that.

I find it hard to understand your image descriptions, though. I'm not sure if @0.xx is the radius of the strength?? Or is it sometimes this and sometimes that?
It does come from a benchmarking BD: HD Benchmark 2nd Edition (http://www.spearsandmunsil.com/portfolio/hd-benchmark-2-0/)
Every pattern was created using our exclusive ultra-high-precision software tools and represents the state of the art in video reproduction.

They have many other nasty bits such as http://thumbnails113.imagebam.com/42452/4fffd8424512821.jpg (http://www.imagebam.com/image/4fffd8424512821)

"sxbr75+SR3@0.41" in .15: 3 passes, 0.41 strength.
"1@0.66" in .20: first figure is strength, second is radius.

Anyway, I was hoping for you explaining me how HQ looks so much closer to the ground truth than LQ and that didn't happen, I take it that my screenshots were hard to kill then.

I won't give up on SR(mostly due to the magic it does on motion blur, even more striking on 29.97fps footage O-M-G talk about a one-way ticket!), you were kind enough to add a kludge in order to force LQ in .20 but I take it that the seperate knobs for the number of passes and strength will never come back...even as kludges if I ask very very nicely? And this ** radius stuff will replace them?

Even 4*0.41 or 3*0.42 don't look nearly as good as 3*0.41 IME so I'm not willing to compromise whatsoever, your "pretty much the same" and "roughly the same" don't cut it by a very long shot so it sounds like I'll stick to .15 and just got myself a lot of free time suddenly.

If 2 passes at 1.0 are supposed to look "roughly the same" as 3 passes at 0.41 then I wonder why you spent countless hours nitpicking about a lot of details in mVR, such as chroma for instance when many ppl claim that differences IRL are completely invisible......nothing in what you do goes by the "pretty much the same" principle so color me surprised to read that you are willing to kill the SR golden goose *killer* feature in such a tremendous and dramatic way(to me anyway) :(

And if you are so concerned about the GPU consumption wasted by one extra pass then I wonder why you even allow 256 neurons NNEDI3 to begin with, this is not consistent at all. I couldn't care less about a few extra percents of GPU load if PQ looks better to me, I truly wonder how you came up with the idea that mixing the strength and number passes together as a single knob could ever work :confused:

But truth be told, I can't really think of anything to improve in .15 tbh(proper SR on chroma woulda been nice but hardly vital), PQ is truly beyond words so I'm totally cool with calling it my very own 1.0 and live happily ever after......and no more e-drama for you to cope with(well except when that other .15 LQ lover will be back from vacation next week ^^), happy happy joy joy :cool:

My only problem atm is that 1080p movies got more resolution but 720p encodes get the magical SR motion-blur treatment, choices..

I also don't understand why madHcNet32.dll is locked even when mVR is closed lately, I don't have any A/V resident app running and virustotal doesn't consider my mVR installation infected...oh well, that never happened before, it's only after a zillion .15/.20 rollings that it started acting up.

[James Freeman]

Madshi,

I suppose low latency mode is something that a player would call for not the user, because I don't see an option for that?

[ryrynz]

I suppose low latency mode is something that a player would call for not the user, because I don't see an option for that?

You got it.

[DragonQ]

Try v0.88.21. If that still fails, please upload a debug log.

Debug log here (http://www.aotplaza.com/Files/HTPC/madVR%20-%20log%20(DXVA%20processing%20failed).7z).

[Thunderbolt8]

l understand your concern. But please understand that most of today's content is actually a downscale, produced by the studios from their masters. DVDs were usually downscaled from 2K masters. Better Blu-Rays are downscaled from 4K masters. So upscaling video that was formerly downscaled is not something unusual, it's what we do every day.

The purpose of first downscaling and then upscaling again is that this is the only way we can objectively judge whether the upscaled image comes near to the original. If we don't use this approach, we have e.g. a DVD resolution source and an 1080p upscale, but whether the upscale is good or not nobody can say. Different upscalers, different sharpening algorithms produce different "looks". Some users prefer this, other users prefer that. Without having the original to compare to, if you ask 100 different users for which algorithm combination they prefer, you'll get 98 different answers.
Would it at least make sense to limit ourselves to the source and scaling resolutions that make most sense for this? E.g. 720p to 1080p or 1080p to 4k or 4k to 1080p? Not sure if scaling something like 400 pixels to 800 pixels would be of help for a media player (especislly not in the future when 4k becomes the standard)

[TheShadowRunner]

madshi, even with 0.88.21 that has the OSD rendering back to 0.88.16, the image is now black while seeking forward / backward.
This does not happen with the true/pure 0.88.16, any way around it?

[madshi]

The problem persists, unfortunately.
Does this test build fix it?

http://madshi.net/madVR8821b.rar

"sxbr75+SR3@0.41" in .15: 3 passes, 0.41 strength.
"1@0.66" in .20: first figure is strength, second is radius.
Might have made sense to mention that in your original post... ;) It's quite confusing if you use the same syntax to describe different settings, without actually explaining that anywhere.

Anyway, I was hoping for you explaining me how HQ looks so much closer to the ground truth than LQ and that didn't happen, I take it that my screenshots were hard to kill then.
I didn't comment on the images because I wasn't sure which settings you were using, see above.

From what I can see, your comparison is interesting, but not very goal oriented. You've posted a bunch of different screenshots with different settings, and all the conclusions I can draw from them are these:

1) Using a bunch of somewhat different settings results in images which look somewhat different.
2) You prefer one specific set of settings with one specific madVR version over a different set of settings with a different madVR version.
3) Latest SuperRes with default settings does produce aliasing with your test image, while with your preferred settings it's less of a problem.
4) With your specific test image, some other algo changes I did between v0.88.15 and v0.88.21 have a certain effect, too.

I'm not totally sure what your goal with those images were. If you just wanted to show that your settings with v0.88.15 produce a somewhat different result to default settings with v0.88.20 when using the "BilinearSuperRes" hack, you've succeeded, but other than that it's hard to draw any hard conclusions.

A goal oriented test would have been to use v0.88.15 for all images, and then to compare 3 passes with 0.65 strength to 2 passes with 1.00 strength, to check if there's a noticeably difference in image quality. But you didn't do that, so you didn't put any weight to your wish that you want to be able to adjust passes and strength separately.

FWIW, SuperRes is still not "finished". There's one change I plan to do for the next build, which will change the look of the image slightly again (but not too much). Furthermore I will probably increase the radius by default which should get rid of most aliasing problems.

If 2 passes at 1.0 are supposed to look "roughly the same" as 3 passes at 0.41 then I wonder why you spent countless hours nitpicking about a lot of details in mVR, such as chroma for instance when many ppl claim that differences IRL are completely invisible......nothing in what you do goes by the "pretty much the same" principle so color me surprised to read that you are willing to kill the SR golden goose *killer* feature in such a tremendous and dramatic way(to me anyway)
Details in chroma upscaling can be next to invisible in many situations. But there are situations where there's a dramatic difference, and obviously, when judging which algorithms to use, you choose test patterns/images where differences are especially noticeable.

So far nobody has shown any proof that 3 passes with lower strength looks better at all than 2 passes with higher strength. All the evidence so far suggests that both produce nearly identical results. Yes, there are tiny differences, but it's hard to say which is actually better. If there were proof that 3 passes with lower strength would objectively be better, I would consider allowing that, even if it costs more GPU power. But there's no evidence that points in that direction. And I'm not going to waste GPU power on something where nobody is able to produce any evidence of improvement with any test images.

I also don't understand why madHcNet32.dll is locked even when mVR is closed lately, I don't have any A/V resident app running and virustotal doesn't consider my mVR installation infected...oh well, that never happened before, it's only after a zillion .15/.20 rollings that it started acting up.
I've not changed anything there. But if your media player still runs, the DLL will still be loaded. Make sure your media player is really closed. It might still be lingering somewhere in your task manager.

Would it at least make sense to limit ourselves to the source and scaling resolutions that make most sense for this? E.g. 720p to 1080p or 1080p to 4k or 4k to 1080p? Not sure if scaling something like 400 pixels to 800 pixels would be of help for a media player (especislly not in the future when 4k becomes the standard)
The exact source and target resolution doesn't matter too much to any of the scaling algorithms. The scaling factor decides everything. 1080p -> 4k is exactly 2.00x scaling factor. Which is the same as 400 -> 800 pixels.

madshi, even with 0.88.21 that has the OSD rendering back to 0.88.16, the image is now black while seeking forward / backward.
This does not happen with the true/pure 0.88.16, any way around it?
madVR now renders in paused and stopped mode, too. When seeking, the media player usually stops playback for a short time. So madVR might think "oh, I'm in stopped mode, so I'm going to render black now". There's a workaround in place which IIRC blocks rendering from occurring for 1 second after seeks. If your seek takes longer, madVR might be tempted to render black.

This is only a cosmetical issue, right? Why do seeks seemingly take so long in your case?

[XMonarchY]

Is the "Low Latency Mode" some new option or is it enabled by default?

With 88.20, I can set Chroma Upscaling NNEDI3 64n with SR Passes = 4 & Strength = 1 and Upscaling Refinement SR to Strength = 4, Radius = 0.66 and have no presentation glitches.

With 88.21, I get presentation glitches unless I lower Chroma Upscaling SR to Passes = 2 & Strength = 1 and also lower Upscaling Refinement SR to Strength = 2, Radius = 0.66 .

Not sure why - maybe presentation glitches were not properly reported in 88.20?

[nevcairiel]

Is the "Low Latency Mode" some new option or is it enabled by default?

Thats not an option users need to worry about, its only for players that want to show an interactive OSD with madVR.

[clsid]

@madshi
Symantec keeps detecting mvrsettings32.dll after each new release. You can submit a false positive report here (if you haven't done so already): https://submit.symantec.com/false_positive

I have already done it for the current version.

[madshi]

With 88.21, I get presentation glitches unless I lower Chroma Upscaling SR to Passes = 2 & Strength = 1 and also lower Upscaling Refinement SR to Strength = 2, Radius = 0.66 .

Not sure why - maybe presentation glitches were not properly reported in 88.20?
SuperRes in Upscaling Refinement got more expensive in v0.88.21 compared to v0.88.20, because that was the only way to make higher radius settings work without artifacts. SuperRes is still a work-in-progress. Performance might change from one version to the next. When all is said and done, maybe we can squeeze some more performance out of SuperRes. Makes no sense to do time consuming optimizations right now, when things are not in their final state yet.

[madshi]

@madshi
Symantec keeps detecting mvrsettings32.dll after each new release. You can submit a false positive report here (if you haven't done so already): https://submit.symantec.com/false_positive

I have already done it for the current version.
Argh, when are they finally going to learn? :mad:

[Thunderbolt8]

The exact source and target resolution doesn't matter too much to any of the scaling algorithms. The scaling factor decides everything. 1080p -> 4k is exactly 2.00x scaling factor. Which is the same as 400 -> 800 pixels.well then at least use the scaling factors which refer to the scalings of the resolutions I suggested. also, using resolutions with which you are still able to recognize changes of course.

[madshi]

well then at least use the scaling factors which refer to the scalings of the resolutions I suggested.
I did exactly that. Using 2.0x scaling, same as 1080p -> 4K.

[aufkrawall]

Argh, when are they finally going to learn? :mad:
Probably never, since most likely there's not much work done by humans when false positive threshold isn't exceeded.

[leeperry]

Might have made sense to mention that in your original post... ;) It's quite confusing if you use the same syntax to describe different settings, without actually explaining that anywhere.
Well, these are the only knobs in both builds. I don't see what's confusing, 0.66 radius would even appear to be the default value:

http://thumbnails113.imagebam.com/42462/57934f424611007.jpg (http://www.imagebam.com/image/57934f424611007)

http://thumbnails113.imagebam.com/42462/7b4625424611673.jpg (http://www.imagebam.com/image/7b4625424611673)

I'll give you that I didn't mention "softness" in .15 but then again it shoulda been called "bluriness", this knob is beyond useless IME.

I'm not totally sure what your goal with those images were.
1) Refute the following claims you made a few days ago:
The reason for that is that LQ mode sucks. Big time.
the direction LQ is going is away from the ground truth, while HQ is going nearer to the ground truth

It definitely does in .20 because even a strength of 1 is way oversharp, I don't see how you could say that 3@0.41LQ in .15 sucks this bad compared to HQ and that HQ is so much closer to the ground truth.

It's not quite the end-user's fault if you've changed the SR logic in a way that makes LQ useless in .20.

Again, it's the middle of summer and many ppl are on vacation......still, not every mVR tester has gone AWOL and someone else would appear to see things the same way I do(God forbid ^^):
It's hard to compare because strength 1 for nohq is too strong. (..)
HQ still has that almost softer than original look with slight ringing around numbers. White is spilled into black area, black is spilled into white area.

NoHQ doesn't have that problem even on higher strengths. But as I said even strength 1 is too strong for my taste.

I believe it to be rather undeniable in my comparison that HQ is way softer and that reasonable LQ settings in .15 look "better"™, as in "closer to the ground truth".

2) You've decided to only provide on single strength knob in .20, being your own very personal homebrew experimental recipe of a mix between the number of the passes and strength(as known in .15). This cannot work IME and it definitely doesn't in .20 as even a strength of 1 is way too sharp to be of any use huh(and again, I'm not the only one thinking so).

On one hand you refuse to provide knobs in order to finetune sxbr and on the other LQ SR with a strength of 1 is über-sharp and HQ is blurry as hell, major show stoppers at work here.

3) Show that sxbr125 with 3@0.41LQ in .15 looks better than anything HQ could ever provide in .15 or .20.

4) Allow me to see that NEDI has been superseded by sxbr125, once the SR settings are finetuned in order to counterbalance its sheer sharpness.

A goal oriented test would have been to use v0.88.15 for all images, and then to compare 3 passes with 0.65 strength to 2 passes with 1.00 strength, to check if there's a noticeably difference in image quality. But you didn't do that, so you didn't put any weight to your wish that you want to be able to adjust passes and strength separately.
Right, well 3@0.65 was nice with NEDI but I now prefer 3@0.41 with the sharper sxbr125. That's the only sharpness knob I have access to(the sharpness setting in my TV looks horrific) so I make do with what I got and once all properly set it truly does wonders :)

I did use both builds with the sole features they provide, stop hiding knobs from the end-user and you'll get your fair comparison.

As I said, in .15 I don't like 4@0.41 or 3@0.42, I'm not sure such tiny differences would be visible on screenshots at all ....the same way most of the chroma suboptions would be mostly invisible too, yet users are allowed to pick one over another.......if they all look "roughly the same", you might as well ditch most of them and only keep one or two for all I know. I really wasn't aware that mVR was going towards a "more or less the same ya know the deal" route, good to know.

So far nobody has shown any proof that 3 passes with lower strength looks better at all than 2 passes with higher strength. All the evidence so far suggests that both produce nearly identical results. Yes, there are tiny differences, but it's hard to say which is actually better. If there were proof that 3 passes with lower strength would objectively be better, I would consider allowing that, even if it costs more GPU power. But there's no evidence that points in that direction. And I'm not going to waste GPU power on something where nobody is able to produce any evidence of improvement with any test images.
Right, so you make subjective choices for the end-user because you know it will look "nearly" identical even if it doesn't at all to the end-user.

Lemme know what screenshots might possibly change your mind then? Would a comparison of 2@1.0LQ against 3@0.41LQ with the former being sharper and less detailed make your day? I should fairly easily be able to make that happen.

BTW, I also really like 3@0.41(0.00 softness eventually) SR on chroma with sxbr125+AR...PQ stunningness never ends hah! :cool:

I've not changed anything there. But if your media player still runs, the DLL will still be loaded. Make sure your media player is really closed. It might still be lingering somewhere in your task manager.
I did check eventually and it is not, I can even rename PotP's folder without a itch. W7 is prolly keeping your DLL locked for some reason, this very DLL would appear to be related to networking.

[madshi]

I'm not sure such tiny differences would be visible on screenshots at all ....the same way most of the chroma suboptions would be mostly invisible too
As I said, when using the "right" test images/videos, different chroma scalers can look vastly different from each other. So what you're saying here (and already said in your previous post) is flat out incorrect.

Lemme know what screenshots might possibly change your mind then? Would a comparison of 2@1.0LQ against 3@0.41LQ with the former being sharper and less detailed make your day? I should fairly easily be able to make that happen.
I've told you many times already. 3 passes with 0.66 strength should be roughly identical to 2 passes with 1.00 strength. So make comparison screenshots for those two situations with v0.88.15. You can use any other combination of passes and strengths, too. Just make sure that they sum up to roughly the same value. E.g. 3 * 0.66 = 1.98. 2 * 1.00 = 2.00. And 1.98 is roughly identical to 2.00. If you insist that you have to use a strength of 0.41, then compare 3 passes with 0.41 with 2 passes with 0.61. Because 3*0.41 is roughly identical to 2*0.61.

I did check eventually and it is not, I can even rename PotP's folder without a itch. W7 is prolly keeping your DLL locked for some reason, this very DLL would appear to be related to networking.
Well, some process must still have it loaded. Maybe madHcCtrl.exe is still running? Maybe you've changed the madVR tray icon setting to have it always visible?

[aufkrawall]

Something's still wrong with SuperRes, causing a load of aliasing (tested with that lighttower picture leeperry posted some days ago).
Doesn't happen with this (https://github.com/zachsaw/MPDN_Extensions) SuperRes version (as long as softness isn't used).

[madshi]

Something's still wrong with SuperRes, causing a load of aliasing (tested with that lighttower picture leeperry posted some days ago).
Doesn't happen with this (https://github.com/zachsaw/MPDN_Extensions) SuperRes version (as long as softness isn't used).
I'm going to reenable linear light downscaling for SuperRes in the next build (currently I'm using gamma light downscaling), which may fix the problem with this specific image, but I'm not sure. You may also have to increase the radius to 1.00, or at least higher than 0.66. Shiandow is also still working on SuperRes. So neither the version in madVR nor the one in MPDN is "final" yet.

[Telion]

madVR now renders in paused and stopped mode, too. When seeking, the media player usually stops playback for a short time. So madVR might think "oh, I'm in stopped mode, so I'm going to render black now". There's a workaround in place which IIRC blocks rendering from occurring for 1 second after seeks. If your seek takes longer, madVR might be tempted to render black.
Would you please increase this to 2 sec at least? I have a rather slow rig where some seeks get into this interval without a black screen, whereas some don't and I see a black screen flashing. So it's a tad irritating to have such fickle seek experience.

[DragonQ]

Does this test build fix it?

http://madshi.net/madVR8821b.rar

Looks like it, yes. Thank you.

By the way, are there any known issues with "use Direct3D 11 for presentation" or "use separate device for presentation" with HD4000 IGPs? On my laptop using either of these options leads to major presentation issues (frames jumping about all over the place). Not a big deal since I can disable both options, just wondering if you knew.

[leeperry]

As I said, when using the "right" test images/videos, different chroma scalers can look vastly different from each other. So what you're saying here (and already said in your previous post) is flat out incorrect.
Right, so you don't want to have two seperate SR knobs for the number of passes and strength in order to avoid clogging the mVR settings control panel(when they both make extremely obvious changes to the picture), but OTOH it'd make perfect sense to for instance provide as many as 11 chroma upscaling algorithms with three subsettings, that might very well sometimes make barely visible differences using 400% magnification on nasty test patterns.

Reality is that 99.9999999% of mVR users watch good ole SD/HD movies and will either go cheap coz they have to, J3AR due to its high bang/bucks ratio or NNEDI3/sxbr if they wanna go all the way sharpness-wise.

Seriously, if anything is bound to confuse new users it's for instance the ability to upscale chroma using that many different algorithms, I mean who would ever use Spline for this job? No one, yet this useless option is here confusing the hell out of newbies.

The whole point of two separate knobs for SR is the ability to finetune the final picture sharpness based on the end-user personal taste, display native sharpness(due to blurry/grainy anti-reflective coatings for instance, especially on TN computer screens that look hazy compared to mineral glass Plasma's), viewing distance(the farther the sharper), the MTF/OTF sharpness of the end-user prescription eyewear lenses(organic glass and even worse polycarbonate come with very poor constringence (https://en.wikipedia.org/wiki/Abbe_number) and have to be counterbalanced), how the TV applies its RGB/YcBcR back and forth conversions, how sharp the image doubling algorithm is and so on. Botttom line is that mVR is in dire need of a very subtle sharpness knob IMO and you are against it as of now.

I've told you many times already. 3 passes with 0.66 strength should be roughly identical to 2 passes with 1.00 strength. So make comparison screenshots for those two situations with v0.88.15. You can use any other combination of passes and strengths, too. Just make sure that they sum up to roughly the same value. E.g. 3 * 0.66 = 1.98. 2 * 1.00 = 2.00. And 1.98 is roughly identical to 2.00. If you insist that you have to use a strength of 0.41, then compare 3 passes with 0.41 with 2 passes with 0.61. Because 3*0.41 is roughly identical to 2*0.61.
Fair enough, I'll give it a shot but that won't change anything to the fact that 2*0.61 is impossible to achieve in the newest mVR builds as you didn't make the logic of the new strength knob public and again, even a strength of 1 in LQ mode is way too sharp to be of any use in .20.

Well, some process must still have it loaded. Maybe madHcCtrl.exe is still running? Maybe you've changed the madVR tray icon setting to have it always visible?
Nope I also checked and it's not running either, only that very DLL is locked. The mVR tray icon isn't visible either. I guess I could try this app (http://filehippo.com/download_unlocker/) and see what's locking it up but it'll be Explorer anyway.

[KoD]

There is a known issue if D3D11 does not officially support the refresh rate you want to use. In that case some GPU drivers run into trouble with queues not filling properly, especially when using a large number of prepresented frames. There's no solution to this. madVR is able to make D3D11 use the refresh rate you want, but with some GPU drivers these queues-not-filling problem is the consequence. Probably if you limit yourself to 1080p60, you'll not have this problem.
Hi madshi, the problem does not seem to be related to D3D11 supported refresh rates. It happens no matter the refresh rate, from 23.976 to 60Hz. As I said, the issue only happens when madVR sends 10bit per color channel output, and the TV receives it (well, it says it receives 12bit per channel). And that happens only when using D3D11 + fullscreen, and the TV set configured as "10bit or more" in the madVR settings.

As for me, it's not important if this gets fixed or not, I am not using fullscreen mode, as it's too annoying that lag which happens when I try to display the context menu in MPC-HC to switch the audio or subtitle track. With windowed mode, and therefore no 10 bit per channel output, there are no issues, even with D3D11 (and the framerate does not matter in this case, either).

As an additional note, the sudden frame skips that happen with 0.80.20 when turning the OSD on/off and that people reported, I have also seen them - and they also happen only when using D3D11 and fullscreen mode (did not see them when using windowed mode, or D3D9). I have not yet tested 0.88.21, so I don't know if these frame skips are still present.

Who knows, maybe the issue is in the way MPC-HC interacts with madVR, since the issue happens only after two or more switches between fullscreen and windowed mode. Or it could be something weird with the nvidia driver.

[TheShadowRunner]

This is only a cosmetical issue, right? Why do seeks seemingly take so long in your case?
Yes it seems only cosmetic, I play rather high bitrate videos from a NAS, guess that's why.
Would you please increase this to 2 sec at least? I have a rather slow rig where some seeks get into this interval without a black screen, whereas some don't and I see a black screen flashing. So it's a tad irritating to have such fickle seek experience.
Agreed, 2 or even 3 sec would be better.

[XMonarchY]

DXVA deinterlacing is the same deinterlacer as CUVID deinterlacer. HQ is default for DXVA deinterlacing.

and to be more precise CUVID deinterlacing doesn't allow madVR to use IVTC on the interlaced video stream. so there is nothing to win only things to loose.

and different decoder doesn't have better picture quality.

and about openCL looks like nvidia has removed cl_nv_d3d9_sharing in newer drivers. i'm not 100% sure if madVR uses that extensions. if it does everything make sense.

Any word on this from madshi regarding this? Does NNEDI3 use CL_NV_D3D9_SHARING?

With 353.49 Hotfix drivers, my OSD shows "Chroma > NNEDI64" and below "Image > Catmull-Rom AR" . It doesn't say NNEDI3 64, but just NNEDI64. Does that mean NNEDI3 is being used or not?

[aufkrawall]

Yes, it must be a new typo. Why not judging by image quality?

[nevcairiel]

You should all really stop speculating on things that don't have a shred of proof that it matters. NNEDI clearly still works. If you want to test something, check if its slower or something.

[BetA13]

maybe im too stupid, but how can i change lq / hq super ress?
i know i read it somewhere but cant find it anymore..
i cant see teh setting HQ/LQ . or did i miss something?

greetz :)

also, i cant see any difference with super ress on or off.. what do i have to look for?
its one of the only settings i dont understand yet..

[jewshawn2]

Just a follow up. The bug I reported has been fixed in the latest release.

madVR v0.88.21

* OSD rendering back to 0.88.16 logic, except when low latency mode is active
* fixed: DXVA processing failed when video stream switched resolution
* fixed: render times weren't shown correctly
* fixed: SuperRes bigger radius values could cause artifacts
* fixed: low latency mode sometimes wasn't turned off when it should


I am reporting a bug that was introduced since v0.88.17.

In order for OBS (Open Broadcaster Software) to capture video in Potplayer with madVR, you have to use "Game Capture" source. I was told by someone on the OBS forum that this uses OpenGL to capture video. And it is the only method to capture video with madVR as the renderer.

Since v0.88.17 video capture using OBS (both versions) and Potplayer causes unwatchable jittery/stuttering video. The video looks perfectly fine on screen. But the OBS capture window shows jittery video. v0.88.16 was the last release that worked fine.

The bug can be reproduce on both of my PCs using the default madVR settings and default PotPlayer settings. However, if I use a different video player like MPC-HC x64 or bsplayer with madVR the video capture in OBS is fine. But when I adjust volume level the OSD causes stuttering video in the capture window.

I don't expect this bug report to get a lot of attention since it's very specific but I still wanted to report it for documentation purposes. I hope other forums members can reproduce the bug and verify my claims.

These were the changes introduced to madVR, perhaps one of these changes broke functionality between madVR, Potplayer, and OBS:
v0.88.17
* madVR now renders in paused and stopped mode, too
* added automatic OSD low latency logic
* added SuperRes anti-ringing filter
* fixed little SuperRes quality detoriation introduced in v0.88.16
* fixed: high GPU consumption in paused mode (PotPlayer, Kodi DSPlayer)
* all (useful) IVideoWindow APIs now work even when no pins are connected

My setup:

madVR v0.88.17 thru v0.88.20

x64 bit Potplayer [1.6.55124] 2015/07/10

x64 OBS Multiplatform 0.11.1

x64 OBS Original 0.652b

x64 Win 7 / Nvidia 8800 GTS

[huhn]

You should all really stop speculating on things that don't have a shred of proof that it matters. NNEDI clearly still works. If you want to test something, check if its slower or something.

sorry nnedi3 doesn't work with 353.50, 353.54 and 353.62.
this should be proof enough: http://abload.de/img/nnedi3h0sib.png

and the only thing that is clearly changed in the driver is the removed cl_nv_d3d9_sharing.

if madVR isn't using cl_nv_d3d9_sharing than the reason is something else.

but what so ever nnedi3 doesn't work but openCL in general does work.

[Ver Greeneyes]

maybe im too stupid, but how can i change lq / hq super ress?
i know i read it somewhere but cant find it anymore..
i cant see teh setting HQ/LQ . or did i miss something?LQ mode was removed. IIRC madshi said you can get something close to it using AdaptiveSharpen, though obviously there will be some performance cost. Edit: But see Unr3al's post (http://forum.doom9.org/showthread.php?p=1731879#post1731879) for a hidden way to enable it.

also, i cant see any difference with super ress on or off.. what do i have to look for?Try using more than 1 pass, at 3 or 4 passes the difference should be pretty clear as long as you're actually upscaling.

[Anima123]

What do you guys think the default value of 'radius' of SuperRes should be? I really like it be 0.77 or so, to me it's a good balance and the result effect is quite impressive.

[pirlouy]

@BetA13: For SuperRes HQ/LQ, you have to use .15 version (link in the first post)

@Anima123: Careful; what you like is not what it should be. The only chance to judge is with screenshots comparison to original image.
http://forum.doom9.org/showthread.php?p=1730855#post1730855

[mindz]

Looks like it, yes. Thank you.

By the way, are there any known issues with "use Direct3D 11 for presentation" or "use separate device for presentation" with HD4000 IGPs? On my laptop using either of these options leads to major presentation issues (frames jumping about all over the place). Not a big deal since I can disable both options, just wondering if you knew.

I second that. Im using a HD4600 on my desktop. When enablding D3D11, the frames skip and flicker all over the place, it is not watchable.

[Unr3aL]

Just FYI, LQ SR might still work as this originates from 0.88.19b:

...

(P.S: leeperry, you can create an empty file called "BilinearSuperRes" in the madVR folder. That means HQ turned off. I pretty much hate the look it produces, though, so use it at your own "risk".)

[abotiz]

Hello

I need help to understand what I'm going to set the MPC-HC and Madvr.
I have a HTPC that is connected with HDMI to AV Marantz 6900sr and play with EPSON Tw7200.
Should I set something on Madvr or MPC, or fix Marantz everything.

thanks in advance

[Asmodian]

Any word on this from madshi regarding this? Does NNEDI3 use CL_NV_D3D9_SHARING?

With 353.49 Hotfix drivers, my OSD shows "Chroma > NNEDI64" and below "Image > Catmull-Rom AR" . It doesn't say NNEDI3 64, but just NNEDI64. Does that mean NNEDI3 is being used or not?

Nvidia's next Windows 10 drivers, 353.62, seem to still be missing this (the OSD, rendering times, and look all indicates NNEDI isn't running). I am worried this will be the norm going forward but Nvidia still hasn't released a driver newer than driver 353.30 themselves, only Windows Update drivers. :(

I think 353.49 still has it, that is probably the newest driver that works for madVR NNEDI3. 353.54 is when I noticed NNEDI3 stop working.

[ashlar42]

Does SmoothMotion when activated "always" in the settings works (and taxes system resources) only when a frame drop/repeat would occur? From all I've read (that it doesn't create extra frames as other "smooth" options do on TVs) I would say this is the case, but I'd like to know for sure. Not just for system resources but to be sure that the video stays untouched unless needed (to avoid frame drops/repeats, that is).

[huhn]

Does SmoothMotion when activated "always" in the settings works (and taxes system resources) only when a frame drop/repeat would occur? From all I've read (that it doesn't create extra frames as other "smooth" options do on TVs) I would say this is the case, but I'd like to know for sure. Not just for system resources but to be sure that the video stays untouched unless needed (to avoid frame drops/repeats, that is).

smooth motion is only blending frames and doesn't create motion interpolated frames.

smoothmotion is blending frames based on the video clock and the audio clock/referance clock so it is kind of blending frames the whole time.

the performence impact is about nothing at all.

[aufkrawall]

Geforce driver 352.62 is now available as a package directly from NV:
http://international.download.nvidia.com/Windows/353.62/353.62-desktop-win10-64bit-international.hf.exe
Of course cl d3d9_sharing extension is still missing (since it's the same driver version as the driver from WU).

SM5.0/DirectCompute NNEDI3 implementation badly needed. :(

[Akeno]

smooth motion is only blending frames and doesn't create motion interpolated frames.

smoothmotion is blending frames based on the video clock and the audio clock/referance clock so it is kind of blending frames the whole time.

the performence impact is about nothing at all.

Is there any advantage to using smooth motion when your refresh rate is an exact multiple of the video frame rate or is it just wasted resources?

[madshi]

Geforce driver 352.62 is now available as a package directly from NV:
http://international.download.nvidia.com/Windows/353.62/353.62-desktop-win10-64bit-international.hf.exe
Of course cl d3d9_sharing extension is still missing (since it's the same driver version as the driver from WU).
Which extensions are available now?

[aufkrawall]

The smaller the difference between video fps and refreshrate is, the more motion blur you get with smooth motion.
However, if you want to eliminate repeated frames at all costs (e.g. if 1 frame is repeated per hour or so), it would be still useful if motion blur doesn't annoy you.

[aufkrawall]

Which extensions are available now?
http://abload.de/image.php?img=353.62x5pbz.png

[ashlar42]

The smaller the difference between video fps and refreshrate is, the more motion blur you get with smooth motion.
However, if you want to eliminate repeated frames at all costs (e.g. if 1 frame is repeated per hour or so), it would be still useful if motion blur doesn't annoy you.
Hmmm, ok, the exact opposite of what I thought. Without Reclock I have 1 frame drop every 4 hours or so at 23.97599Hz (instead of 23.97602) and 1 frame drop every 38 minutes at 50.0018Hz. I thought I could avoid Reclock but this doesn't seem to be the case.
Thanks.

[huhn]

Is there any advantage to using smooth motion when your refresh rate is an exact multiple of the video frame rate or is it just wasted resources?

there is no general answer if you get an repeated or dropped frame every 4 h or lower than yes it is still pretty useful.

if you have an very unlikely perfect synced audio and video clock no it just wastes some system performance in this case.

[huhn]

Hmmm, ok, the exact opposite of what I thought. Without Reclock I have 1 frame drop every 4 hours or so at 23.97599Hz (instead of 23.97602) and 1 frame drop every 38 minutes at 50.0018Hz. I thought I could avoid Reclock but this doesn't seem to be the case.
Thanks.

the trick is it to use smooth motion only at the highest possible refresh rate. and motion blur is not the right name for the possible visible issue of smoothmotion at least in my opinion.

[aufkrawall]

How'd you call it? Ghosting?