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

[Zachs]

I've moved the source to Bitbucket. Can you please PM your email address to me please?

And happy new year everyone!!!

[Zachs]

Shiandow, I'll need to add you to the new repo on Bitbucket too. You may have to create a branch and cherry pick your commits.

[patul]

I'd be interested in seeing MPDN continue. Not sure if I have the time/skill to be a full time maintainer but more than willing to contribute some of my time and even resources (can probably offer hosting space for binaries on my server and domain) to keep things going.
Would be a real shame if MPDN were to die.

Also, a bit early but happy new year to everyone!

+1. It would be real shame if this wonderful player is no longer developed. Personally, I've been using MPDN since very beginning, and have been following this thread since its early days, hence I would like to see some capable hands will take up and continue the development.

Good to see we have a volunteer already.

Happy new year!

[Shiandow]

Happy new year to everyone!

This sure is a nice way to kick off the new year. Should people be interested in developing it's probably good to know I have managed to extract the UI from the rest of the player logic, that should make it easier to at least make something that looks like MPDN :) but it should also help make some sense of the part that remains.

If anyone's interested in adding HDR support I also have a few pixel shaders that add at least some rudimentary support for HDR images, but they need some tinkering to make sure they get the right parameters from the video (unless you're willing to adjust them manually on the fly, but that's probably just me...)

[Zachs]

Happy new year Shiandow! Can you PM me your Bitbucket email address? I've moved the repo there because it's free for up to 5 devs.

[Zachs]

I'm pretty sure everyone would love to have HDR support! :)

[huhn]

If anyone's interested in adding HDR support I also have a few pixel shaders that add at least some rudimentary support for HDR images, but they need some tinkering to make sure they get the right parameters from the video (unless you're willing to adjust them manually on the fly, but that's probably just me...)

how about running an synthetic created 3D LUT with HDR-SDR conversation at it for know.

the current 3D LUt is broken and very easy to fix (full range -> limited range, 3D LUT, limited range full range conversation).

it's a waste in processing power but what can you do 3d LUT are limited range end of story.

it even kind of works already.
running an 3D LUt with a limited to full range conversation after it looks similar(on a fast view exactly the same to me) to me compared to madVR running with the same HDR->SDR 3D LUT.

so take the best you can get and displaycal developer clearly know what they are doing.

[Zachs]

Last 2 spots available to any potential MPDN Devs.

[Zachs]

If anyone's interested in adding HDR support I also have a few pixel shaders that add at least some rudimentary support for HDR images, but they need some tinkering to make sure they get the right parameters from the video (unless you're willing to adjust them manually on the fly, but that's probably just me...)

Don't we already provide the render scripts with parameters from the video?

[Shiandow]

Don't we already provide the render scripts with parameters from the video?

Don't think we provide any HDR paramaters yet.

It would also be nice if we could figure out a way to make the video parameters extendable, rather than hard coded into the application, but I'm getting ahead of myself.

[Zachs]

That's not entirely impossible. A string dictionary would do the job. The thing is I'm not sure where that HDR info is coming from.

[Shiandow]

A string dictionary would work, but it would be nicer if you could somehow request information by C# interface.

[Zachs]

Any idea where that information comes from? We can decide how to pass that info to the scripts once we know where to get it from.

The thing with interfaces is they must be defined at compile time. I was thinking of something that would allow us to grab all info regardless of how useful they are and dump them into a dictionary. It's the scripts that will decide how useful the info is.

[Zachs]

Or do you mean COM interface? The metadata usually comes from it.

[Shiandow]

No I meant something similar to:



IHDRParameters hdr_params = video.info as IHDRParameters;



although in practice you might end up with something closer to:



IHDRParameters hdr_params = video.requestInfo<IHDRParameters>();



which some other extension providing video information that implements IHDRParameters.

Sure the interfaces need to be known at compile time, but that's no different from needing to know the parameter names that the information would otherwise be in.

I might be overcomplicating things though, it's just that this would prevent a lot of guesswork when reading the parameters.

[nevcairiel]

The thing is I'm not sure where that HDR info is coming from.

