Media Player .NET (MPDN) - D3D HQ GPU Video Renderer [v2.49.0/v1.31.0 27 Dec 2018]

[huhn]

this should stop all none security updates for now:
http://abload.de/img/update8mxgw.png

and there is a file/option from microsoft to stop "third party" updates. and there is a software to block some updates here a german page with it: http://www.chip.de/downloads/Microsoft-Hotfix-Windows-10-Updates-verstecken-oder-blockieren_81466169.html

I personally use 353.62 so I don't use any of this.

and here a work around from the beta times: http://answers.microsoft.com/en-us/insider/forum/insider_wintp-insider_devices/how-do-i-stop-nvidia-driver-34965-from-auto/1e82e119-789c-4809-bcd3-56e1515bedc2?tab=question&status=AllReplies#tabs

[aufkrawall]

Problem is that not the device is hidden from WU, but only the specific driver. That means if a new driver is released on WU, it will automatically be downloaded and installed if you don't run the tool from MS to hide drivers timely.
The setting in the advanced system options to not download driver updates from WU doesn't really have an effect, it downloaded drivers with it disabled for many users (me included).

The only safe way is to manually disable Windows Update service and manually start it again and directly after this start the update hide tool from MS before searching for updates.
But this can't be reommended to most users, since they will forget to enable the service again and miss out security updates.

[ryrynz]

Here ya are lads.

http://i.imgur.com/NN961F9l.jpg

http://i.imgur.com/Tfz6mJRl.jpg

[aufkrawall]

I alrady said that it doesn't have to work.

[ryrynz]

Seems to be working fine for me.

[aufkrawall]

But internet forums are full of reports that it didn't work.

[huhn]

don't forget most people on the internet aren't any good with PCs.

[Belphemur]

I went for this tool first : http://www.guru3d.com/files-details/display-driver-uninstaller-download.html
To remove all old drivers and everything that could be problematic. It also disable for you the automatic update of drivers.

Then when I restarted and I installed the version of the driver I wanted. I've done the the same for the Intel drivers (I was having some crash with it).

[aufkrawall]

afaik, DDU just sets the option in the advanced system settings that is shown on ryrynz' screenshots above.

[aufkrawall]

This time, MPDN crashed with this error while being in the render script settings:
http://abload.de/thumb/mpdncrash8osya.png (http://abload.de/image.php?img=mpdncrash8osya.png)

Well, however playback so far is totally fine when doing nothing else. There's some stutter during playback when changing volume via mouse scroll, but that's not a huge issue to me.

Btw: Jinc2D with few taps can be well used together with SuperRes for scaling below factor 1.5x, image isn't doubled and so a lot of GPU resources are saved, compared to the other available algorithms.
Scaling BD content to WQHD looks great this way.

I lowered SuperChromaRes strength a bit (to 1.7), since it brightens colors (mostly red) up a bit (or more than a bit). MPDN Jinc with 4 taps w.o. AR looks good and isn't too expensive together with SuperChromaRes.
However, Jinc3 AR of madVR is still better for this purpose, imho.

[Zachs]

On a different note, will there be improvements to startup speed and such soon?

Check out the latest release. With the installed version, MPDN without extensions now starts up immediately for both x86 and x64 editions.

Startup time with extensions had also been improved and on my system it is now less than half a second. We will continue to look into startup speed improvements (the bulk of the time is spent in creating and initialising the playlist extension).

[Zachs]

This time, MPDN crashed with this error while being in the render script settings:
http://abload.de/thumb/mpdncrash8osya.png (http://abload.de/image.php?img=mpdncrash8osya.png)

Well, however playback so far is totally fine when doing nothing else. There's some stutter during playback when changing volume via mouse scroll, but that's not a huge issue to me.

Btw: Jinc2D with few taps can be well used together with SuperRes for scaling below factor 1.5x, image isn't doubled and so a lot of GPU resources are saved, compared to the other available algorithms.
Scaling BD content to WQHD looks great this way.

I lowered SuperChromaRes strength a bit (to 1.7), since it brightens colors (mostly red) up a bit (or more than a bit). MPDN Jinc with 4 taps w.o. AR looks good and isn't too expensive together with SuperChromaRes.
However, Jinc3 AR of madVR is still better for this purpose, imho.

I'm not sure what the crash is and I haven't been able to replicate the problem. Perhaps send me your config files and some instructions on how to replicate the issue?

MPDN's Jinc2D is similar to AviSynth's - in fact, you'll find the code to reference AviSynth's Jinc implementation too. I'm not sure what madVR's Jinc is but I think it is similar (i.e. both EWA) to MPDN's Jinc2D. Perhaps madVR uses different weights, but only madshi can answer that (MPDN's Jinc2D is open source, madVR's Jinc is closed source).

