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

[Zachs]

Originally Posted by toniash

Could you create a script with Lumasharpen on top of NEDI?

This will be possible with the next version of MPDN where you can stack multiple render scripts.

[toniash]

Originally Posted by Zachs

This will be possible with the next version of MPDN where you can stack multiple render scripts.

Thanks!
Would it be possible to overscale(over device resolution) + sharpen + downscale(to device resolution) ??

[Zachs]

Originally Posted by toniash

Thanks!
Would it be possible to overscale(over device resolution) + sharpen + downscale(to device resolution) ??

That will depend on the specific render script. There's no restriction for creating such a script. If you mean Nedi specifically you'll have to ask Shiandow. But I believe the Nedi algo allows for such an implementation.

[Shiandow]

Originally Posted by Zachs

Amazing job Shiandow! (btw, this is without superres too right?)

Thanks, yes this is still without SuperRes, I will probably implement that one as well but there are some things that I will want to try out that have now become possible, so it will take some more time.

Too bad it doesn't seem to work in some cases, hopefully it will become clear why this happens soon.

By the way I've made some slight changes to Filter.cs that now make it possible to prevent textures from being allocated unnecessarily. So now NEDI renders directly onto the output texture if it doesn't need to rescale. I've updated NEDIRenderScript.rar to include these changes.

[Shiandow]

Originally Posted by toniash

Would it be possible to overscale(over device resolution) + sharpen + downscale(to device resolution) ??

That would be possible, although with the current interface render scripts are forced to a specific output size, which makes this harder. You could make a sharpening filter which requires the input to be double the video size, and use that one after NEDI, but I'm not sure if that is the best solution.

[Zachs]

Originally Posted by Shiandow

That would be possible, although with the current interface render scripts are forced to a specific output size, which makes this harder. You could make a sharpening filter which requires the input to be double the video size, and use that one after NEDI, but I'm not sure if that is the best solution.

Wouldn't it be possible to overscale using an intermediate ITexture and then output to the final size? i.e. The final chained filter would have an over sized texture. This then gets blitted to the size forced output target. I could definitely allow arbitrary output size but following that I would need to scale it to the size of the display window anyway. What I'm doing with the render script interface is I'm allowing scripts to determine how to scale this to the target window. What it currently lacks is a scale function to get MPDN to do the final scaling. Or is there something I'm missing here?

[Shiandow]

Originally Posted by Zachs

Wouldn't it be possible to overscale using an intermediate ITexture and then output to the final size? i.e. The final chained filter would have an over sized texture. This then gets blitted to the size forced output target. I could definitely allow arbitrary output size but following that I would need to scale it to the size of the display window anyway. What I'm doing with the render script interface is I'm allowing scripts to determine how to scale this to the target window. What it currently lacks is a scale function to get MPDN to do the final scaling. Or is there something I'm missing here?

Welll if the output size of NEDI is fixed then I'd have to do the downscaling in the NEDI script itself. So you can't simply do something like NEDI -> sharpening -> downscaling, without changing the script.

[Zachs]

Originally Posted by Shiandow

Thanks, yes this is still without SuperRes, I will probably implement that one as well but there are some things that I will want to try out that have now become possible, so it will take some more time.

Too bad it doesn't seem to work in some cases, hopefully it will become clear why this happens soon.

By the way I've made some slight changes to Filter.cs that now make it possible to prevent textures from being allocated unnecessarily. So now NEDI renders directly onto the output texture if it doesn't need to rescale. I've updated NEDIRenderScript.rar to include these changes.

I'll be testing render script on an AMD card as soon as I have access to one. It would appear that all of those affected are running AMD cards. This may take some time as it usually means I have to come up with a workaround for one specific vendor.

I'm thinking of just including filter.cs as part of MPDN's standard distribution if you haven't got any objections?

[Zachs]

Originally Posted by Shiandow

Welll if the output size of NEDI is fixed then I'd have to do the downscaling in the NEDI script itself. So you can't simply do something like NEDI -> sharpening -> downscaling, without changing the script.

I get it now.
But it's definitely possible to do (NEDI -> downscaled to target size) -> sharpening in the next version of MPDN. If a script needs implicit sharpening before downscaling to target size, that would need to be done in the script itself. But I don't believe that's what most users were asking for. What they wanted was (correct me if I'm wrong) to sharpen Luma after it's been scaled to display window size.

Otherwise, I'm open to suggestions as to how we could allow a script to define both input and output sizes and still chain them together.

e.g.
Script 1: input size X, output size Y
Script 2: input size Z, output size W

In other words, how should MPDN deal with Y -> Z scaling when user puts script1 and script2 stacked up in that order?

