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

[patul]

I got "Failed to connect filter to graph (Mpdn.VideoPlayer)" exception when tried to use ffdshow raw video decoder as post processing filter. Could you take a look in to it, since I can use this filter in other players? Or I misunderstood the usage of DS filter in your app?

Detailed exception is as per following:

Unable to cast COM object of type 'System.__ComObject' to interface type 'DirectShowLib.IBaseFilter'.
This operation failed because the QueryInterface call on the COM component for the interface with IID
'{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}' failed due to the following error:
No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).
(Mpdn.VideoPlayer)

If you could add playlist and pixel shader support then it will be great. Thanks

[madshi]

finally i can watch movies with madvr but without having teh gpu at 60% all the time...
FWIW, when using MPDN you're not using madVR! MPDN and madVR have nothing to do with each other, except that MPDN is "borrowing" a lot of ideas from madVR.

[Anime Viewer]

Just a heads up, MPDN v2.7.0 has been released and features 12- and 16-tap Lanczos and Jinc. It's also massively faster. First time I've been able to use Jinc 16-tap (or its equivalent) on my GTX560 without it sounding like a plane taking off! :)

Render times are definitely lower then reported with the previous version(s) I used, but I don't see any noticeable visual difference between the different tap settings (at least with the content I've tested with). (I was actually afraid it might over sharpen images with 16-taps set, but since it looks like the others that doesn't appear to occur). As a result I'll probably keep it at a 6 or 8 taps setting unless someone can offer a reason I should set it to one of the other tap settings.

[turbojet]

+1 on shader support and is there any plans for ivtc and auto hiding caption like how auto hide control bar works?

[Zachs]

I got "Failed to connect filter to graph (Mpdn.VideoPlayer)" exception when tried to use ffdshow raw video decoder as post processing filter. Could you take a look in to it, since I can use this filter in other players? Or I misunderstood the usage of DS filter in your app?

Detailed exception is as per following:

Unable to cast COM object of type 'System.__ComObject' to interface type 'DirectShowLib.IBaseFilter'.
This operation failed because the QueryInterface call on the COM component for the interface with IID
'{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}' failed due to the following error:
No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).
(Mpdn.VideoPlayer)

If you could add playlist and pixel shader support then it will be great. Thanks

I'll take a look at the error.

Custom pixel shader support is definitely pretty high on my todo list. I am looking to do a prescale and postscale shader. I'm still toying with the idea of whether to incorporate scripting straight into it too - so you could do things like, scale to a much larger image size than display with sharpest scaler, call an external pixel shader to sharpen it further, then scale it back down for display. I'd imagine this to take quite a bit of time to implement so for the first stage I might just do prescale / postscale custom shader. Does madVR do that at the moment?

Render times are definitely lower then reported with the previous version(s) I used, but I don't see any noticeable visual difference between the different tap settings (at least with the content I've tested with). (I was actually afraid it might over sharpen images with 16-taps set, but since it looks like the others that doesn't appear to occur). As a result I'll probably keep it at a 6 or 8 taps setting unless someone can offer a reason I should set it to one of the other tap settings.

16-tap causes a lot of ringing (especially noticeable for >200% upscale). Jinc is by nature a much softer scaler than Lanczos so ringing is not as noticeable on the higher order scalers. You can definitely tell the difference for low res (say 320x240) image with high contrast edges that has been blown up to a 1920x1080 screen. If you are happy with 8 taps, by all means use that. The lower it is, the cheaper it is to run (quieter too).

+1 on shader support and is there any plans for ivtc and auto hiding caption like how auto hide control bar works?

DXVA Deinterlacing - If there's a small example of how it is done, I'd love to incorporate that into MPDN. I know the API calls I need but I haven't looked into it much yet as all my systems have QuickSync and LAV video decoder does deinterlacing already. Auto hide caption is a great idea. I'll see what I could do.

[Anime Viewer]

16-tap causes a lot of ringing (especially noticeable for >200% upscale). Jinc is by nature a much softer scaler than Lanczos so ringing is not as noticeable on the higher order scalers. You can definitely tell the difference for low res (say 320x240) image with high contrast edges that has been blown up to a 1920x1080 screen. If you are happy with 8 taps, by all means use that. The lower it is, the cheaper it is to run (quieter too).



I was already aware of the ringing at higher taps settings which madVR did a good job of displaying with its visual effects bar when people change scalers in madVR, but checking the anti-ringing boxes always seem to cancel out that problem (at a hit to render speed), but in MPDN that hit is what I consider insignificant. I'll have to test some 320x240 videos that you mentioned to see if I can see the difference there (usually the lowest resolution video I tend to view are 400p).

Something interesting/strange I noticed in my testing is that 64-bit MPDN seems to render twice as fast as the 32-bit version. (See linked screen shots below). The left image is from the 64-bit MPDN, and the right image is from the 32-bit version (both with all the same settings in MPDN).

http://postimg.org/image/se2558l1r/full/

[BetA13]

FWIW, when using MPDN you're not using madVR! MPDN and madVR have nothing to do with each other, except that MPDN is "borrowing" a lot of ideas from madVR.

ooops...yeah i see now.. my bad, im sorry ;) poor choice of words from my site..
also, i just found out that MPDN is not using 60fps@60hz but 23/29/etc fps@60hz

