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

[aufkrawall]

Originally Posted by Zachs

Go ahead and create a request on GitHub for separate neuron settings for each pass.

*sigh*, not something a person not used to GitHub could do in three seconds, it seems?

[ryrynz]

Originally Posted by aufkrawall

*sigh*, not something a person not used to GitHub could do in three seconds, it seems?

Either he or Shiandow will get around to it, just create the request and wait. You likely won't be waiting terribly long.

[Zachs]

Originally Posted by aufkrawall

*sigh*, not something a person not used to GitHub could do in three seconds, it seems?

Well, GitHub isn't any more complicated than your typical issue tracking system.

Anyway the link is here: https://github.com/zachsaw/MPDN_Extensions/issues

[Zachs]

Originally Posted by Marnes

On a different note, will there be improvements to startup speed and such soon? I've been a big fan of mpdn for a while now because the image quality is so good, resource usage is low and the fluid motion filtering is just perfect, but I didn't realize until I installed potplayer that mpdn easily takes 5x as long to open and start playing. Even with my fast ssd, mpdn takes kinda annoyingly long to open when you're trying to go through many files. I tried to look for a replacement for fluid motion (the main reason I don't want to use other players anymore) but all that's available is interframe (haloing artifacts and different end goal) and other avisynth stuff (tedious to set up).

On x86, startup time is nearly instant on my system. For some reason, the .NET framework takes longer to start the x64 edition. The rest of the time it's to do with loading and initialising render scripts etc. Unless PotPlayer has something as sophisticated and as advanced as MPDN's features, you really can't compare the two.

[aufkrawall]

Originally Posted by Zachs

Well, GitHub isn't any more complicated than your typical issue tracking system.

Anyway the link is here: https://github.com/zachsaw/MPDN_Extensions/issues

Oops, sorry. I confused it with "pull request".
Have written an issue.

Regarding doubling/quadrupling: Yes, such scripts are very powerful, but you have to spend quite some time to get along with it. Thus a simple GUI option would be nice.

With my NNEDI3 tests, I recognized that under heavy load, the render queues sometimes don't fill up completely unless video is paused and then resumed.
Therefore, an option to fill up the queues before playing would be nice.

With default quality mode, MPDN OpenCL is even a little faster than madVR:
~13,34ms
~30% GPU usage
1126mhz

Is that "image quality" preset full 16bit like madVR?

[madshi]

FWIW, it's hard to make this a perfect apples to apples comparison. E.g. which algorithm is used by either madVR or MPDN to upscale chroma, when luma is doubled with NNEDI3? Which algorithm is used to fix the NNEDI3 pixel shift (if fixing is needed) etc. In order to get a 100% comparable situation all algorithms need to be 100% identical. Which is difficult because e.g. anti-ring filter implementations are different etc.

[aufkrawall]

I used bicubic resizing otherwise which looks "almost" completely identical and else turned everything off that can be turned off (AR filter, dithering etc.), same queue lengths etc.
But no guarantee for pixel shift correction. Anyway, the difference in GPU load is neglectable.
That reported load is not very accurate:
When I set OpenCL NNEDI3 in madVR to 128 neurons, I don't have anymore than 90% load reported, but power consumption is very high despite of this.

General question: Next year's GPUs will have much faster FP16 processing due to "mixed precision". Will this be helpful for video renderers?

[Zachs]

Originally Posted by aufkrawall

I used bicubic resizing otherwise which looks "almost" completely identical and else turned everything off that can be turned off (AR filter, dithering etc.), same queue lengths etc.
But no guarantee for pixel shift correction. Anyway, the difference in GPU load is neglectable.
That reported load is not very accurate:
When I set OpenCL NNEDI3 in madVR to 128 neurons, I don't have anymore than 90% load reported, but power consumption is very high despite of this.

General question: Next year's GPUs will have much faster FP16 processing due to "mixed precision". Will this be helpful for video renderers?

Well MPDN no longer uses FP16 - it uses 16-bit integer - for its default mode (Image Quality mode). I believe madVR also introduced it shortly after MPDN did. But I suppose if you use Render Performance / Max Render Performance modes, it might be faster... unless they also have a UNORM16 processing mode... who knows.

[aufkrawall]

Ok, I managed to make conditional render scripts do what I want them to do.
The result is NNEDI3 64 quadrupling via SM5.0 + AdaptiveSharpen after each doubling. Thanks a lot, Zachs and Shiandow!
My new favorite chroma scaler for this player is Jinc16 AR (of MPDN itself) + SuperChromaRes (1 pass, 2 strength, 0 softness).
It looks very much like Jinc AR of madVR.
So, if debanding would look better with stuff like bad news broadcasts I'd be almost totally happy with image quality.
Almost, because see the following.

Some strange observations:
MPDN D3D9 and 11 don't give equal results, with bilinear TMU scaling pixels differ (each red pixel has a different color between d3d9 and 11):

This is not the case with madVR, with it D3D9 and 11 look the same.

I also notice that MPDN is a bit darker than madVR. You can see it best at the wall behind the stairs:
MPDN D3D9:


madVR D3D9:


Settings were as much identical as they can be (dithering off, bilinear TMU etc.).

