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

[aufkrawall]

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.


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]

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]

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.

[Shiandow]

I think I see what you mean, but those aren't really the kind of gradients that need debanding. The most obvious bands occur when the total difference is 1 over a distance of 10 or more pixels, which would make the average difference less than 0.1.

Besides in the example you gave, 10 pixels spanning a total of 13 values, there might be a difference greater than 1 between several (at least 3) of those pixels but the difference between their rounded values and their actual value is at most 1 (or 0.5 if they were always rounded to the nearest value). True you can allow a debanding filter to change the value of a pixel by more than 1, but in my opinion that means you've started to remove noise and not just banding.

FWIW the current versions of my debanding script use statistical properties to try to distinguish between rounding errors and detail, which essentially make it impossible to simply allow it to remove slightly more 'noise'. This is a limitation that is caused by designing an algorithm specifically to remove rounding errors. If you used a general denoiser at a very low strength you should be able to simply dial up the strength to remove more noise, but those algorithm have the disadvantage that they're not as good at distinguishing between rounding errors and detail, so you might need to remove more detail in order to remove all banding.

What I'm trying to say is that both type of algorithms have their uses, but they do different things. Trying to use a debander to remove noise or a denoiser to remove banding might work but the result will be far from perfect.

[aufkrawall]

I'd be very grateful for a denoise-checkbox in your algorithm though. :o

[aufkrawall]

Ok, D3D9 and 11 look identical now (I also tested render scripts).

MPDN still looks different to madVR with colors. MPDN is a bit closer to EVR CP of MPC HC, but they are different though.

MPDN:
http://abload.de/thumb/mpdndx117aj0f.png (http://abload.de/image.php?img=mpdndx117aj0f.png)

madVR:
http://abload.de/thumb/madvrfokzs.png (http://abload.de/image.php?img=madvrfokzs.png)

EVR CP of MPC HC (ignore chroma scaling and just look at the wall behind the stairs):
http://abload.de/thumb/evrcpouk7n.png (http://abload.de/image.php?img=evrcpouk7n.png)

Royal question: Who is right? madVR is known to be suitable for exact calibration. However, this doesn't have to be a guarantee.
What's the experts' opinion?

Edit: There is also a huge difference with the brown-orange carpet.
EVR-sync looks very close to madVR:
http://abload.de/thumb/evrsyncezzuc.png (http://abload.de/image.php?img=evrsyncezzuc.png)

[ryrynz]

MPDN still looks different to madVR with colors. MPDN is a bit closer to EVR CP of MPC HC, but they are different though.


There are pixel details in the MPDN image that are simply not there with madVR, that makes me think the resizer (bicubic?) being used for madVR is slightly less sharp. Fairly small differences though at the end of the day.

A few edges and areas there with reasonable differences which would be still hard to notice, but there's generally a 1/1/1 or 2/2/2 difference which wouldn't be noticeable.
I do favor the MPDN image here up close simply because of the pixel detail. Would it make a shred of difference while watching video, nope. Would be interesting to see a slightly sharper madVR upscaler for comparison.

[Zachs]