that also might explain why my gpu usage with MPCHC+madvr is so damn high, haha...its not allways easy to perform 60fps on very High HQ content..

Greetz

[Zachs]

Something interesting/strange I noticed in my testing is that 64-bit MPDN seems to render twice as fast as the 32-bit version. (See linked screen shots below). The left image is from the 64-bit MPDN, and the right image is from the 32-bit version (both with all the same settings in MPDN).

http://postimg.org/image/se2558l1r/full/

Are you sure they are exactly the same settings? 32- and 64-bit have separate config files. I have not noticed this on my machines and it shouldn't make a difference as it's the exact same code for 32- and 64-bit paths. Could be the drivers if both have exactly the same settings.

[Anime Viewer]

Are you sure they are exactly the same settings? 32- and 64-bit have separate config files. I have not noticed this on my machines and it shouldn't make a difference as it's the exact same code for 32- and 64-bit paths. Could be the drivers if both have exactly the same settings.

Yes, they are the same settings. I've set them both to Direct3D 10.1 render, unchecked full screen exclusive, set both to the same video bit depth, set both to ordered dithering, and set all scalers to Jinc 6 taps with anti-ringing checked in all.

I was very surprised by it too expecting the same performance from 32 and 64 bit versions, and like you mentioned the only thing I can think of to explain it is the 32-bit vs 64-bit drivers with the 64-bit drivers working better for some reason.

[Zachs]

Yes, they are the same settings. I've set them both to Direct3D 10.1 render, unchecked full screen exclusive, set both to the same video bit depth, set both to ordered dithering, and set all scalers to Jinc 6 taps with anti-ringing checked in all.

I was very surprised by it too expecting the same performance from 32 and 64 bit versions, and like you mentioned the only thing I can think of to explain it is the 32-bit vs 64-bit drivers with the 64-bit drivers working better for some reason.

I see your machine is Optimus equipped. Could be the drivers being optimized a lot more for 64-bit since newer games are mostly 64-bit now. I don't know for sure though, just a guess.

[jkauff]

FWIW, when using MPDN you're not using madVR! MPDN and madVR have nothing to do with each other, except that MPDN is "borrowing" a lot of ideas from madVR.
madshi, maybe you could "borrow" the MPDN feature of allowing the user to choose which version of Direct3D to use. That would allow XP users to continue to use madVR, while others could take advantage of newer technology.

[patul]

I'll take a look at the error.

I'd imagine this to take quite a bit of time to implement so for the first stage I might just do prescale / postscale custom shader. Does madVR do that at the moment?


Thank you. Pre-scale/post scale would be enough. madVR has been supporting custom pixel shader since v0.85.0 if I'm not mistaken.


DXVA Deinterlacing - If there's a small example of how it is done, I'd love to incorporate that into MPDN.

http://msdn.microsoft.com/en-us/library/windows/desktop/cc307964%28v=vs.85%29.aspx

+DXVA Deinterlacing, MPDN will help users with sh*tty CPU and GPU (like me) a lot. I even tested it on my 5 years old laptop (Dual core Athlon Neo X2 L335 + ATi Mobility Radeon HD 3400), DirectX 10.1, 16 bit output!!!!! :p

[Zachs]

Thank you. Pre-scale/post scale would be enough. madVR has been supporting custom pixel shader since v0.85.0 if I'm not mistaken.