[Shiandow]

Originally Posted by Zachs

I'm thinking of just including filter.cs as part of MPDN's standard distribution if you haven't got any objections?

No, please do. I think it might also be beneficial to change the render script interface somewhat. For instance, adding an InputFilter to IRenderer.

I think it would also greatly simplify the chaining of render scripts if you force render scripts to expose a filter. If you don't change the way "OutputSize" works for Filters then this would also add a way of allowing Filters to control their own output size. Unfortunately Filters can't currently be trusted to always return the correct output size, so you may have to do something about that.

[Shiandow]

Originally Posted by Zachs

I get it now.
But it's definitely possible to do (NEDI -> downscaled to target size) -> sharpening in the next version of MPDN. If a script needs implicit sharpening before downscaling to target size, that would need to be done in the script itself. But I don't believe that's what most users were asking for. What they wanted was (correct me if I'm wrong) to sharpen Luma after it's been scaled to display window size.

Otherwise, I'm open to suggestions as to how we could allow a script to define both input and output sizes and still chain them together.

e.g.
Script 1: input size X, output size Y
Script 2: input size Z, output size W

In other words, how should MPDN deal with Y -> Z scaling when user puts script1 and script2 stacked up in that order?

Well toniash was asking specifically if it would be possible to add sharpening on the overscaled image.

Anyway when you have scripts where the sizes don't match then obvious thing to do is to have MPDN scale the result of script1 to the wanted input size of script2. If you implemented this then you could have something like:

X --NEDI--> 2X --Auto Scaling--> Y

But if you added a sharpening algorithm (which always keeps the size the same), then it would become:

X --NEDI--> 2X --Sharpening--> 2X --Auto Scaling--> Y

Of course you could make the sharpening even more complicated and have it to choose as input size either 2X or Y, whichever is greater.

[Zachs]

Originally Posted by Shiandow

No, please do. I think it might also be beneficial to change the render script interface somewhat. For instance, adding an InputFilter to IRenderer.

I think it would also greatly simplify the chaining of render scripts if you force render scripts to expose a filter. If you don't change the way "OutputSize" works for Filters then this would also add a way of allowing Filters to control their own output size. Unfortunately Filters can't currently be trusted to always return the correct output size, so you may have to do something about that.

I think I see what you're saying now.
If render scripts are forced to expose IFilter interface, then MPDN's job would be much simpler - simply chain all filters together and call Render!
Each script could then have 1 Filter, or multiple filters chained.

At the very end of the chain, the last IFilter still needs to scale it to target size doesn't it?

EDIT: You've just answered it in the post above this one

I'll have a think about your method. It's definitely much more flexible than my original idea of stacking render scripts which I've already implemented but that could easily be undone.

EDIT#2:

Question. How would you let the Filter ask for a specific Input size then? Such as what NEDI is doing via InputDescriptor.Size? Another auto-scale? Those auto-scales that get added in automatically may actually degrade image quality and cost a lot of GPU time?

[Shiandow]

You may want to change the implementation of OutputSize somewhat, It's currently somewhat fickle. Basically if you ask the script what it's OutputSize is then it will simply return whatever size it wants, and setting the output size may or may not have an effect. I'm don't think this is going to work too well in more complicated cases.

[Shiandow]

Originally Posted by Zachs

EDIT#2:

Question. How would you let the Filter ask for a specific Input size then? Such as what NEDI is doing via InputDescriptor.Size? Another auto-scale? Those auto-scales that get added in automatically may actually degrade image quality and cost a lot of GPU time?

Yeah, it's probably not a good idea to let render scripts return arbitrary filters. I'm also wondering if it was a good idea to allow OutputSize to be set for Filters, the fact that it may fail silently is very annoying.

Perhaps it's best if you create a more restricted class RenderFilter which has a property InputSize and allows you to set a TargetSize. Perhaps also force it to make it's OutputSize equal to TargetSize.

You could then easily create a RenderFilter from a GenericFilter by adding a scaler to the GenericFilter output.

I think it's best if I create an example of this for the NEDIFilter, shouldn't take too long.

[Zachs]

Originally Posted by Shiandow

Yeah, it's probably not a good idea to let render scripts return arbitrary filters. I'm also wondering if it was a good idea to allow OutputSize to be set for Filters, the fact that it may fail silently is very annoying.

Perhaps it's best if you create a more restricted class RenderFilter which has a property InputSize and allows you to set a TargetSize. Perhaps also force it to make it's OutputSize equal to TargetSize.

You could then easily create a RenderFilter from a GenericFilter by adding a scaler to the GenericFilter output.