[aufkrawall]

MPDN's Jinc2D would probably be fine for chroma, but yet it can only be used for luma (and only for upscaling).
That other Jinc of MPDN (that comes with the player itself, not with the render scripts) is muuuch softer.

My config isn't anything special, I think crashes are rather related to specific actions in a row than to a specific config.
Maybe enable some kind of debug mode? Then I can provide logs.

[aufkrawall]

2.39 hasn't yet crashed even once while changing render script settings.

Deband seems noticeably improved: In the example I posted earlier, higher power now reduces the banding better.
And even if set to 1, it doesn't seem to be a huge detail killer.
However, I really dislike the grain. It is easy to perceive but doesn't seem to have a real positive effect. Thankfully it can be turned off.
In some areas, Shiandow's algorithm is better than madshi's and vice versa.

For SuperRes, smoothness is still in the GUI (but doesn't seem to have an effect). I found it very useless anyway, introducing lots of aliasing (shouldn't it do the exact opposite?).

As for chroma, I'm now with custom chroma scaler (B: 1; C: 0.2) + SuperChromaRes (1 pass, strength 1.3). Hard to notice a difference to madVR Jinc3 AR without a comparison with some cartoon examples.
Jinc2D with configurable AR filter, like already existing for luma, would probably be better though.

[aufkrawall]

Ok, here's an example (filmed skies) where madVR deband still looks clearly better:
http://www41.zippyshare.com/v/hqA15LOW/file.html

[ryrynz]

2.39 hasn't yet crashed even once while changing render script settings.


I noticed switching between NNEDI3 versions a couple of nights back that I didn't get any crashing, I was totally expecting it to.

[Zachs]

Did you experience crashing when switching scripts too?

[Anima123]

Just noticed that MPDN's FSE mode actually performs worse than desktop mode, due to spikes of high rendering time which causes in-fluidity during playback of videos. Desktop mode plays well though.

Windows 8.1 64-bit, nVidia 880M Optimus system, with latest version of MPDN, render script SuperRes used.

[ryrynz]

Just noticed that MPDN's FSE mode actually performs worse than desktop mode, due to spikes of high rendering time which causes in-fluidity during playback of videos. Desktop mode plays well though.

Windows 8.1 64-bit, nVidia 880M Optimus system, with latest version of MPDN, render script SuperRes used.

Does it apply to all D3D versions and bit depth outputs? Is your refresh rate the same in FSE mode?

[kingpage]

Thanks for such an awesome player. I love it!

I came from Potplayer where I could jump forward and backward instantaneously (but inaccurately).

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

I had a look to see if I could modify one of your extensions, Navigation.cs. Since it is trying to calculate where the next frame is, it's quite slow. StepFrame() is the only quick one but it pauses the playback and it's only forwarding by 1 single frame). Going back 1 frame on the other hand, Jumpframe (-1), is as slow as the Jump(x) method.

The next or previous keyframe isn't exposed in the methods of the PlayerControl class, unfortunately. I was wondering if you would consider adding a feature like that (it's also implemented in all the major media players, such as VLC, kmplayer, MPC-HC, etc) that allows users to instantly jump to keyframes so that we don't need to wait. The intervals between keyframes are usually 5-10 seconds long, really nice to have when precision isn't required (we can still have the ability to jump single frames), which is most of the time.

[Zachs]

Thanks for such an awesome player. I love it!

I came from Potplayer where I could jump forward and backward instantaneously (but inaccurately).

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

I had a look to see if I could modify one of your extensions, Navigation.cs. Since it is trying to calculate where the next frame is, it's quite slow. StepFrame() is the only quick one but it pauses the playback and it's only forwarding by 1 single frame). Going back 1 frame on the other hand, Jumpframe (-1), is as slow as the Jump(x) method.

The next or previous keyframe isn't exposed in the methods of the PlayerControl class, unfortunately. I was wondering if you would consider adding a feature like that (it's also implemented in all the major media players, such as VLC, kmplayer, MPC-HC, etc) that allows users to instantly jump to keyframes so that we don't need to wait. The intervals between keyframes are usually 5-10 seconds long, really nice to have when precision isn't required (we can still have the ability to jump single frames), which is most of the time.

I'll add that to the PlayerControl class.

[kingpage]

I'll add that to the PlayerControl class.

Great! Thanks so much for your great work. Keep it up!

[Zachs]

Great! Thanks so much for your great work. Keep it up!

Turns out there's no need to. A simple change to Navigation.cs (https://github.com/zachsaw/MPDN_Extensions/commit/2ffc56e765fe18a6787e9640a3a449bb2f280169) was enough to do the trick. It'll be available in the next MPDN Extensions release.

EDIT: v1.12.0 is now available.