From here:
https://github.com/Nevcairiel/LAVFilters/blob/master/developer_info/IMediaSideData.h

Note that if you provide a custom allocator (which renderers typically do), you'll need to make sure the IMediaSamples it allocates actually implement the IMediaSideData interface.

[Zachs]

Cheers Nev

[Zachs]

Nev, do we need to copy and cache pData in STDMETHOD(SetSideData)(GUID guidType, const BYTE *pData, size_t size) PURE;
or can we simply hold the pointer and size to pData and expect pData to be valid throughout the lifetime of the IMediaSample?

[nevcairiel]

You need to copy and save it. The caller of SetSideData has no clue about the ultimate lifetime of the object, since its reference counted.

[Zachs]

Thanks Nev.

[Zachs]

We can't seem to get assfiltermod to call ISubRenderConsumer.Connect. Xysubfilter on the other hand has no problems doing so. :(

Nevermind. Found the problem after reading the source code of assfiltermod - it's expecting the consumer to implement ISubRenderConsumer2. IMHO it should be checking for ISubRenderConsumer interface, not ISubRenderConsumer2.

[huhn]

interesting it just worked out of the box with madVR. madshi didn't even know this renderer was a thing.
that'S the spec if i'm not mistaken:
http://madshi.net/SubRenderIntf.h

[Zachs]

The documentation isn't ambiguous but it was misinterpreted by assfiltermod's author.

MPDN didn't need the Clear method so did not implement the ISubRenderConsumer2 interface. Assfiltermod however only looks for that interface, when the Connect method actually belongs to the ISubRenderConsumer interface.

[Metal-HTPC]

This is by far the greatest player I ever tested. Never got MPC-HC or BE to work properly with madVR.
MPDN has all the usefull settings already integrated and works very stable. The playback is the best possible in my setup.

The only thing I'm missing is a way to play my DVD's. Is there an addon somewhere which makes VIDEO_TS folder playback including menus etc possible ?

I archived my whole music DVD collection in the regular dvd format (VTS/VOB files) and most of those shows will most likely never see a Blu-ray release.

thanks in adavnce for your help
regards

[Shiandow]

Not sure if the VTS files will work since DVD menus are not supported (and will probably remain unsupported for the near future). I'm pretty sure that the LAV filters should be able to handle the VOB files though, so those should work.

[avih]

Hi everyone,
... Both madVR and MPV use portions of code from MPDN Extensions.


Would you mind pointing out some MPDN extensions which are used in mpv (and the mpv code which uses things from MPDN)? I'm somewhat familiar with mpv code, and I don't recall anything which came from MPDN...

[huhn]

here you go: https://gist.github.com/igv
these are the easy ones even i can find.

[avih]

here you go: https://gist.github.com/igv
these are the easy ones even i can find.

But this is not mpv using anything from MPDN. These are shaders which presumably can work in mpv when loaded as external shaders.

It's like I'll write some JS code which can run in Firefox and then advertise/claim that Firefox is using my code...

[huhn]

aren't or at least wasn't they shipped with mpv builds?

[avih]

aren't or at least wasn't they shipped with mpv builds?

Surely not with the official windows distribution at https://mpv.srsfckn.biz/ .

If you or some other third party wants to distribute an mpv build with a collection of shaders from MPDN, you can do that, but it cannot be considered part of mpv itself...

[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 (https://github.com/mpv-player/mpv/issues/2230#issuecomment-161190654) 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]

http://madshi.net/clown.png
https://imgur.com/download/CDKoAYw
https://imgur.com/download/PfaOev4
https://imgur.com/download/1jmlV63
https://imgur.com/download/0SVl9wx
https://imgur.com/download/Vy90l8M
https://imgur.com/download/3yT2Sym
https://imgur.com/download/b6N5jiE
https://imgur.com/download/Tqs0AdK
https://imgur.com/download/yQwNpb9
https://imgur.com/download/IUrJe5c
https://imgur.com/download/FSRFots
https://imgur.com/download/tlc2cpV
https://imgur.com/download/jzGNF3N

[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]

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?