http://msdn.microsoft.com/en-us/library/windows/desktop/cc307964%28v=vs.85%29.aspx

+DXVA Deinterlacing, MPDN will help users with sh*tty CPU and GPU (like me) a lot. I even tested it on my 5 years old laptop (Dual core Athlon Neo X2 L335 + ATi Mobility Radeon HD 3400), DirectX 10.1, 16 bit output!!!!! :p

How important is pre-scale custom ps? The reason I'm asking is MPDN scales YUV individually to its target size instead of combining them into RGB first (lots of performance benefits). While I could definitely make pre-scale custom ps for MPDN, it would not be compatible with the ps files that expect RGB textures for pre-scale. It would have to be rewritten to work with YUV individually. Postscale is RGB, so there's no problem.

For post-scaled custom PS, I am need some clarifications on the following:


Existing custom pixel shader parameters:

s0 = scaled texture (RGB)

p0, p1:
#define width (p0[0])
#define height (p0[1])
#define counter (p0[2]) // what is this? Increment by 1.0f per frame?
#define clock (p0[3]) // what is this? Performance counter clock, or video clock in float?
#define px (p1[0]) //one_over_width (of s0 I presume?)
#define py (p1[1]) //one_over_height (of s0 I presume?)


MPDN specifics:

y0, u0, v0 = unscaled y, u, v textures
p2: // unscaled luma and chroma sizes (reciprocal, i.e. 1/width, 1/height)
#define rcp_luma_width (p2[0])
#define rcp_luma_height (p2[1])
#define rcp_chroma_width (p2[2])
#define rcp_chroma_height (p2[3])
#define COLORIMETRIC
#define CM_FULL 0
#define CM_601 1
#define CM_709 2


Specifically, I'd like to know what counter and clock params should contain (I assume these are used for PRNGs but some expect their input values to be in certain ranges).

I would also like to add some MPDN specific params. With those parameters, you could basically write your own scalers.
COLORIMETRIC will be assigned CM_FULL/CM_601/CM_709 when the custom PS is compiled, so you could do your own YUV to RGB conversion too!

[patul]

How important is pre-scale custom ps?

Personally, I only use pre-scale custom ps for color manipulation/effect because it is faster to work with smaller size of pixels on contrary to if do it post-scale. I put sharpening/convolution shaders post-scale.

For the shader parameters, I can't confirm since I don't know either. Sorry. Probably JanWillem32, madshi, or nevcairiel can confirm on these parameters.

[edison]

When playing a x264 rgb lossless avi file(http://www.mediafire.com/download/i86ob2ydx2i9hbh/guide_codeblocks_portable_x264.avi):
http://i.imgur.com/36TMeie.png

[Zachs]

MPDN doesn't support RGB inputs (yet), so it relies on upstream filters (LAV Video Decoder) to convert to one of the 4 supported input formats. In other words, this is expected for RGB encoded videos.

EDIT: Just tested the file myself. Upstream (LAV? Media?) is reporting incorrect YUV colorimetrics. Manually set it to either bt709 or bt601 and you will get correct colors.

[Zachs]

I got "Failed to connect filter to graph (Mpdn.VideoPlayer)" exception when tried to use ffdshow raw video decoder as post processing filter. Could you take a look in to it, since I can use this filter in other players? Or I misunderstood the usage of DS filter in your app?

Detailed exception is as per following:

Unable to cast COM object of type 'System.__ComObject' to interface type 'DirectShowLib.IBaseFilter'.
This operation failed because the QueryInterface call on the COM component for the interface with IID
'{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}' failed due to the following error:
No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).
(Mpdn.VideoPlayer)

If you could add playlist and pixel shader support then it will be great. Thanks

I've just looked into this. I'm not seeing this error here. I could even see ffdshow raw video filter as one of the entries in the filter list.

EDIT: ffdshow version tested: ffdshow_rev4532_20140717_clsid.exe

[patul]

I've just looked into this. I'm not seeing this error here. I could even see ffdshow raw video filter as one of the entries in the filter list.

Ouch.. that's unfortunate. What is your OS? I've tested on two different hardware and OSes (Win7 and Vista), both gave me the same exception. Thanks anyway for looking into it.

[Zachs]

Ouch.. that's unfortunate. What is your OS? I've tested on two different hardware and OSes (Win7 and Vista), both gave me the same exception. Thanks anyway for looking into it.

