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

[huhn]

if i'm not mistaken the shader nnedi3 version is written by someone from MPDN a lot of different version for different ways to call openCL nnedi3 where also written by zach again if i remember correctly. it's been a couple of years...

https://github.com/mpv-player/mpv/pull/2555/files

and it's not hard to find evidence as you cna see:

* A HLSL port further modified by madshi, Shiandow and Zach Saw could be
* found at (also LGPLv3 licensed):
* https://github.com/zachsaw/MPDN_Extensions
*

and the main post of MPDN is from 2014.

beware i'm not a programmer but MPV has changed over the years and removing shaders from the project that are used fairly as open source is in my novice eyes a degradation of MPV.

[avih]

A nnedi3 port (by bjin iirc) was in mpv for few months and removed some years ago.

[edit]
nnedi3 is, AFAICT, not MPDN code. It was ported to various systems, I guess to MPDN too, and various forms are floating around (avisynth, shader forms, etc). It's possible that the MPDN authors have some lines of code which ended up in mpv, like hundreds of other people do too.

Personally, I don't think the specific nnedi3 subject has enough merit to advertise that "Both madVR and MPV use portions of code from MPDN Extensions", and even if it was, it was only the case for few months, and it's not been the case for years.

To advertise something like that, IMHO, it needs something quite a bit more substantial.

[edit2]
Actually, I'm pretty sure at least with nnedi3, mpv never contained any MPDN code. To quote bjin who wrote the code which landed (and soon later removed) in mpv:

To clarify, the reimplementation is done from scratch without taking any existing code as reference

[huhn]

@zachsaw Thanks for pointing this out. To clarify, the reimplementation is done from scratch without taking any existing code as reference. It's still unclear to me wether this could be considered as derivative work or not.

I will open another PR to add all credits.

adding the full quote makes it look quite different and the fact they are properly named in the shader.

https://github.com/mpv-player/mpv/issues/2752

What is the difference? adaptive sharpen already has been ported and super-res is the same shader from MPDN Extensions.

and that's how it should be.

[avih]

Can you please stop acting like a child? If there's MPDN code in mpv, just show me where it is in mpv.

[huhn]

excuses me?

[Zachs]

[Zachs]

Any opinions about the quality of the scaler above?

[madshi]

Looks good to me, most probably a neural network? Of course a big question will be speed. You may want to work on reducing ringing artifacts, though.

[huhn]

in the skyscraper image the the skyscraper in the top right has some patter how do patterns like this look in motion?

do i see this correctly or is the ringing very similar to super xbr 150? https://abload.de/img/tqs0adk-imgur.png_snagajqp.png

can you create an x4 image from the castle to see if this get's out of hand: https://abload.de/img/sclossr3j7e.png
i first watched this image on my HTPC and is was not properly possible to judge this image in UHD so i unscaled it using the windows picture app and it got totally out of hand at this part.
on a 1080 screen watched at native resolution it only looks odd.

[Zachs]

I haven't tested it in motion yet but the building image is probably the worst I could find. Wanted to post a mixture of good and bad ones.

What was I supposed to be looking out for in the castle photo? I haven't trained it to scale 4x so it's unreasonable to pile 2x scaler twice and judge it's quality. It's not a scaler where you can pile.

Not sure about speed yet but yes it's NN based. I guess the true test will be when I write the OpenCL code and test it on my 970 GTX.

[Zachs]

Looking closely at the ringing pattern I don't think it resembles the one you posted at all? Not sure if I'm looking at the same thing though.

[huhn]

Looking closely at the ringing pattern I don't think it resembles the one you posted at all? Not sure if I'm looking at the same thing though.

the two black bars ion the top right skyscraper are for me the part with the biggest ringing.

What was I supposed to be looking out for in the castle photo? I haven't trained it to scale 4x so it's unreasonable to pile 2x scaler twice and judge it's quality. It's not a scaler where you can pile.

but what else are you going todo if you have to scale the image further use bicubic?