[Zachs]

MPDN's Jinc2D would probably be fine for chroma, but yet it can only be used for luma (and only for upscaling).
That other Jinc of MPDN (that comes with the player itself, not with the render scripts) is muuuch softer.

Just released v1.12.0 - it now has Jinc2D Chroma. Oh by the way Jinc2D not only used for luma - it's used for upscaling the whole image (chroma included - actually RGB to be more accurate). It's just the first stage where chroma is upscaled to luma size isn't being done in Jinc2D. Now Jinc2D Chroma can be used for this particular purpose.

[ryrynz]

Zach, does two pass NNEDI3 make sense over just one pass? There's no option for a single pass so I assume the benefits outweigh the additional performance hit.

My quick evaluation of the second pass yielded little in the way of any tangible improvement setting the second pass from 16 to 256.

[nevcairiel]

Zach, does two pass NNEDI3 make sense over just one pass? There's no option for a single pass so I assume the benefits outweigh the additional performance hit.

My quick evaluation of the second pass yielded little in the way of any tangible improvement setting the second pass from 16 to 256.

Its always two passes, the new options just allow you to specify different strength for the second pass. The first pass is more important, so its probably useless to set the second pass to a higher neuron count - instead increase the first pass and lower the second.

[ryrynz]

Its always two passes, the new options just allow you to specify different strength for the second pass. The first pass is more important, so its probably useless to set the second pass to a higher neuron count - instead increase the first pass and lower the second.

Ah, madVR never made any reference it from what I saw.
That makes sense not setting it higher than the first pass (large waste of resources)
Zach, in this case would you think it would be wise to disable higher counts for the second pass?

Also could you look at the anti-ringing? I enabled it for Jinc 2D chroma @strength 0.85 and the whole image softened considerably.. something's wrong there.

[kingpage]

Turns out there's no need to. A simple change to Navigation.cs (https://github.com/zachsaw/MPDN_Extensions/commit/2ffc56e765fe18a6787e9640a3a449bb2f280169) was enough to do the trick. It'll be available in the next MPDN Extensions release.

EDIT: v1.12.0 is now available.

It's working perfectly!!! Thanks again for everything.

[ryrynz]

It's working perfectly!!! Thanks again for everything.

Yup I had a play with it also, FYI for any files where there isn't any keyframe info it'll use the 30 second jump.

[Zachs]

Ah, madVR never made any reference it from what I saw.
That makes sense not setting it higher than the first pass (large waste of resources)
Zach, in this case would you think it would be wise to disable higher counts for the second pass?

I think you weren't looking at the right places - first pass scales one axis, second pass scales another. So if you only look at a horizontal straight line for example, you'll find the second pass to do nothing at all. Keep in mind SM5 and OpenCL versions do first and second passes in the opposite sequence.

Also could you look at the anti-ringing? I enabled it for Jinc 2D chroma @strength 0.85 and the whole image softened considerably.. something's wrong there.

I'll have a look.

[Zachs]

When you said it made the whole image considerably softer, do you mean as compared to when anti-ringing isn't enabled?
I can't see any difference at all to be honest. In fact, I'm not seeing much difference at all with anti-ringing enabled / disabled when it's used in chroma.

[aufkrawall]

Thanks for adding Jinc2D for chroma. However, it's still very soft, imho too soft for chroma.

There's a bug of deband: When strength is 1.0, there are white pixels sparkling. It disappears when using any value below 1.0.

[Zachs]

The Jinc kernel is from AviSynth's JincResize (https://github.com/AviSynth/jinc-resize/blob/master/JincResize/JincFilter.cpp) - I haven't checked but I would imagine the AviSynth Jinc to give you roughly the same results.
I think you're basing it off madVR though but its kernel isn't available for comparison so it's kind of pointless, or if it's even in fact similar to AviSynth JincResize.

[aufkrawall]

Yeah, I realize.
I think NNEDI3 will just be the way to go: not a real performance issue with 16 neurons for chroma and thanks to Shiandow's SM5.0 port, there'd be no stupid driver issues. :)

[Zachs]

FWIW, you can use other kernels with Jinc2D - it's a generic EWA scaler that will be made compatible with all the custom scalers that MPDN already supports. For example, you'll find SincBlackman (EWA version, not the current one in MPDN) to be much sharper than JincJinc (which is what Jinc2D currently is). In fact any Sinc filter (e.g. Lanczos) will give you much higher sharpness, but with more ringing as well.

[aufkrawall]

Could you elaborate what an EWA scaler is?
It's really hard to find a good chroma scaler for bad cartoon sources:
They all blur, ring or aliase. SuperChromaRes can be used as a kind of sharpening, but it can significantly make colors brighter.