On my monitor, I really can't see any difference between EVR and MPDN. To rule out any rounding differences, try enabling dithering and see if you find the difference smaller.
As I understand it (correct me if I'm wrong), calibration needs to be done for a specific renderer, doesn't it?

[ryrynz]

What was the deal with the d3d11 color difference (re latest update)?

[Zachs]

It was actually just a tiny pixel shift in dx10/11 mode. Not something you can see with your naked eyes.

[huhn]

On my monitor, I really can't see any difference between EVR and MPDN. To rule out any rounding differences, try enabling dithering and see if you find the difference smaller.
As I understand it (correct me if I'm wrong), calibration needs to be done for a specific renderer, doesn't it?

no it doesn't. a normal calibration is done using the CMS from a TV and it has to work with every renderer/source.

3d is an exception most people on earth don't care about 3D anyway.

[madshi]

True you can allow a debanding filter to change the value of a pixel by more than 1, but in my opinion that means you've started to remove noise and not just banding.

FWIW the current versions of my debanding script use statistical properties to try to distinguish between rounding errors and detail, which essentially make it impossible to simply allow it to remove slightly more 'noise'. This is a limitation that is caused by designing an algorithm specifically to remove rounding errors. If you used a general denoiser at a very low strength you should be able to simply dial up the strength to remove more noise, but those algorithm have the disadvantage that they're not as good at distinguishing between rounding errors and detail, so you might need to remove more detail in order to remove all banding.

What I'm trying to say is that both type of algorithms have their uses, but they do different things. Trying to use a debander to remove noise or a denoiser to remove banding might work but the result will be far from perfect.
I think we're almost in philisophical land now. Your definition of banding and debanding seems to be slightly different to mine. Yours seems to be "banding = max 1 integer steps caused by rounding". Mine is more like "visible step lines in gradients that are not supposed to be there". Consequently, your ideal debanding algorithm would never remove more than rounding errors, while mine might, if the source seems to need it. I don't think madVR's debanding filter can be labeled "denoise", in any case. It's overall design is very much targetted at making gradients smoother and nothing else, which is unlike what any "noise reducer" would do. Also I would classify "noise" to be somewhat randomly distributed dots. Which is very different to banding.

MPDN still looks different to madVR with colors. MPDN is a bit closer to EVR CP of MPC HC, but they are different though.

Royal question: Who is right? madVR is known to be suitable for exact calibration. However, this doesn't have to be a guarantee.
What's the experts' opinion?
Might be as easy as a case of different matrix/primaries guesses. Which matrix and primaries have MPDN, EVR and madVR been using in your screenshots?

As I understand it (correct me if I'm wrong), calibration needs to be done for a specific renderer, doesn't it?
Ideally, every render would produce exactly the same (= correct) colors. If that were true, one calibration should suffice for all renderers. In real life things are not always as perfect. There are even standalone Blu-Ray players which produce slightly different colors. So sometimes in real life a calibration needs to be done per source device (or renderer). But of course that's not how it should be, in an ideal world.

[aufkrawall]

There are pixel details in the MPDN image that are simply not there with madVR, that makes me think the resizer (bicubic?) being used for madVR is slightly less sharp. Fairly small differences though at the end of the day.

It's both bilinear scaling via TMUs for comparison's sake.
What I notice, apart from that slight color difference, is that below the headband of the girl, there's a green square with madVR which isn't there with MPDN.
Most interesting is that it's always there with madVR and never with MPDN, no matter which scaling algorithm is used. :confused:


A few edges and areas there with reasonable differences which would be still hard to notice, but there's generally a 1/1/1 or 2/2/2 difference which wouldn't be noticeable.
I do favor the MPDN image here up close simply because of the pixel detail. Would it make a shred of difference while watching video, nope. Would be interesting to see a slightly sharper madVR upscaler for comparison.
We shouldn't compare image quality by single pixels with the pictures above since it's just bilinear TMU.
With NNEDI3 quadrupling via OpenCL there's not a real difference either, apart from colors.

On my monitor, I really can't see any difference between EVR and MPDN. To rule out any rounding differences, try enabling dithering and see if you find the difference smaller.

The difference is still there with dithering (both random).
The difference between EVR CP and MPDN is veery small, but it's there. I just checked in a dimmed room. However, since it's so small, it could be related to chroma upscaling.
This could also apply to madVR and EVR-sync. We could say we have to groups here: EVR-CP and MPDN on the one side and madVR and EVR-sync on the other one.


Might be as easy as a case of different matrix/primaries guesses. Which matrix and primaries have MPDN, EVR and madVR been using in your screenshots?

Both MPDN and madVR report BT.709, but madVR detects TV levels as input (information by upstream) while MPDN reports full range (not clear if it's meant for input or output).
Edit: Ok, I think it's surely meant for output.

Here's the sample again:
http://www20.zippyshare.com/v/0K5ArS12/file.html


Btw: MPDN doesn't accept PNGs with 8BPP whie it has no problems with 24BPP.
8BPP: http://www20.zippyshare.com/v/niiU7x21/file.html
24BPP: http://www20.zippyshare.com/v/USMxFxEL/file.html

[madshi]

What I notice, apart from that slight color difference, is that below the headband of the girl, there's a green square with madVR which isn't there with MPDN.
Most interesting is that it's always there with madVR and never with MPDN, no matter which scaling algorithm is used. :confused:
It seems there are actually 2 frames in that file. madVR shows the first, MPDN the 2nd. You can see that madVR has a decoder queue of 2/2.

[aufkrawall]

oh my, you nailed it..
Thank you, madshi!

I need to take a look again at Handbrake's kind of frame counting. It may work a bit (or a frame?) different than avs trim... :o

[huhn]

MPDN nnedi3 openCL doesn't work as madVr openCL nnedi 3 doesn't work.

Zachs does your openCL nnedi3 version use cl_nv_d3d9_sharing?

because it looks like this isn't part of newer drivers anymore.

[Zachs]

They better bring it back. I don't see a reason why they need to remove it especially when all their earlier Win10 drivers have it. Maybe they feel they have such a lead in the market place they're giving AMD a chance to catch up? :)

EDIT: All jokes aside, unless they've implemented the KHR methods, they've just shot themselves in the foot by crippling their own products. Can you check if the corresponding KHR extensions are now part of their new drivers? You can dump all the OpenCL extensions with GPU Caps Viewer.

[Zachs]

Btw: MPDN doesn't accept PNGs with 8BPP whie it has no problems with 24BPP.
8BPP: http://www20.zippyshare.com/v/niiU7x21/file.html
24BPP: http://www20.zippyshare.com/v/USMxFxEL/file.html

LAV is responsible for "not accepting" it. MPDN doesn't decode media files.

[huhn]

They better bring it back. I don't see a reason why they need to remove it especially when all their earlier Win10 drivers have it. Maybe they feel they have such a lead in the market place they're giving AMD a chance to catch up? :)

i hope they just removed it by accident. and yes it is very sad that AMD doesn't deliver at the moment...

[Zachs]

It could very well be that they have finally implemented the Khronos ones so they removed their equivalent NV extensions. Could you quickly dump the OpenCL extensions of their new drivers please?

[huhn]

LAV is responsible for "not accepting" it. MPDN doesn't decode media files.

and why does the lavfilter in MPC-HC handle this 8 bit png?

[huhn]

It could very well be that they have finally implemented the Khronos ones so they removed their equivalent NV extensions. Could you quickly dump the OpenCL extensions of their new drivers please?

i did this already with gpu cap and no they didn't.

couldn't the Khronos api version the reason for the copyback issue with AMD? so not sure if this is a good idea...

thsi whole topic is a mystery for me any way. according to this source: https://anteru.net/2012/10/30/1998/

cl_khr_d3d10_sharing is a 1:1 copy from cl_nv_d3d10_sharing. nvidia has both version with should be 100 % the same and doesn't make any sense to me but what ever.

[madshi]

The Khronos API version is *not* responsible for the copyback issue. Intel GPUs use the Khronos API and don't have any copyback issues. The D3D9 version of Khronos differs quite noticeably from the NV version.

[huhn]

wasn't it "ok" to do copyback with the openCL khronos extension. which makes the amd copyback issue not a "bug".

[Zachs]

Yeah the Khronos group didn't mandate the need to do interop without a copyback so it's not technically a bug, but that doesn't mean it isn't a problem.
Anyway until Nvidia brings back their interop extension, you'll have to use the shader version of NNEDI3. On my Kepler, the OpenCL version is a fair bit faster. Fermi is the other way around... Go figure.

[Zachs]

Dear devs,

The latest code check-in on GitHub is meant for v2.39.0 (available as test build only at the moment), which unfortunately has some breaking changes to the extensions API due to the introduction of ScalerTaps.Two.

Hardware scalers have also been removed and nearest neighbour / bilinear now works properly when used as a downscaler - i.e. they are 1-tap box and 2-tap triangular filters respectively.
The new nearest neighbour downscaler should be around the same quality as the old hardware bilinear (and non hardware bilinear) when downscaling by a small amount but it should give much better quality at larger downscale factors (but it's still just a box filter at the end of the day). You may find the new bilinear to be adequate in most cases without the need to go to Bicubic even.

Anyway if anyone wants to have a play with it besides the devs, feel free to download the test build from http://mpdn.zachsaw.com/Test%20Builds/3220/. If you encounter any problems, please report them here. Do note however that if you want to use it with extensions, you'll have to use the latest source from GitHub.

Cheers.

[aufkrawall]

How can I use SuperRes after each doubling when using NNEDI3 quadrupling?
I have two conditional scripts in a row set up for quadrupling:

if SourceSize.Width < 1280 and SourceSize.Height < 720 and NeedsUpscaling
-> use NNEDI3 + Image Processor
if SourceSize.Width <= 1600 and SourceSize.Height <= 900 and NeedsUpscaling
-> use NNEDI3 + Image Processor

If I simply replace NNEDI3 in these two scripts with SuperRes (each with NNEDI3 as prescaler), I seem to end up with only NNEDI3 doubling instead of quadrupling. :confused:

[Shiandow]

As of now that's not possible since SuperRes always scales to the screen size. There are also some subtleties when you use SuperRes multiple times like that since it's best for SuperRes to know that the original image was, which it won't if you simply use it after the image has been doubled.

For now it's best to just use the NNEDI3 quadrupler as a prescaler for SuperRes.

[aufkrawall]

Ok, :thanks: .

[Anima123]

Dear devs,
The new nearest neighbour downscaler should be around the same quality as the old hardware bilinear (and non hardware bilinear) when downscaling by a small amount but it should give much better quality at larger downscale factors (but it's still just a box filter at the end of the day). You may find the new bilinear to be adequate in most cases without the need to go to Bicubic even.

Cheers.

Does the new scalers would be of any benefit together with SuperRes in the future versions, where bilinear played a role in downscaling 2x scaled image to the original size?

[Zachs]

It should already have an effect. You should try it out. Feedback's always appreciated as usual.

[ryrynz]

BTW, while we're on the subject, has anyone noticed the SM5 NNEDI3 is now around 10% faster with the same neurons vs OpenCL with the recent Nvidia drivers? At least on my Fermi cards, it was neck and neck (with SM5 just a touch faster) when we first implemented it. We haven't updated the NNEDI3 code and the only thing that's changed would've been the drivers. Just wondering if anyone's noticed the speed improvements.

My 750Ti can do 256 neurons at 720 x 480 x 24FPS now.. It's pretty much at it's limit though.

D3D9, with hardware bilinear chroma and luma no SM or FM and no dithering on a 720x480 24 FPS file using NNEDI3 on OpenCL with a target resolution of 1920 x 1080


MPDN

Neurons Rendering time GPU %
16 10.6 15%
32 13.3 20%
64 17.8 30%
128 23.7 53%
256 39.6 91%

madVR

Neurons Rendering time GPU %
16 10.4 12%
32 13.1 18%
64 17.7 31%
128 25.6 57%
256 43.7 96% ~Frame drops~

[Zachs]

Speaking of NNEDI3, I've just checked in some codes that allow you to select different neuron count for each pass.
First pass is definitely much more important than second as the second relies on the first.
Go have a play. :)

[aufkrawall]

Zachs, MPDN often crashes with this error when I change lots of settings in a row, e.g. when comparing scaling results:
http://abload.de/img/mpdncrashb1ler.png (http://abload.de/image.php?img=mpdncrashb1ler.png)
Sometimes the player also becomes sluggish before this when switching between fullscreen several times (non-FSE).

Furthermore, the dialog to add shaders to image processor can't be reached if media is opened in the player, it then opens somwhere in the background or so and can't be pulled to the foreground.
The player must be terminated because it locks itself out.

[ryrynz]

Good thing there's two NNEDI3 versions.. Since Nvidias w10 driver kills openCL compatibility ATM with no ETA on the fix.

[Zachs]

Zachs, MPDN often crashes with this error when I change lots of settings in a row, e.g. when comparing scaling results:
http://abload.de/img/mpdncrashb1ler.png (http://abload.de/image.php?img=mpdncrashb1ler.png)
Sometimes the player also becomes sluggish before this when switching between fullscreen several times (non-FSE).

Furthermore, the dialog to add shaders to image processor can't be reached if media is opened in the player, it then opens somwhere in the background or so and can't be pulled to the foreground.
The player must be terminated because it locks itself out.

This error message is from the CLR (i.e. .NET runtime) and indicates a serious problem in the runtime. First thing that comes to mind is that there's a memory corruption that has affected the runtime. It could be caused by a number of things though... even a GPU driver can cause that since they run mostly in user mode now.

[Zachs]

Good thing there's two NNEDI3 versions.. Since Nvidias w10 driver kills openCL compatibility ATM with no ETA on the fix.

Have they even said they're going to fix it?

[aufkrawall]

They may bring it back or not, we have not been told yet:
https://forums.geforce.com/default/topic/860152/geforce-drivers/official-windows-10-353-62-game-ready-display-driver-feedback-thread-7-29-15-/post/4618371/#4618371

And SM5.0 NNEDI3 is still working well here. :cool:

This error message is from the CLR (i.e. .NET runtime) and indicates a serious problem in the runtime. First thing that comes to mind is that there's a memory corruption that has affected the runtime. It could be caused by a number of things though... even a GPU driver can cause that since they run mostly in user mode now.
It happens out of nowhere while I'm in the settings dialog, mostly of render scripts.

[ryrynz]

They may bring it back or not, we have not been told yet
And SM5.0 NNEDI3 is still working well here. :cool:


Yeah real shame after I posted those glorious openCL NNEDI3 results.

[Zachs]

Is it actually possible to run 353.49 Hotfix drivers under Windows 10? I heard they force the latest one on you via Windows Update. I wonder what would happen if you are running a beta driver that is newer than what Windows Update has...

[huhn]

you can run 353.49 and you can disable the update. it's not true that you can't stop updates.

[ryrynz]

you can run 353.49 and you can disable the update. it's not true that you can't stop updates.

Confirmed 343.59 fixes OpenCL. Huhn you might wanna let people know about this on the madVR forum, also mention the device installation settings option to disable auto updating from Windows Update.

[Zachs]

Uh detailed instructions on how to disabled windows update for GPU drivers would be nice... :)