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

[Zachs]

I can't understand why x32 builds are more efficient!

Not with MPDN. The additional CPU consumption is from upstream filters (ffdshow / AviSynth). It's likely that they haven't coded x64 ASM functions, so the build is non-optimized unlike x86 where performance critical parts would've been fully optimized in ASM/SSE/SSE2 etc. Only a guess. Any SSE2 optimized functions I wrote for MPDN are used in both x64 and x86 builds.

[chainik_svp]

Zachs
Can you elaborate on what you mean by the frame size changing part?

ffdshow raw -> Resize & aspect -> check "Resize"

frame size CAN change after opening the video and all standard renderers (plus madVR) handle this correctly


Anyway ffdshow raw filter increasing CPU consumption is really odd. But that's kind of out of my control really.

still it doesn't with MPC-HC

[Zachs]

Zachs
Can you elaborate on what you mean by the frame size changing part?

ffdshow raw -> Resize & aspect -> check "Resize"

frame size CAN change after opening the video and all standard renderers (plus madVR) handle this correctly


Anyway ffdshow raw filter increasing CPU consumption is really odd. But that's kind of out of my control really.

still it doesn't with MPC-HC


Ah that frame size. What is it used for and how often is it used btw? Unlikely I'll be supporting that in the near future though.

It doesn't with MPC-HC doesn't mean there's no bug in ffdshow that is causing this problem. I don't do anything special to cater for ffdshow. In fact, I do the bare minimum after opening the media file, less than MPC-HC as you have noted with frame size changing.

[chainik_svp]

Ah that frame size. What is it used for.

frame cropping at the first place - to cut off black fields/borders or distorted edges, to change aspect ratio
to fill black fields with SVP ;)


It doesn't with MPC-HC doesn't mean there's no bug in ffdshow that is causing this problem. I don't do anything special to cater for ffdshow.

just letting you know...

[Zachs]

frame cropping at the first place - to cut off black fields/borders or distorted edges, to change aspect ratio
to fill black fields with SVP ;)

Is it a must for SVP to work?

[chainik_svp]

SVP assumes it's working.
One more example is watching 1080p on a smaller screen. One can save a lot of horsepower downscaling the video to screen size before motion interpolation.

In fact I know only ONE video renderer that can't handle this - the one built into Stereoscopic Player.

[Zachs]

SVP assumes it's working.
One more example is watching 1080p on a smaller screen. One can save a lot of horsepower downscaling the video to screen size before motion interpolation.

In fact I know only ONE video renderer that can't handle this - the one built into Stereoscopic Player.

Now you know two :)

[Anime Viewer]

Tested on i5-2430M + AMD 6470M

Common settings: LAV Video decoder (DXVA2 Copy-back mode) + ffdshow raw filter
MPC-HC setting: EVR-CP (bilinear resizer)
MPDN settings: D3D9 renderer on adapter 0, bilinear upscalers, no dithering
SVP settings: the very same in all cases, up to 60 fps, GPU accelerated through AMD's card
Video file: 1280x720 @24

Measured CPU load:

- MPC-HC x32, no SVP: 0-10%
- MPC-HC x64, no SVP: 5-15%
- MPDN x32, no SVP: 10-20%
- MPDN x64, no SVP: 20-30%

- MPC-HC x32, SVP: ~20%
- MPC-HC x64, SVP: ~30%
- MPDN x32, SVP: ~40%
- MPDN x64, SVP: 55-60%

o_O
Are you sure SVP (and/or ffdshow64) is working with your x64 players. You're the only one I've seen report it running without crashing out with an error message. If you're share which files you installed, and what setup configurations you went with in ffdshow64 and MPDN x64 I'll see if Intel GPU report the same increase or not. For me MPDN x64 runs faster (render times) than x32...

Is it a must for SVP to work?
I'm still experimenting with SVP, but like you I think I may prefer MPDN with SVP off (too many graphic anomalies on subtitle video with it on which may be more annoying than any judder that may be present with it off) .

[chainik_svp]

Are you sure SVP (and/or ffdshow64) is working with your x64 players

Yeah I'm pretty sure about it ;)

Not so sure about the numbers as they were taken from one particular system. On my home rig with AMD Phenom X6 it not look so bad...

[toniash]

@Zachs So, what I've to do to insert lumasharpen as a postscaling shader?

[Zachs]

@Zachs So, what I've to do to insert lumasharpen as a postscaling shader?

Just use the luma sharpen render script.
In that script (in RenderScripts folder, SweetFxSample.LumaSharpen.cs), it uses LumaSharpen.hlsl under the SweetFX folder to do pixel shading. In that file, there are several parameters you could change. If you want to stack pixel shaders, have a look at the Luma->Monochrome render script.