Btw: MPDN still can't open 8bpp PNGs, while MPC HC with LAV can.
Not important, buy why is that so?

[ryrynz]

Could you elaborate what an EWA scaler is?


Elliptical Weighted Averaging.

http://www.imagemagick.org/discourse-server/viewtopic.php?t=25653

[Zachs]

Without going into technical details, an EWA scaler generally gives you less aliasing and produces sharper image.

I'll have a look at the 8bpp PNG problem.

[Zachs]

Hmm. I think I know what you guys are saying now about using Jinc2D in chroma and I've probably misunderstood what you were after.
As it stands, Jinc2DChroma only scales from source to luma size and has no effects in NNEDI3's chroma scaler.
That's probably why you're saying it's still soft.
To achieve this, I'll need to add a selection box to NNEDI3's config dialog to select chroma scaler.

[aufkrawall]

Elliptical Weighted Averaging.

http://www.imagemagick.org/discourse-server/viewtopic.php?t=25653
Thanks, will take a read.

Hmm. I think I know what you guys are saying now about using Jinc2D in chroma and I've probably misunderstood what you were after.
As it stands, Jinc2DChroma only scales from source to luma size and has no effects in NNEDI3's chroma scaler.
That's probably why you're saying it's still soft.
To achieve this, I'll need to add a selection box to NNEDI3's config dialog to select chroma scaler.
I really just meant scaling from source to luma.
Take a look at the flowers of the headband:
http://www7.zippyshare.com/v/Yck0L3UK/file.html
(yes, it's still the two frames-sample, but let's not be bothered by this since it doesn't affect us for this :) )
Every soft algorithm will mix up green with the pink stars (no matter if luma is upscaled afterwards or not).

And here's an example where other algorithms can introduce heavy ringing or mix up red and black:
http://www34.zippyshare.com/v/6gcCgyDm/file.html

madVR's Jinc3 AR does well in both cases, but since we don't know what it does, I think we really need to doge to NNEDI3 for chroma upscaling (which should always be best with enough neurons anyway and even with just 16 still way to go).

[Zachs]

Took a look at it and it has nothing to do with scalers. It's just a badly encoded source with chroma offset that doesn't conform to standards. MPDN follows Nev and Microsoft's advise in using a half pixel horizontal offset for MPEG2 and above sources when it hasn't provided any specifics about its chroma offset. With your source, it's encoded with zero offset but has neglected to put that information in its DXVA_ExtendedFormat structure. It was established in the past madVR uses a different scheme to determine the chroma offset but it was hardly reliable as well.

FWIW there's a hidden setting in MPDN's config file that allows you to override the default chroma offset but I wouldn't recommend changing with it since it will most likely cause problems with properly encoded sources.

[aufkrawall]

I can't evaluate this.
However, I'm still sure that NNEDI3 chroma scaling would look better.
And not only with bad cartoon sources, but also a lot more with low-res pixel-art like old games. No linear scaling algorithm will ever look good with that.

[Zachs]

I do plan to add NNEDI3 chroma scaling but it's not top priority since there isn't a convincing evidence to show that it's really that much better than just Lanczos for example.

[Zachs]

I've just committed a bunch of changes that introduces a generic EWA scaler in place of the 'old' Jinc2D scaler.
Jinc2D is still there under the new EWA scaler's config dialog but you can now also choose any of the custom linear scalers. In particular, Sinc-Blackman seems to give very sharp results that isn't too sharp while the other Sincs probably are. Then again, some people want super sharp images so you may want to have a play with it to find the optimal scaler for your eyes.

Testing this a little more and it seems these sharper scalers are very suitable as post scaler for any of the image doublers (NEDI/Super-xBR/NNEDI3).

[Zachs]

Btw: MPDN still can't open 8bpp PNGs, while MPC HC with LAV can.
Not important, buy why is that so?

You should be able to do that now with v2.39.2.

[aufkrawall]

You should be able to do that now with v2.39.2.
Yes, but now white is gray with it. Problem with transparency?

[Zachs]

Not sure. I'll look into it (low priority).

[aufkrawall]

Why is chroma scaling via render scripts only for pre-scaling luma?
Seems contradictory to luma scaling via render scripts to me, which completely replaces main MPDN's luma scalers when setting up corresponding conditional scripts.

[Zachs]

Because to make chroma scaler work as a chroma scaler for NNEDI3 would require it to work within that script (i.e. alongside it, not before or after). NNEDI3 has to explicitly support it, and the chroma scaler has to be written such that it is able to be used that way too.

In other use cases, chroma scaling in render scripts does completely replace MPDN's chroma scalers, just like scaling luma does.

[aufkrawall]

Alright, now I got it. Thanks. I'll probably stick to Sinc-Blackman 16 AR for now, it's not bad at all.