Win7 x64. Not that it matters I don't think.

Try the ffdshow version in my edited reply.
The error message sounds like the coders of that version you are using have forgotten to report one of its interface (IBaseFilter) when queried. The same thing happened with XySubFilter.

The Old New Thing: The ways people mess up IUnknown::QueryInterface (http://blogs.msdn.com/b/oldnewthing/archive/2004/03/26/96777.aspx)

[patul]

Win7 x64. Not that it matters I don't think.

Try the ffdshow version in my edited reply.
The error message sounds like the coders of that version you are using have forgotten to report one of its interface (IBaseFilter) when queried. The same thing happened with XySubFilter.

The Old New Thing: The ways people mess up IUnknown::QueryInterface (http://blogs.msdn.com/b/oldnewthing/archive/2004/03/26/96777.aspx)

Tested with ffdshow_rev4533_20140929_clsid (latest revision) and ffdshow_rev4530_20140209_clsid (previous revision to ffdshow_rev4532_20140717_clsid), both versions threw the exception. I'll try to revert to ffdshow_rev4532_20140717_clsid and report back. Thanks

[Zachs]

Tested with ffdshow_rev4533_20140929_clsid (latest revision) and ffdshow_rev4530_20140209_clsid (previous revision to ffdshow_rev4532_20140717_clsid), both versions threw the exception. I'll try to revert to ffdshow_rev4532_20140717_clsid and report back. Thanks

Strange. I didn't have to do anything besides adding it to the video post processing list to get it to work. I did find a bug with how I was detecting input format though so I'll correct that in the future. It was to do with how YUV format was changed from what LAV Video Decoder reported and I was using the format from that instead of the ffdshow filter.

As a workaround, just have ffdshow output to YV12 for now.

[patul]

Strange. I didn't have to do anything besides adding it to the video post processing list to get it to work. I did find a bug with how I was detecting input format though so I'll correct that in the future. It was to do with how YUV format was changed from what LAV Video Decoder reported and I was using the format from that instead of the ffdshow filter.

As a workaround, just have ffdshow output to YV12 for now.

After full install of ffdshow_rev4532_20140717_clsid, it works somehow, I also noticed the bug you mentioned just now. Previously I only installed the raw video decoder filter, since I only need its post processing. Thanks

[Zachs]

I haven't tried svp but does that mean you could run svp with MPDN now?

[Blight]

Zachs,
Any plan to release just the renderer as a separate filter?

Why limit the renderer to only support a locked-in GUI and player feature set?
If you release the renderer as a stand-alone filter, I'll be happy to add support for it in Zoom Player.

[Zachs]

I explained before that it's not possible as it's not written as a DirectShow renderer. .NET is not friendly when it comes to writing DirectShow renderers unfortunately. Believe me when I said I have tried. It will take some c++ shims and a lot of effort to turn it into a DirectShow renderer.

[patul]

I haven't tried svp but does that mean you could run svp with MPDN now?

Sure, I can run SVP with MPDN. Tried and confirmed. :):)

[Blight]

Zachs:
That's a shame, it severely limits the exposure of your cool work.

[Anime Viewer]

Sure, I can run SVP with MPDN. Tried and confirmed. :):)

Anything special people should know about configuring it for use with MPDN?
I had never used SVP before, and just downloaded and installed it getting the results shown in the picture below. Here is what I did:

Downloaded SVP_3.1.6 from the SVP website (http://www.svp-team.com/wiki/Download), installed SVP unchecking everything except SVP 3.1.6 and Options (since there is no need for the SVPTube player, or anything MPC, LAV, or MadVR related (since LAV is already installed, and none of the other things would be used with MPDN and SVP)), left Install AviSynth and Install FFDShow checked and left the other Extras unchecked.
Launched MPDN, Options, DirectShow, Video and added ffdshow raw video filter to selected filters.
What (if anything) is wrong or missing compared to your (patul) setup?


http://s11.postimg.org/4hzqu8csv/SVP_MDPN_test.jpg (http://postimg.org/image/4hzqu8csv/)

[patul]

Anything special people should know about configuring it for use with MPDN?


Make sure you use YV12 as "Primary output color space" in ffdshow under "Output" tab, and you could try to turn off the "Set interlaced flag in output media type" check box. In fact, to make it simple, I use YV12 in the whole DS graph.

[Zachs]

There's a bug in MPDN that requires ffdshow to be set to output YV12 only as a workaround for now. I'll be fixing that in the next release along with the new feature "RenderScript".

[Anime Viewer]

Make sure you use YV12 as "Primary output color space" in ffdshow under "Output" tab, and you could try to turn off the "Set interlaced flag in output media type" check box. In fact, to make it simple, I use YV12 in the whole DS graph.

There's a bug in MPDN that requires ffdshow to be set to output YV12 only as a workaround for now. I'll be fixing that in the next release along with the new feature "RenderScript".

Thanks for the replies, but unfortunately changing the output to only YV12 in ffdshow video decoder configuration didn't eliminate the problem. I'll wait until the next release and test it again after that. (I testing by adding ffdshow raw video filter in external filters in MPC-HC, and it worked with that player so once the fix is instituted hopefully it will work in MPDN too). (Not that its perfect in MPC either - it smears subtitles in MPC-HC).

[patul]

Have you tried to turn off the "Set interlaced flag in output media type" check box? I had exactly same problem, but after changed the output color space and turn off the "Set interlaced flag...", the problem gone.

[Anime Viewer]

Have you tried to turn off the "Set interlaced flag in output media type" check box? I had exactly same problem, but after changed the output color space and turn off the "Set interlaced flag...", the problem gone.

Yes, I tried with the set interlaced flag unchecked. I also tried unchecking everything except YV12 in addition to setting YV12 as the primary output color space.

I also tried setting other things in the ffdshow video decoder configuration program to only use YV12 (like AviSynth), but that made no difference. Prior to that test I was running with all the boxes in the left column of the configuration program unchecked. I experimented with checking and changing settings in Postprocessing and codec. I also tried unchecking all output formats except for Yv12 in LAV video decoder. None of those experiments worked either.

I noticed if I hover over the ffdshow video decoder raw square on the startbar while video is playing it reads:
Input: YV12 (uncompressed)
Output: NV12

[Zachs]

Guys, I'm about to release the next version in the next half an hour and it should fix that problem. Might wanna save your time testing the newer version instead.

EDIT: Version 2.8.0 is now released.
I've tested ffdshow with 2.8.0. Working fine now.

[Anime Viewer]

Guys, I'm about to release the next version in the next half an hour and it should fix that problem. Might wanna save your time testing the newer version instead.

EDIT: Version 2.8.0 is now released.
I've tested ffdshow with 2.8.0. Working fine now.

The 2.8 version did indeed fix the color issues when playing with ffdshow and SVP. However SVP causes graphic anomalies (what I previously referred to as subtitle smearing, but I now see isn't just the subtitles - see picture linked below). Since I see it occur in both MPC-HC and MPDN I suspect it would have to be fixed by SVP, and there may not be anything that can be done to resolve it from the video player side.

Screen shot taken from MPDN 2.8.1:
http://postimg.org/image/71jxvhiqt/
Edit: I found the issue causing the SVP blurring (aka double contours and interpolated frames issue). Unfortunately the solution talked about on the linked page doesn't entirely get rid of the problem since SVP removed some of the options from their profile options. (Decrease grid step and search radius are no longer selectable options).
http://www.svp-team.com/wiki/Watching_anime

[edison]

It seems the XySubFilter does not work with 2.8.1 here.

[Zachs]

It seems the XySubFilter does not work with 2.8.1 here.

No that still remains on my todo list.

[Zachs]

The 2.8 version did indeed fix the color issues when playing with ffdshow and SVP. However SVP causes graphic anomalies (what I previously referred to as subtitle smearing, but I now see isn't just the subtitles - see picture linked below). Since I see it occur in both MPC-HC and MPDN I suspect it would have to be fixed by SVP, and there may not be anything that can be done to resolve it from the video player side.

Screen shot taken from MPDN 2.8.1:
http://postimg.org/image/71jxvhiqt/
Edit: I found the issue causing the SVP blurring (aka double contours and interpolated frames issue). Unfortunately the solution talked about on the linked page doesn't entirely get rid of the problem since SVP removed some of the options from their profile options. (Decrease grid step and search radius are no longer selectable options).
http://www.svp-team.com/wiki/Watching_anime

I'm not a big fan of frame interpolation. Can't stand the artefacts and soap opera feel. Hated the hfr hobbit!

[huhn]

please don't put frame interpolation and HFR in the same box this is like apple and moonstone.

[Zachs]

please don't put frame interpolation and HFR in the same box this is like apple and moonstone.

I guess I wasn't clear. I meant I personally feel HFR = soap opera. Using frame interpolation to achieve HFR with unwanted artefacts is... worse. Again, personal feeling. But to each his own.

[Zachs]

MPDN v2.8.4 (To be updated to v2.9.0 soon!!!)

IRenderer.cs


using System.Drawing;
using Mpdn.RenderScript.Scaler;
using SharpDX;
using SharpDX.Direct3D9;
using Point = System.Drawing.Point;

namespace Mpdn.RenderScript
{
public interface IRenderer
{
// Returns original video size
Size VideoSize { get; }

// Returns original luma size
Size LumaSize { get; }

// Returns original chroma size
Size ChromaSize { get; }

// Returns the aspect ratio (nominator=X and denominator=Y)
Point AspectRatio { get; }

// Returns the target window size (after applying letterboxing)
// Can change mid-playback (OnTargetSizeChanged will be called)
Size TargetSize { get; }

// Returns the YUV colorimetrics type (as seen on Ctrl-J stats screen)
// Can change mid-playback (OnTargetSizeChanged will be called)
YuvColorimetric Colorimetric { get; }

// Returns the input format (as seen on Ctrl-J stats screen)
FrameBufferInputFormat InputFormat { get; }

// Returns the current output bit depth
// Can change mid-playback (OnTargetSizeChanged will be called)
BitDepth OutputBitDepth { get; }

// Original Y plane texture
ITexture TextureY { get; }

// Original U plane texture
ITexture TextureU { get; }

// Original V plane texture
ITexture TextureV { get; }

// The active luma upscaler (as set in MPDN options menu)
IScaler LumaUpscaler { get; }

// The active luma downscaler (as set in MPDN options menu)
IScaler LumaDownscaler { get; }

// The active chroma upscaler (as set in MPDN options menu)
IScaler ChromaUpscaler { get; }

// The active chroma downscaler (as set in MPDN options menu)
IScaler ChromaDownscaler { get; }

// The input render target that holds the MPDN prescaled texture
ITexture InputRenderTarget { get; }

// The output render target that MPDN will display on screen
// InputRenderTarget can the same as OutputRenderTarget if both can share the same texture
ITexture OutputRenderTarget { get; }

// When render scripts are chained, the next render script in the chain could request for its input in YUV
bool OutputYuv { get; }

// Create a render target of 'size' to use in the script
ITexture CreateRenderTarget(Size size);

// Create a texture of 'size' to use in the script
ITexture CreateTexture(Size size);

// Update the texture created via 'CreateTexture'
// 'data' is of type Half (16-bit float) and the length of the array must be equals to
// texture width * 4 (RGBA) * height
void UpdateTexture(ITexture texture, Half[] data);

// Compile shader program (hlsl) and return a shader object
IShader CompileShader(string filename);

// Load precompiled shader program (compiled shader object) and return a shader object
IShader LoadShader(string filename);

// Render to renderTarget using the specified shader
void Render(ITexture renderTarget, IShader shader);

// Render to renderTarget using the specified texture (no pixel shader)
// enableHwFiltering = true sets to linear filter, false sets it to point filtering
void Render(ITexture renderTarget, ITexture texture, bool enableHwFiltering);

// Same as above except it uses MPDN's internal scaler
// 'Scale' automatically determines which scaler (upscaler or downscaler, or none) to use depending
// on whether the render to renderTarget is an upscale, downscale or straight blit
void Scale(ITexture renderTarget, ITexture texture, IScaler upscaler, IScaler downscaler);
}
}


IScriptRenderer.cs


namespace Mpdn.RenderScript
{
public interface IScriptRenderer
{
ScriptDescriptor Descriptor { get; }

ScriptInputDescriptor InputDescriptor { get; }

// Called immediately when this class is instantiated
// 'instanceId' is zero-based index of the instance of this class
// in a render script chain
void Initialize(int instanceId);

// Will not be called if InputDescriptor.HasConfigDialog returns false
void ShowConfigDialog();

// Called when this object is assigned to MPDN's renderer
// This will happen before OnTargetSizeChanged() and Render() ever gets called
void Setup(IRenderer renderer);

// Called when target size has changed (e.g. window resize)
void OnTargetSizeChanged();

// Render your frame to IRenderer.OutputRenderTarget here
void Render();
}
}


ITexture.cs


using SharpDX.Direct3D9;

namespace Mpdn.RenderScript
{
public interface ITexture
{
Texture Texture { get; }
Surface Surface { get; }

int Width { get; }
int Height { get; }
}
}


IShader.cs


using System;
using System.IO;
using SharpDX.Direct3D9;

namespace Mpdn.RenderScript
{
public interface IShader : IDisposable
{
void SetConstant<T>(string identifier, T value, bool throwOnError) where T : struct;

void SetTextureConstant(string identifier, Texture value, bool enableHwFiltering, bool throwOnError);

void SetTextureConstant(string identifier, BaseTexture value, bool enableHwFiltering, bool throwOnError);
}
}


ScriptDescriptor.cs


using System;

namespace Mpdn.RenderScript
{
public class ScriptDescriptor
{
// Each script needs a unique GUID
public Guid Guid = Guid.Empty;
public string Name;
public string Description;
public string Copyright;
public bool HasConfigDialog;
}
}


ScriptInputDescriptor.cs


using System.Drawing;

namespace Mpdn.RenderScript
{
public class ScriptInputDescriptor
{
// IRenderer object's InputRenderTarget will be provided in this size
public Size Size;
// If true is returned, dithering is disabled and the prescaled texture will
// be provided in YUV format
public bool WantYuv;
// Set Prescale to false if don't need MPDN to prescale Y, U and V textures
// In which case, IRenderer object's InputRenderTarget will be blank
// Typically, you'd only set this to false if you are doing your own scaling
// and you are using TextureY, TextureU and TextureV directly to render your
// target (which means you don't need MPDN's prescaled texture)
// Default is true
public bool Prescale = true;
}
}


Scalers.cs


using SharpDX.Direct3D9;

namespace Mpdn.RenderScript.Scaler
{
public interface IScaler
{
ImageScaler ScalerType { get; }
}
}

// Scaler types and their constructors:
// HwPoint();
// HwBilinear();
// Bilinear();
// Softcubic(float softness); // softness 0.0f - 1.0f
// Bicubic(float sharpness, bool antiRingingEnabled); // sharpness 0.0f - 1.0f
// Lanczos(Lanczos.Taps tapCount, bool antiRingingEnabled) // tapCount Lanczos.Taps.Four, Six, Eight, Twelve, Sixteen
// Spline(Spline.Taps tapCount, bool antiRingingEnabled) // tapCount Spline.Taps.Four, Six, Eight
// Jinc(Jinc.Taps tapCount, bool antiRingingEnabled) // tapCount Jinc.Taps.Four, Six, Eight, Twelve, Sixteen

// Usage example:
// IScaler upscaler = new HwPoint();
// IScaler upscaler = new Jinc(Jinc.Taps.Sixteen, true);


Declarations.cs


using System.ComponentModel;

namespace Mpdn.RenderScript
{
public enum FrameBufferInputFormat
{
[Description("NV12 8-bit 4:2:0")]
Nv12,
[Description("YV12 8-bit 4:2:0")]
Yv12,
[Description("P010 10-bit 4:2:0")]
P010,
[Description("P016 16-bit 4:2:0")]
P016
}

public enum YuvColorimetric
{
[Description("Full Range")]
FullRange,
[Description("ITU-R Rec BT.601")]
ItuBt601,
[Description("ITU-R Rec BT.709")]
ItuBt709
}

public enum BitDepth
{
[Description("8 bits")]
EightBits,
[Description("10 bits")]
TenBits,
[Description("16 bits")]
SixteenBits
}

public enum ImageScaler
{
Hardware,
Bilinear,
Bicubic,
Softcubic,
Lanczos,
Spline,
Jinc
}
}

[Anime Viewer]

Hi everyone,



Starting v2.8.0, MPDN has a new feature called "Render Script". This takes advantage of C#-script to allow user to fully customize / rewrite the entire rendering pipeline of MPDN. Essentially, all of MPDN's current scaling algorithms could be fully implemented via its Render Script system and run as fast and efficient as it is implemented in MPDN. In other words, there is no advantage for your custom algo to be coded in MPDN. In fact, in moving forward, any new scaling algorithms I implement for MPDN will be via its Render Script system. In the RenderScript folder, you will find some sample scripts which by no means showcase anywhere near its full capabilities. Detailed documentation and more advanced samples to follow (this will take some time - some help appreciated).

[/CODE]

I'm guessing I'm not understanding how the Renderscripts and example SweetFX shaders enable. Selecting the monochrome option does turn the video black and white, but the other SweetFX doesn't appear to change the picture in any way from when the none setting is selected instead, and in all cases the configuration button is greyed out when the SweetFX options are selected.

The SweetFX is supposed to have an effect like shown in the comparison pictures at the link below, correct?
http://forums.elderscrollsonline.com/discussion/89444/sweetfx-the-enhancement-that-your-eso-game-is-likely-missing

[Zachs]

SweetFX is a suite of Pixel Shader files for post processing. The two render scripts are really just examples of what could be done. The luma shapen one, take a look at the corresponding files in the SweetFX folder (LumaSharpen.hlsl) for the different settings you could choose.

MPDN render scripts are like winamp dsp plugins except there is no need to compile them into DLLs. If you have used post processing shaders before then render script is similar but is much more flexible.

As to why configure button is disabled, that's because the example render scripts say there's nothing to configure.

Ultimately this opens up MPDN for full extensibility by the community. For example, Shiandow's amazing NEDI scaling algo could be implemented and it would be just a click away to activate it.

[patul]

Thanks for the new version. A bit unusual approach to implement custom shader support, on contrary to other players. I was bit skeptical to this approach, but then I realized the full potential of this approach, it will be easier to port custom scalers into MPDN, I would love to see Shiandow's NEDI scaler ported to MPDN.

However, I still think you probably have to consider non-developer users too, if you want this player to be widely used. Convenience of usage is needed, for example stacking, ordering of shaders.

[Zachs]

Thanks for the new version. A bit unusual approach to implement custom shader support, on contrary to other players. I was bit skeptical to this approach, but then I realized the full potential of this approach, it will be easier to port custom scalers into MPDN, I would love to see Shiandow's NEDI scaler ported to MPDN.

However, I still think you probably have to consider non-developer users too, if you want this player to be widely used. Convenience of usage is needed, for example stacking, ordering of shaders.

Already well into this chaining/ordering of scripts (current implementation of render script lacks the ability to stack/order multiple scripts). However, stacking/ordering "plain old" shaders can be easily created via the current implementation of render script. If anyone wants to have a go at creating such a script, I'll be happy to provide any assistance. If not, I'll be doing that when I get some time.

Render script is at its infancy now for end-users especially. The whole render script system was created in consultation with Shiandow based on his experience on what was lacking in other players / renderers' custom pixel shader system. I could use with a little help though especially with that plain old pixel shader as post processing filter stacking script.

[chainik_svp]

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

[Zachs]

As said a few pages ago MPDN does a lot more than mpchc EVR CP even with the same settings. Among others there is frame drop / delay prevention that sacrifices some cpu cycles to guarantee smooth playback.

EDIT: I've just tested a 50fps HD clip on both MPC-HC EVR CP and MPDN, both without SVP. Both Bilinear. Both without ffdshow raw video filter. Both x86 builds.
GTX560, i5-3470

MPDN: 7-8%
MPC-HC: 6-7%

That's a difference of 1% in MPC-HC EVR CP's favour.

Letting the clip play further, both dropped MPC-HC and MPDN dropped to 5%. BTW, I used "low update speed" on my task manager to get a more stable average.

[toniash]

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
I can't understand why x32 builds are more efficient!

[chainik_svp]

Seems like just adding "ffdshow raw" (w/o any filters) in MPDN increases CPU consumption by 10-15%.
That 60fps video file (http://www.svp-team.com/files/demo/space_60.mkv): 35-45% CPU load w/o ffdshow raw in both MPC-HC and MPDN and up to 60% in MPDN with ffdshow.


BTW it really doesn't like frame size changing in the post processor ;)

[Zachs]

Seems like just adding "ffdshow raw" (w/o any filters) in MPDN increases CPU consumption by 10-15%.
That 60fps video file (http://www.svp-team.com/files/demo/space_60.mkv): 35-45% CPU load w/o ffdshow raw in both MPC-HC and MPDN and up to 60% in MPDN with ffdshow.


BTW it really doesn't like frame size changing in the post processor ;)

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

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