i'm talking about the white vertical lines in the shadow which are very very sharp if it is scaled further it looked like it is cut there.
i make you an UHD scaled image later which get's cropped for image size reasons.

Not sure about speed yet but yes it's NN based. I guess the true test will be when I write the OpenCL code and test it on my 970 GTX.

so an advanced language like openCL is needed. i'm getting some nnedi3 flashback here and openCL clearly didn't help there in term of functionality.

[Zachs]

No. I'd be training 3x and 4x separately with different models after the 2x one is done. This is the minimum quality version that is meant to work in real time on a decent GPU. But I can't be certain until I actually write the code and test it out. OpenCL has all the functionalities I need to implement it. Just requires some grunt work and time which is very scarce for me right now.

Is the ringing acceptable though? Is it a good compromise between ringing and sharpness and details?

[huhn]

edit: this is maybe not a fair comparison because maybe one is bicubic 60 the other one bicubic 60 AR i look into it sorry.
this is the castle upscaled wiht bicubic to UHD so i have to say the ringing should be fixed:
https://abload.de/img/bicubicupscale49kna.png
here is NGU sharp x2 and bicubic to UHD cropped:
https://abload.de/img/ngubicubicupscale62jq6.png

the castle image is most likely unfair madshi really likes to use it and so NGU will just do great here. of course just an adjudicated guess.

here is one of the vertical "cut" i was talking about too it's the same bicubic upscaled image just with a marker:
https://abload.de/img/cutb1kni.png

here is the sky scraper with NGU as a comparison too:
https://abload.de/img/ngusharpuaj13.png

while your algorithm is generally sharper and that by a lot on the images i took a closer look but NGU doesn't ring.

i personally avoid image scaler that can look odd from time to time even when they are an AVG far better that's why i don't use NGU sharp. so just to be fair.

[Zachs]

Well like I said it shouldn't be upscaled with bicubic to UHD for comparison because you wouldn't stack it with anything else. If anything, you'd use the 4x upscale directly. This is purely a 2x scaler. At 2x, though, is the ringing acceptable?
It also seems to have better detail than NGU.
3x and 4x will be more expensive computationally, and the exercise here is to find out what's the cheapest way to get 2x with high enough quality.
There will be another piece for 3x and 4x respectively.

[huhn]

is pretty hard to see details on UHD if the image 920x600 but i would say yes the ringing is still obvious.

would integar NN scaling for comparison be fair?

while i can see that 2x 3x and 4x scaling fix the issue for additional scalers for resolution like 1080p 720p on an UHD screen but what are you doing about DVDs?

your implementation doesn't look as "flat" as NGU how much of this is from ringing?

[Zachs]

Ringing can contribute to some perceived sharpness so it's not all bad but inspecting the images closely reveals that NGU does remove quite a bit of details, which is likely why it appears "flat".

[huhn]

there is a reason that in my personal opinion NGU sharp should be used with the add grain feature but this is not about NGU here.

what so ever i see the ringing as a major problem in your scaler implementation.

can you maybe add an 1080p image upscaled to UHD?

[hooddy]

Originally Posted by Zachs

ANYCPU build still needs the native parts which are currently only built for x86 and x64. ARM on windows is very new and I'm not even sure if it's worth supporting seeing as the filters are probably not going to work too. Perhaps running the x86 build would work via emulation?

Ashley I'm not sure about Intel x86 emulation but I'm pretty sure WinRT devices is weak to it. There is exist port of VLC for WinRT/32 ARM (not ARM64 pubic available) but its very private and carefully hided from usual ppls (i really dunno whats the reason for this strange behavior). I'm just for populate WinOnARM/32 and freeware code for it. I read later that some part of your player uses specific cpu archs. Its sad tat your palyer wont run on ARM32. The same story with PAin.NET the lead coder wont port it for ARM32 (but yes there is port of older version tat works well on WinRT).

[hooddy]

Maybe some guys that gets sources compile ARM32 build with ANYCPU options in Visual Studio?