I think it's best if I create an example of this for the NEDIFilter, shouldn't take too long.

That'll be great if you could.

I'll take a look at it tomorrow!

[fairchild]

I downloaded the NEDIRenderScripts.rar timestamped 10-26-14 and I still get a black screen when changing the default resolution of any video. I am using the latest official 14.9 drivers on my AMD 7870.

[Shiandow]

Originally Posted by fairchild

I downloaded the NEDIRenderScripts.rar timestamped 10-26-14 and I still get a black screen when changing the default resolution of any video. I am using the latest official 14.9 drivers on my AMD 7870.

Unfortunately that hasn't been solved yet. It seems to be a problem with all AMDs. As far as I have been able to figure out there's not much I can do to make NEDI work on AMDs. Zachs will have to figure out what exactly goes wrong.

Originally Posted by Zachs

That'll be great if you could.

I'll take a look at it tomorrow!

Well turns out that it didn't go exactly as I had thought, but I think I succeeded anyway. The gist of it is that there is now a class "ResizeableFilter". This class promises to resize everything to a specified TargetSize, but if TargetSize is not specified it should try to do nothing. This TargetSize is allowed to reset after every Render, to avoid unnecessary scaling (I'm not sure if this is best, but you should update the TargetSize every Render anyway).

You can make an arbitrary Filter into a ResizeableFilter using a scaler. I've currently implemented a simple HW linear scaler which could be replaced with MPDN's scaling algorithms. Anyway the resulting code is simply: "new Scaler(Filter)". I'm not entirely happy with the names, so feel free to change them. This also holds for most of the other code I wrote.

The idea then is to have each RenderScript expose a method: CreateFilter, which has as input some ResizeableFilter and should return a Filter (I'm not sure if this filter should be a ResizeableFilter as well or if MPDN should take care of this conversion when necessary). Anyway, this allows you to assume the Input is a ResizeableFilter if you want to, but this can also be ignored (If so then the Scaler Filter should try to do nothing).

Currently this method adds an annoying unnecessary Scaler to InputTexture, but that shouldn't be the case after defining an InputFilter. Since, as far as I can tell, it should be possible to package the process that you currently use to create InputTexture into a ResizeableFilter.

Than all that remains to chain the render scripts is to call CreateFilter for each one.

Edit: Still taking care of some final bugs.
Edit2: Bugs are fixed now; for some reason rendering a texture to another texture of the same size using linear scaling doesn't simply copy the Texture.
Edit3: Some changes to the Filter definitions. Removing the RenderFilter class since it had essentially become a copy of GenericFitler. Changed description above accordingly.
Note: For people who only want to try NEDI there's no need to re-download anything yet.

[Anime Viewer]

Originally Posted by Zachs

Can someone let me know how to use XySubFilter (auto-load version) in GraphStudioNext?
It doesn't load subtitles at all and it doesn't even have an output pin?? How is it meant to be used?

EDIT: Ah nevermind. Found it: http://madshi.net/SubRenderIntf.h

Were you working on getting XySubFilter (auto-load version) working, so that DirectVobSub (auto loading version) wouldn't have to be installed separately for future versions of MPDN?

There might be a way to tie it into the install/setup similar to how KCP did it.

Edit: I see things are tided up with XySubFilter elsewhere, so I guess you're hands are tied on getting it working with MPDN in the near future.
http://forum.doom9.org/showthread.php?t=168282&page=34
http://forum.doom9.org/showthread.ph...44#post1693444

[toniash]

@zachs @shiandow many people do overscaling + sharpening with ffdshow + avisynth because it wasn`t possible with shaders

[Shiandow]

Well a few pages back I posted a method to do NEDI -> Scaling -> Sharpen, but I think that method may not work anymore in combination with some of the changes I made.

Anyway If you want to do: NEDI -> Sharpen -> Scaling, then the easiest way to do this is to download the newest script files, and add the line:

PHP Code:

FinalPass   =   new ShaderFilter(FinalPass, Renderer.CompileShader(Path.Combine(ShaderPath, @"..\SweetFX\LumaSharpen.hlsl"))); 


to Nedi.cs at line 77, just after:

PHP Code:

FinalPass   =   new NEDIVInterleave(FirstPass,NEDI_II,
                        Renderer.CompileShader(Path.Combine(ShaderPath, @"NEDI-VInterleave.hlsl")));); 


This adds another step after the NEDI algorithm, where it performs LumaSharpen on the doubled image.

When it becomes possible to chain shaders this should be possible without changing any code, and hopefully it will even become possible to add a sharpening filter which either does: upscaling -> sharpening or sharpening -> downscaling. But this might take a while.