[toniash]

Just use the luma sharpen render script.
In that script (in RenderScripts folder, SweetFxSample.LumaSharpen.cs), it uses LumaSharpen.hlsl under the SweetFX folder to do pixel shading. In that file, there are several parameters you could change. If you want to stack pixel shaders, have a look at the Luma->Monochrome render script.

Ok thanks, I'll try!:)

It works! :thanks:

[BetA13]

monochrome works, but lumasharpen doesnt do anything, even when i set it 1.25, wich should totaly oversharpen the picture.. but it didnt change anything...

dunno whats wrong.. i double checked everything, even restarted teh player after selecting teh sharpen shader...

in mpchc etc, this works perfect...
But there im using these here:

---> http://forum.doom9.org/showthread.php?t=170357&highlight=sweetfx

greetz ;)

[Shiandow]

As an example of what the new render scripts can do I've implemented the NEDI shaders I developed (for more information see this thread (http://forum.doom9.org/showthread.php?p=1682901#post1682901)). The configuration process is now considerably easier. Simply download NEDIRenderScripts.rar (http://www.mediafire.com/download/rdzl5taqtpzudp5/NEDIRenderScripts.rar) and extract it in MPDN's RenderScript folder. Then go to MPDN's options and enable the NEDI render script. The script then doubles the image using NEDI and scales the result to the correct output size (using linear scaling, but this should be replaced by something better soon).

People interested in creating their own render scripts may also want to look at the Filter.cs file that is included, this script defines some classes that take care of some of the housekeeping you need to apply and chain shaders. I've asked Zachs to look at whether parts of this script can be included as part of the default render script code. Until that time using Filter.cs should at least make it easier to try things out.

EDIT: Use version 2.8.2. Older version won't work.
EDIT2: Minor improvements to code: NEDIFilter didn't report size correctly and Filter.cs now allows you to try to reuse Textures (fails gracefully and silently).

[Shiandow]

Did you perhaps use version 2.8.2? The name ITexture didn't exist yet in 2.8.0. I should probably have mentioned that, sorry about that.

[Anime Viewer]

Did you perhaps use version 2.8.2? The name ITexture didn't exist yet in 2.8.0. I should probably have mentioned that, sorry about that.

Yep, that was the problem. I wasn't running 2.8.2, so now the scripts are running fine after updating the version.

[toniash]

As an example of what the new render scripts can do I've implemented the NEDI shaders I developed (for more information see this thread (http://forum.doom9.org/showthread.php?p=1682901#post1682901)). The configuration process is now considerably easier. Simply download NEDIRenderScripts.rar (http://www.mediafire.com/download/rdzl5taqtpzudp5/NEDIRenderScripts.rar) and extract it in MPDN's RenderScript folder. Then go to MPDN's options and enable the NEDI render script. The script then doubles the image using NEDI and scales the result to the correct output size (using linear scaling, but this should be replaced by something better soon).

People interested in creating their own render scripts may also want to look at the Filter.cs file that is included, this script defines some classes that take care of some of the housekeeping you need to apply and chain shaders. I've asked Zachs to look at whether parts of this script can be included as part of the default render script code. Until that time using Filter.cs should at least make it easier to try things out.

EDIT: Use version 2.8.2. Older version won't work.

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

[Shiandow]

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

Hopefully it will soon be possible to do this from within MPDN. It should be fairly trivial to add LumaSharpen after NEDI, but you seem to have found a bug, which I'll need to fix to actually make it trivial. I probably won't release a separate version with the LumaSharpen, but after I've fixed the bug you should be able to add it by changing 1~2 lines of code, so I'll just show you which lines you need to change.

[Shiandow]

Turns out it wasn't a major bug (yet) but I've removed it anyway. If you want to use LumaSharpen then what you need to do is: redownload the script, open Nedi.cs, find line 150 (last line of the NEDI.Render method) and add the line:

m_NediFilter = new ShaderFilter(m_NediFilter, m_Renderer.CompileShader(Path.Combine(ShaderDataFilePath, @"..\SweetFX\LumaSharpen.hlsl")));

just after

m_NediFilter = new NEDIFilter(InputFilter, ShaderDataFilePath);

[fairchild]

I just get a black screen when trying to use NEDI shader, the other 2 built in ones work fine. (black screen occurs when going full-screen)

[patul]

Shiandow, thanks for porting your NEDI shader to MPDN, however I found a possible bug, I got blank screen if I resize the window, or go to full screen.