[Zachs]

That looks like a serious bug to me as I haven't encountered any difference in D3D9 / 11.
Is this with bilinear / dithering off / fluid motion off / improve chroma reconstruction off etc.? Does this happen without NNEDI3?

Could you enable dithering to see if there's any discernible colour difference? I suspect that's just a difference how the rounding is done.

[aufkrawall]

Originally Posted by Zachs

That looks like a serious bug to me as I haven't encountered any difference in D3D9 / 11.
Is this with bilinear / dithering off / fluid motion off / improve chroma reconstruction off etc.? Does this happen without NNEDI3?

Yes, all off and no NNEDI3 nor any render script active.

Originally Posted by Zachs

Could you enable dithering to see if there's any discernible colour difference?

Will do tomorrow, it's very late here.

[Zachs]

Such a serious bug would've been noticed by other users. MPDN has had dx11 for a long time now, and personally I've not encountered the problem or anyone else with that problem. Was it just that particular file?

[aufkrawall]

Wait: the red pixels just portray pixels that don't share the same color between two different pictures. I don't see a difference just with my eyes. However, there's mathematically a difference between d3d9 and 11 which shouldn't be there.
and it has nothing to do with the issue that mpdn seems slightly too dark.

[Zachs]

Oh right I thought it was showing such crazy artefacts. I'll have a look.

[madshi]

Originally Posted by Zachs

Well MPDN no longer uses FP16 - it uses 16-bit integer - for its default mode (Image Quality mode). I believe madVR also introduced it shortly after MPDN did.

Actually, madVR has been using 16bit integer as the "main" texture format for more than 5 years now.

[aufkrawall]

Took a look at the new Jinc (cylindrical):
It's softer than Jinc3 AR of madVR but shows less aliasing. The more taps, the less aliasing. Seems like it's "best" to use 8 taps with maximum AR filter strength.

[Shiandow]

Originally Posted by aufkrawall

So, if debanding would look better with stuff like bad news broadcasts I'd be almost totally happy with image quality.

To make things clear I would like to point out that there are two kinds of 'banding', which in my opinion should be treated differently.

There's the banding which is caused by rounding the image to a low bit depth, this banding is usually made somewhat 'blocky' by the image compression. This is what I usually mean when I say banding, and it is the kind of banding that the debanding filter I made is supposed to remove. And it does so quite well (even if I say so myself).

And then there's all kinds of band shaped noise that can be caused by improper handling of the image, usually by processing the image without debanding beforehand, and then quantizing the image again. A fairly common example is a gradient which misses some values, so instead of going 111222333444 it goes 111222222444. MPDN's debanding is still capable of making this slightly better, but it basically recovers the original image, which already had banding (because of the multi-staged processing).

In my opinion this latter kind is no longer just banding, since the source itself is wrong. It would be better to classify it as noise. To fix it would probably be best to use some kind of denoising filter. I suspect that a trilateral filter would fix it quite nicely. MadVR's method might even be somewhat similar to a trilateral filter, but using a denoising filter to remove banding is not generally a good idea. You run the risk that it will remove things which aren't banding (the first kind). In fact MadVR set to high indeed does remove some detail, sometimes this is just unwanted noise (as with that news broadcast), but sometimes it isn't.

[madshi]

You make it sound as if debanding caused by rounding were safe and would never remove any image detail. IMHO that's just not true, unfortunately. Of course increasing debanding strength will also increase detail loss at the same time. But from what I can see, there's no magical strength boundary, that avoids detail loss if you stay under, and suddenly introduces dramatic detail loss if you go over.

In real life there's not only rounding, but also dithering and grain which needs to be taken into account. Banded gradients often jump around a bit. It could be 1121132224223334544555 etc.

And a debanding strength knob doesn't have to be limited to only handle exact 1 step gradients or exact 2 step gradients. If you use a more complex threshold logic, you can also e.g. use a debanding strength of 1.3 steps, averaged over a larger distance.

[Shiandow]

Well of course removing rounding errors will also remove some detail, although in my experience the amount of useful detail mixed in with the rounding errors is rather low, most of it doesn't seem to survive the compression. Still in higher quality sources removing the banding might indeed mean that you also remove some detail. But still, to some extent it is possible to distinguish (possible) rounding errors from other detail, and I think a debanding filter should take that into account.

I'm not too sure what you mean by removing 1.3 step banding, the image itself contains only integer steps. Of course that doesn't mean you have to treat all '1 step bands' equally, you could always look at the context to see if it should or shouldn't be removed, and both MadVR's and MPDN's debanding do so, in their own way.

[madshi]

I mean if you look at the "bigger picture", e.g. the value difference of two pixels which have a distance of 10 pixels distance between them, they might have an integer value difference of 13. Which makes the average value difference between them 1.3, if you're inside of a big gradient. So if you look at pixels that are further apart in a large gradient, you can use any threshold you want. It doesn't have to be integer. What I'm meaning to say is that if you want to do more debanding than just 1 integer value rounding differences, the next step up doesn't necessarily have to be a step size of 2. Your original post somewhat sounded like you could only either deband 1 value steps or 2 value steps.