Edit: Ooops, fairchild beats me to it. I wrote the post while retesting the finding.

[Shiandow]

That's odd, I don't seem to be able to reproduce that. Perhaps something weird happens when allocating the new textures. Can't think of anything in the NEDI script that should cause that though, not without crashing.

Edit: Do you still have sound by the way? That would suggest that it is at least doing something.

[fairchild]

Edit: Do you still have sound by the way? That would suggest that it is at least doing something.

Yes, I get sound continuing to play while the screen is just black.

I also just tested with a 1080p file, basically since it has to scale down to a smaller window when not full screen (on a 1080p screen) then I have the black screen. When I go fullscreen with the 1080p movie, I get an image. So basically when it has to resize to a resolution that is not the default, I get a black screen.

[Shiandow]

Could be that the hardware scaling doesn't work for some reason. Could you try changing the extension of "MyOwnUniqueNamespace.MyScaler.cs_" to ".cs", change the "IRenderTarget" on line 24 to "ITexture", and then check if that render script has the same problem?

[patul]

Could be that the hardware scaling doesn't work for some reason. Could you try changing the extension of "MyOwnUniqueNamespace.MyScaler.cs_" to ".cs", change the "IRenderTarget" on line 24 to "ITexture", and then check if that render script has the same problem?

No, it does not have the same problem. MyOwnUniqueNamespace.MyScaler works just fine.

Edit: But, if I read the code correctly, it supposed to run LumaSharpen first, then monochrome. If my understanding is right, then it's not working, I saw no such effect although no blank screen.

[Zachs]

No, it does not have the same problem. MyOwnUniqueNamespace.MyScaler works just fine.

Edit: But, if I read the code correctly, it supposed to run LumaSharpen first, then monochrome. If my understanding is right, then it's not working, I saw no such effect although no blank screen.

Hmm this is odd.

Finally got a few minutes to test NEDI. It's working for me both upscale and downscale. Bloody fast too! 2ms render time for a 320x180 video upscaled to 1080. And the edge is perfectly smooth too on that fav test video of mine - it's highly compressed and has very jagged edges on a lot of the lines - NEDI is much better than Jinc! On several other free to air records, its quality combined with Softcubic chroma doubling is BETTER than my Samsung 55" Series 8 LED TV. It's very similar to NNEDI3 (although *personally* I feel NEDI is more natural - NNEDI3 draws a lot of hard lines when it detects edges while Shiandow's improved NEDI is like a better Jinc). Love it!

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

As for the problems everyone else is seeing, when you enable MyOwnUniqueNamespace.MyScaler, you should see monochrome results. If you don't, then something is obviously broken. I've tested this and NEDI on both Intel and NVIDIA GPUs (don't have access to AMD cards at the moment) and both worked fine.

From the reports, I believe some of you are seeing an exception in the rendering pipeline. It sounds like intermediate texture creation has failed silently (if it seems to work in unscaled output, it's because MPDN is sharing texture with the script internally and would've painted something on it). In the next release of MPDN, I've changed the code quite a bit to enable debug output in the rendering pipeline for errors. What you could do is run DebugView and see if there's any errors. Unfortunately this feature isn't available in v2.8.2 yet, so a little more patience is required. My apologies.

[Anima123]

I might not follow, but how the NEDI script work with together chroma scaling or luma scaling algorithms offered by MPN?

[patul]

As for the problems everyone else is seeing, when you enable MyOwnUniqueNamespace.MyScaler, you should see monochrome results. If you don't, then something is obviously broken. I've tested this and NEDI on both Intel and NVIDIA GPUs (don't have access to AMD cards at the moment) and both worked fine.


Well, I happen to test it on AMD A5400K APU (Radeon HD 7540D) with 14.9 driver.

[Zachs]

Well, I happen to test it on AMD A5400K APU (Radeon HD 7540D) with 14.9 driver.

AMD again. My code is already filled with If AMD then... Looks like I need more of those! There's no specific code branch for Nvidia and Intel.

is everyone else with the problem also using AMD card?

[Zachs]

I might not follow, but how the NEDI script work with together chroma scaling or luma scaling algorithms offered by MPN?

Chroma is usually half the size of luma in width and height. MPDN does the first scaling to get Chroma up to the size of luma. Then NEDI takes over.

[Zachs]

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

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

[toniash]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.

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]

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 (http://haruhichan.com/forum/showthread.php?7545-KCP-Kawaii-Codec-Pack).

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.php?p=1693444#post1693444

[toniash]

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

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


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


to Nedi.cs at line 77, just after:


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.