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

[turbojet]

My batch, which I've tossed, always matched madvr and could switch to refresh rates that madvr couldn't switch to for some reason 72 and 75 hz.

Even if MPDN deinterlaced it probably wouldn't look much different then other renderers deinterlaced, except wmc, which isn't much better. If wmc's method could be figured out and implemented then no need for ivtc or refresh rate changes.

[huhn]

What type of videos play jerky in MadVR but not MPDN? Realizing madvr's film/video detection could use a lot of work. With film mode on all the telecined film and 29 fps video I deal with plays fine. With the little 59 fps video I watch it still works but missing half the frames are noticeable in high motion scenes. OTOH mpdn plays telecined 1080i terribly, with the dupe frames just like any other renderer except madvr's film mode, with the exception of wmc. How does wmc play everything very smoothly? Would be interesting to know. AFAIK it uses the same renderer and default decoder as wmp but wmp doesn't play things smoothly.

If it's wanted I could make a batch script that checks video framerate, monitor refresh rate and switches, if needed, before playing a file in MPDN. I had done something awhile ago to test madvr not switching to certain refresh rates. The only downside to this is all video files need to be opened with the batch script.

madVR can play 29i at 60 fps so what are you talking about?

and it uses the same deinterlacer as WMC the DXVA deinterlacer from your GPU. there is a trade quality for performence option that deinterlace 29i to 30 fps but this is optional.

feel free to post such an major issue in the madVR thread.

[turbojet]

With film mode on it doesn't play 29i at 59 fps and the film/video auto detection is mostly broken.

If WMC uses the same dxva deinterlacer than it's doing something else that plays all 29i telecine material smoothly without dupes at 60hz, it doesn't look like interpolation. SiliconDust's proprietary player QuickTV plays 29i just as smooth as WMC with less cpu/gpu load. No other free players/renderers handles it nearly as good as these 2 except madvr with ivtc which works great with most material at the correct refresh rate or smoothmotion enabled. MadVR and EVR deinterlacing 29i telecine is nearly unwatchable imo, it's just not the same as what you get on your tv from consumer electronics, WMC and QuickTV. If you don't believe me comparehttp://www.mediafire.com/watch/rkctkp9cldmbb69/29i_telecined.mpg in WMC to the others.

If WMC's deinterlacing method was available it's the one to use. There's judder with 25p, 24p and lower progressive video at 60hz with it though.

[huhn]

think about a new thread or we should at least switch to the madVR thread. this thread is not the best choice i guess

i just checked your sample on my windows 10 preview PC it is a normal 3:2 cadence telecine file that should be detelecined and dispalyed with 23p. WMC is no part of windows 10 so i check it later with my windows 7 PC.

will be interesting to see how WMC get's this smooth with a deinerlacer that should be the DXVA deinterlacer.

[turbojet]

I don't think any of this belongs in the madvr thread. I brought it up in here because I asked if ivtc would be considered in the future and Zachs says he'd like to add a deinterlacer but needed examples (of code?). If he didn't want to mess with ivtc may as well aim for a deinterlacing method that is nearly as good which WMC is. Dxva deinterlacing by itself is not very good on telecined material.

[huhn]

I created this thread for this:
http://forum.doom9.org/showthread.php?p=1698551#post1698551

[Zachs]

Edit:
It occurs regardless of whether the Nvidia or Intel gpu is selected for use.
It occurs when the video is maximized to fullscreen (non-fse and with fse enabled), but not when in its default windows size. The "always" bar quickly and briefly flashes on the screen when the configuration button is pressed. I believe it might be being hidden behind the -edit- option -edit- window, and not be able to be switched back to again (and the options window can not be drug away).
It occurs in Direct3D 9Ex render mode as well.
It occurs in video bit depth 8-bit as well.

Edit 2:
Everything seems to point to it occurring when the video screen is maximized to take up the whole screen regardless of what settings are active in the program, and again it never seems to happen when the video is running or paused in its original window.

I just tested this on several machines and none exhibit the problem you described. The options form is shown as a modal dialog - nothing special there.

The "always" bar quickly and briefly flashes on the screen when the configuration button is pressed. I believe it might be being hidden behind the -edit- option -edit- window, and not be able to be switched back to again"

What is an "always" bar?

[Dazog]

Excellent player, Any chance for "Always ontop while playing" feature?

So we don't lose focus on the same screen while multi-tasking.

[Zachs]

Excellent player, Any chance for "Always ontop while playing" feature?

So we don't lose focus on the same screen while multi-tasking.

I'll put that on my todo list.

[Anime Viewer]

What is an "always" bar?

Good question. Unfortunately I can't recall what I meant by that when I typed it 8 days ago (while it says it was posted on the first I actually typed and posted in on the 31st while handing out candy to trick-or-treat-ers). Since I'm typing on a notebook/laptop its possible the cursor jumped and replaced what every word may have been in that space. I suspect I may have been referring to the window/box (what I believe you are calling a "modal dialog") that always pops up when the configuration button in the shader configuration screen is pressed.

You said you tested on numerous systems without being able to replicate it. To rule out certain possibilities did you test it on all of the following type systems?:

Computer with an Optimus setup?
(Since I was able to recreate the bug when both forcing the Nvidia GPU and when forcing the Intel GPU it may not be a connected to either one, but a system that has the mixed GPU setup).

Notebook/laptop?

Its not just the NEDI configuration dialog box, but any of the shader configuration windows that pop up when the configuration button is pressed.

Would someone else with an Optimus system test this problem?
(Open MPDN, Maximize MPDN to full screen, right click on the screen, choose options, enter the Render script settings area, click a script in the script chain area, click the configure button). Does anyone else have the configuration box/window quickly flash on the screen and then vanish (I suspect hide behind the "Options" window)?

Zachs,
Is there perhaps a way to code it so that the Options window/box can be dragged or moved while the related modal dialog boxes are on the screen. That way I could verify the dialog boxes are actually being hidden as opposed to something else.
To give an example of the state it puts things in launch one of the boxes using the configuration button, but instead of interacting with the dialog box try to interact with the options or MPDN video window. Its similar to that state except the screen can not be alt-tabbed away from, and the task can't be ended. When done in this test with the dialog box in the fore-screen the dialog box flashes, but if its being hidden in the background that effect/occurrence may not be seen.
Its also similar (if not identical) to the state (locked fore-ground screen) that occurred with the combination of new windowed mode and DirectX10.1 render both chosen, and the video screen then maximized to full screen. Is it known what was/does happen as far as the type of error that occurs in that type of situation since they may be connected in this case as well?

[Shiandow]

If the dialog is only hidden then you should be able to close it by pressing enter.

[Anime Viewer]

If the dialog is only hidden then you should be able to close it by pressing enter.

That worked, so it looks like it is in fact being hidden. (Don't know how I missed hitting Enter to try and get out of it during my testing. :o)

[Anima123]

Actually I think that bug is cause by the fact that NEDI doesn't update its own input size. More specifically InputFilter is created precisely once, and may not have the correct size.

I think I have found a way to fix it but it requires changes to Filter.cs, and may have other issues. I'll put some more details in a PM.

Shiandow, how's it going on with a proper fix for this bug? I will be looking forward to the next version of your NEDI script.

[Shiandow]

Shiandow, how's it going on with a proper fix for this bug? I will be looking forward to the next version of your NEDI script.

Zachs and I are still working on improving how render scripts work. Part of this is making it easier to react to a change in input size, which is what went wrong with NEDI and caused that bug. Anyway that bug and a lot of other things have been fixed/improved and the improved scripts will be release when the next version of MPDN comes along.

Although if you can't wait, I think we did eventually find a silly mistake which turned out to cause that bug. It should be fixed if you add the line:

base.OnTargetSizeChanged();

at line 99 of Shiandow.NEDI.NediScaler(). This is nowhere near as nice as the way it's fixed in the next version of MPDN, but it should work.

[Zachs]

Would someone else with an Optimus system test this problem?
(Open MPDN, Maximize MPDN to full screen, right click on the screen, choose options, enter the Render script settings area, click a script in the script chain area, click the configure button). Does anyone else have the configuration box/window quickly flash on the screen and then vanish (I suspect hide behind the "Options" window)?


Ah hah! When you said Maximize MPDN to full screen, I thought you meant normal maximize - not change to full screen mode (non-exclusive). I was testing by maximizing the window instead.

So yes, I've finally managed to replicate the bug - so thank you for your persistence! It looks like the script's dialog isn't getting its parent correctly - potentially a .NET framework winform design oversight.

[Zachs]

Excellent player, Any chance for "Always ontop while playing" feature?

So we don't lose focus on the same screen while multi-tasking.

Added in v2.9.0.

That worked, so it looks like it is in fact being hidden. (Don't know how I missed hitting Enter to try and get out of it during my testing. :o)

Fixed in v2.9.0. It was caused by .NET framework not finding the right parent when the modal dialog was shown.

[Dazog]

Added in v2.9.0.



Fixed in v2.9.0. It was caused by .NET framework not finding the right parent when the modal dialog was shown.

Thanks so much for the quick addition to always on top.

[jkauff]

Is there a new Render Scripts .zip file for version 2.9.0, or does the one for the previous version still work? I didn't see a link on Page 1.

EDIT: Nevermind, I found the link. Thanks.

[Anime Viewer]

Added in v2.9.0.

Fixed in v2.9.0. It was caused by .NET framework not finding the right parent when the modal dialog was shown.

Yep it certainly is fixed now.

I did some experimenting with the old error I used to encounter with the screen freezing with a combination of New Windowed Mode and Direct3D 10.1 as the render. Now instead of the freeze it generates error messages. An interesting thing about this error is it occurs when switching back and forth from full screen to windowed mode repeatedly, and when doing so in quick succession. Start a video in windowed mode, double click to expand video to full screen, quickly (as soon as its full screen) double click again to go to windowed size, quickly (as soon as its windowed size) double click to expand to full screen. After repeating for awhile it generates the following errors:
First:

TITLE: SharpDX Error
------------------------------

An unexpected error 'SharpDX.SharpDXException' has occurred.

------------------------------
ADDITIONAL INFORMATION:

HRESULT: [0x887A0005], Module: [SharpDX.DXGI], ApiCode: [DXGI_ERROR_DEVICE_REMOVED/DeviceRemoved], Message: The GPU device instance has been suspended. Use GetDeviceRemovedReason to determine the appropriate action.
(SharpDX)

------------------------------
BUTTONS:

&Ignore
&Abort
------------------------------


then

TITLE: Mpdn.D3D9VideoRenderer Error
------------------------------

An unexpected error 'System.NullReferenceException' has occurred.

------------------------------
ADDITIONAL INFORMATION:

Object reference not set to an instance of an object. (Mpdn.D3D9VideoRenderer)

------------------------------
BUTTONS:

&Ignore
&Abort
------------------------------

I find the D3d9videorender error particularly interesting considering it occurs while the Direct3D 10.1 is still set and showing as the running presenter/renderer.
Its a pretty minor error that probably doesn't matter much since both Direct3D 10.1 mode with old windowed mode, and Direct3D 9 Ex mode with or without new windowed mode both seem to work without causing those errors.

[burfadel]

I get a render error as well...

[Zachs]

I get a render error as well...

Can you give me the stack trace please?

[feelingblue]

Hello

a little question, is possible to use in the shader chain the FineSharp avisynth script ported to MPC-HC Shaders?
http://forum.doom9.org/showthread.php?t=171346

the problem is that the first shader of the chain must convert source rgb into yuv.

[Shiandow]

Hello

a little question, is possible to use in the shader chain the FineSharp avisynth script ported to MPC-HC Shaders?
http://forum.doom9.org/showthread.php?t=171346

the problem is that the first shader of the chain must convert source rgb into yuv.

How is that a problem? It should work if you just use the Image Processing render script and add those shaders.

That said, I did recently discover some weird bugs that seemed to cause problems with shaders that used the alpha channel. Those shaders might run into the same problem. However Zachs was able to find what caused those bugs, so that shouldn't be a problem for long.

[Anime Viewer]

Hello

a little question, is possible to use in the shader chain the FineSharp avisynth script ported to MPC-HC Shaders?
http://forum.doom9.org/showthread.php?t=171346

the problem is that the first shader of the chain must convert source rgb into yuv.

It looks like the scripts function in MPDN. I extracted those shaders to E:\Program Files\MediaPlayerDotNet\RenderScripts\ImageProcessingShaders\MPC-HC on my system and then set the files and their order from the readme inside an image processor script:
ToYUV
RemoveGrain11
RemoveGrain4
FineSharpA
FineSharpB
FineSharpC
ToRGB

Doesn't look very good on my system, but your results may be different depending on your system and the video you're watching.

Edit: just read Shiandow's post above about the bug. Perhaps that is why they don't look good when I added them.
Edit: adding them as post-shaders (after NEDI - if you use NEDI) looked a lot better then adding it as a pre-shaders (before NEDI).

[BetA13]

Finesharp looks great to me, if you dont overdo it.. i tested once with only PRE shader and then with both pre and post..
pre and post is to strong for my liking, but the pre only works and looks great with 720p sources and up..

but i use it in MPCHC with MADvr, doh^^

[Zachs]

I did some experimenting with the old error I used to encounter with the screen freezing with a combination of New Windowed Mode and Direct3D 10.1 as the render. Now instead of the freeze it generates error messages. An interesting thing about this error is it occurs when switching back and forth from full screen to windowed mode repeatedly, and when doing so in quick succession. Start a video in windowed mode, double click to expand video to full screen, quickly (as soon as its full screen) double click again to go to windowed size, quickly (as soon as its windowed size) double click to expand to full screen. After repeating for awhile it generates the following errors:

I find the D3d9videorender error particularly interesting considering it occurs while the Direct3D 10.1 is still set and showing as the running presenter/renderer.
Its a pretty minor error that probably doesn't matter much since both Direct3D 10.1 mode with old windowed mode, and Direct3D 9 Ex mode with or without new windowed mode both seem to work without causing those errors.

I can't replicate this problem on all the machines I've tested (7 graphics cards in total). Granted none had an Optimus setup. Would it possible to disable Optimus to test if it happens on a more traditional setup to rule out driver errors?

[Zachs]

It looks like the scripts function in MPDN. I extracted those shaders to E:\Program Files\MediaPlayerDotNet\RenderScripts\ImageProcessingShaders\MPC-HC on my system and then set the files and their order from the readme inside an image processor script:
ToYUV
RemoveGrain11
RemoveGrain4
FineSharpA
FineSharpB
FineSharpC
ToRGB

Doesn't look very good on my system, but your results may be different depending on your system and the video you're watching.

Edit: just read Shiandow's post above about the bug. Perhaps that is why they don't look good when I added them.
Edit: adding them as post-shaders (after NEDI - if you use NEDI) looked a lot better then adding it as a pre-shaders (before NEDI).

Just to make sure everyone understands how to use the new render scripts. For "post-shaders" you should put a Resizer (to 100% target size) right after NEDI before your Image Processor. Otherwise it processes the image at twice the video size instead of the target size.

IOW, your renderscript chain should look like this:

ImageProcessor --> NEDI --> Resizer (100% target size) --> ImageProcessor.

[Shiandow]

Oh. just tried it out, apparently there is some slight problem with using the Finesharp shaders. The naming for the variables is slightly different from the one MPDN uses, so it didn't get the size information properly.

Edit: Fix no longer needed in latest version of MPDN.

[Dazog]

Can I request a few more features?

A "On Top while playing only" setting.

File type associations in options.

Also in the minimalist mode, no way to tell how far we are into a video if we have to close it and come back and resume from that point.

[kostik]

Is there gonna be pan and scan? I like your player so far but can't get along with it without having a way to zoom video :(
thanks

[Zachs]

Can I request a few more features?

A "On Top while playing only" setting.

File type associations in options.

Also in the minimalist mode, no way to tell how far we are into a video if we have to close it and come back and resume from that point.

I guess if you're not playing, then perhaps just minimize the MPDN window?

File associations is on my todo list, haven't had time to get to that.

Can you elaborate a little on what exactly you mean with the last one? If you move your mouse over the seek bar, doesn't that show you how far into the video?

Is there gonna be pan and scan? I like your player so far but can't get along with it without having a way to zoom video :(
thanks

I have plans to do pan and scan that allows you to fill screen (i.e. no letterboxing) only. Or do you want something more than that?

[kostik]

I guess if you're not playing, then perhaps just minimize the MPDN window?

File associations is on my todo list, haven't had time to get to that.

Can you elaborate a little on what exactly you mean with the last one? If you move your mouse over the seek bar, doesn't that show you how far into the video?



I have plans to do pan and scan that allows you to fill screen (i.e. no letterboxing) only. Or do you want something more than that?
yeap to fill the screen is great. Thanks :)

[Anima123]

FineSharp has the following steps
ToYUV
RemoveGrain11
RemoveGrain4
FineSharpA
FineSharpB
FineSharpC
ToRGB
I wonder if the first and last step are obsolete when used within MPDN's script chain?

[Zachs]

No. If it is applicable to mpchc it's applicable to mpdn.
When you place a pre resize image processor and a post resize one in the chain, mpdn converts YUV to RGB before invoking the scripts. MPDN then expects the result of the render chain to be also in RGB.

[Zachs]

I've updated GitHub with a bunch of changes we (Shiandow and I) have made to improve the render scripts.

Feel free to head over (https://github.com/zachsaw/RenderScripts) to grab the updated version.

Cheers.

EDIT: Added linear light scaling support via ImageProcessor with the following render script chain:
ImageProcessor - When downscaling video: ConvertToLinearLight.hlsl
ImageProcessor - (Your Pre-scaled Shaders - swap with above if you want shaders to work in gamma light)
Resizer - Resize to: 100% of target size
ImageProcessor - (Your Post-scaled Shaders - swap with below if you want shaders to work in gamma light)
ImageProcessor - When downscaling video: ConvertToGammaLight.hlsl

[Anima123]

You guys are awesome!

Now I am encounter a new problem when playing a 720p file with full HD screen. Namely with NEDI and linear light, when play it in windows mode (target size is the same as original size), MPDN used to avoid NEDI in that case, now it's in full chain mode, which means every script in the chain is active.

Any thoughts to avoid unnecessary calculation power consumption in that case?

BTW my script chain is like the following:
NEDI
ImageProcessor - When downscaling video: ConvertToLinearLight.hlsl
esizer - Resize to: 100% of target size
ImageProcessor - When downscaling video: ConvertToGammaLight.hlsl

Edit: So is with 1080p file played in full HD screen resolution. Or I just has the wrong settings with NEDI?

Edit2: The other issue I noticed is that when use linear light without NEDI, playing 1080p file in windows mode, in which case it's downscaling after Resize, which triggers ConvertToGammaLight.hlsl, yet not trigger the ConvertToLinearLight.hlsl in first step, causes the color in windows mode like washed out.

[Zachs]

I think there's a bug that I've fixed in the best version of mpdn that is causing that.

To see if it is that bug, once you have set up the chain can you restart mpdn before testing?

[Shiandow]

I think I've managed to replicate this bug (http://forum.doom9.org/showthread.php?p=1699325#post1699325), it seems to occur when you add the shaders during playback, without resizing. I'll have a quick look to see if I can find what causes it.

Edit: Found it, apparently we forgot to allocate textures when Image Processor updated the filter, again. Let's try a more general fix this time.

[Zachs]

This should be fixed in the version where mpdn triggers output size changed event when apply button is pressed.

Haven't got time right now to release that version yet. But will do ASAP.

[Shiandow]

I actually prefer the method I just proposed on git, maybe have a look?

[Zachs]

I'll take a look.
But MPDN calls output size changed internally anyway to activate its settings :)
Anyway I'll take a look at git.

EDIT: I've merged your changes to master.

[Zachs]

Now I am encounter a new problem when playing a 720p file with full HD screen. Namely with NEDI and linear light, when play it in windows mode (target size is the same as original size), MPDN used to avoid NEDI in that case, now it's in full chain mode, which means every script in the chain is active.

Any thoughts to avoid unnecessary calculation power consumption in that case?

BTW my script chain is like the following:
NEDI
ImageProcessor - When downscaling video: ConvertToLinearLight.hlsl
esizer - Resize to: 100% of target size
ImageProcessor - When downscaling video: ConvertToGammaLight.hlsl

Edit: So is with 1080p file played in full HD screen resolution. Or I just has the wrong settings with NEDI?

Edit2: The other issue I noticed is that when use linear light without NEDI, playing 1080p file in windows mode, in which case it's downscaling after Resize, which triggers ConvertToGammaLight.hlsl, yet not trigger the ConvertToLinearLight.hlsl in first step, causes the color in windows mode like washed out.

Your last issue is fixed with latest render script / MPDN version.

With regards to the first issue, ImageProcessor isn't compatible to be used in that manner yet - When downscaling 'video' means comparing video size with target size, while NEDI doubles the video size before feeding it into ImageProcessor. What is supported at the moment is to have NEDI come after ImageProcessor. EDIT: Scratch that, your usage should be fine. Don't know what I was thinking. If video is being downscaled then NEDI shouldn't be active. In which case, there shouldn't be any problem with using video size vs target size to find out if we're downscaling.

EDIT2: There's still a bug that causes NEDI to be always active when used in that way. I'll fix that.

EDIT3: Fixed in git.

[Anima123]

Shiandow, is there any quality-wise problem with NEDI handled after being converted in linear light, as Zachs suggested right now?

[Zachs]

Shiandow, is there any quality-wise problem with NEDI handled after being converted in linear light, as Zachs suggested right now?

NEDI will be disabled if you don't force enable it in downscaling cases. It won't make a difference.

[Shiandow]

Shiandow, is there any quality-wise problem with NEDI handled after being converted in linear light, as Zachs suggested right now?

Well, as Zachs said there's no problem with the chain you posted since NEDI and linear light conversion won't be on at the same time.

That said I wouldn't recommend performing NEDI in linear light, it tends to make the artefacts more noticeable. And as far as I know there's not much benefit in doing NEDI in linear light. However I could be mistaken so you should probably at least give it a try if you want to be sure.

[Anima123]

I tried the latest version of the player and the script, it's behavior is still not ideal to me.

Let's assume Video Size as the original size of the video, Doubled Video Size is doubled size via NEDI, Target Size is the screen resolution (full screen) mode or a smaller one (windows mode), the following is the ideal behavior in my mind:

if (Video Size >= Target Size) { //which means downscaler should be used
disable NEDI;
trigger linear light if downscaler is used for real;
}
else { // Video Size < Target Size, in which case upscaler should be in use
enable NEDI;
if (Doubled Video Size > Target Size) // in which case the downscaler should be in use
trigger linear light if configured;
}
Any idea if this can be down?

The current latest version does not act like the ideal case, hence there's potential bug to me.

[Zachs]

I have an idea that will do that but I'll discuss with Shiandow in PM first.

[feelingblue]

I am very happy that after my suggestion to use the finesharp shader you have been considering to make it work better. thanks!!
For my setup is probably the best method of sharpness.

A little suggestion, is possible to implement various chroma resampling filters as Robidoux, blackman, Gaussian and Hermite?
Some of them are simlpy interpretation of bicubic style resize.

[Zachs]

I am very happy that after my suggestion to use the finesharp shader you have been considering to make it work better. thanks!!
For my setup is probably the best method of sharpness.

A little suggestion, is possible to implement various chroma resampling filters as Robidoux, blackman, Gaussian and Hermite?
Some of them are simlpy interpretation of bicubic style resize.

MPDN's Softcubic and Bicubic covers a lot of the 'bicubic' style resize via the softness/sharpness parameter. Not sure about blackman but the last I tried gaussian, it's so similar to softcubic it's quite unnecessary.

[Zachs]

I tried the latest version of the player and the script, it's behavior is still not ideal to me.

Let's assume Video Size as the original size of the video, Doubled Video Size is doubled size via NEDI, Target Size is the screen resolution (full screen) mode or a smaller one (windows mode), the following is the ideal behavior in my mind:

if (Video Size >= Target Size) { //which means downscaler should be used
disable NEDI;
trigger linear light if downscaler is used for real;
}
else { // Video Size < Target Size, in which case upscaler should be in use
enable NEDI;
if (Doubled Video Size > Target Size) // in which case the downscaler should be in use
trigger linear light if configured;
}
Any idea if this can be down?

The current latest version does not act like the ideal case, hence there's potential bug to me.

The GUI script chain creator is always going to have limitations - it's just plain unintuitive to use for complicated situations.

As such, MPDN v2.9.3 allows you to write your own chain in a script, as an example:


protected override RenderScript[] GetScriptChain()
{
var result = new List<RenderScript>();

// Pre resize shaders, followed by NEDI image doubler
result.Add(PreProcess);

var size = Renderer.VideoSize;

// Use NEDI once only.
// Note: To use NEDI as many times as required to get the image past target size,
// Change the following *if* to *while*
if (IsUpscalingFrom(size)) // See RenderScriptChain for other comparer methods
{
result.Add(Nedi);
size = DoubleSize(size);
}

if (IsDownscalingFrom(size))
{
// Use linear light for downscaling
result.Add(ToLinear);
result.Add(ResizeToTarget);
result.Add(ToGamma);
}
else
{
// Otherwise, scale with gamma light
result.Add(ResizeToTarget);
}

// Post resize shaders
result.Add(PostProcess);

return result.ToArray();
}


To activate it, choose the "Custom Render Script Chain" script. It must be the sole script in the chain, or its behaviour would be undefined.

Get the latest scripts from github. Example is shown in MyRenderScripts.cs.

You can customize it beyond what is shown by checking for VideoSize - for SD, do X, for super small video size, do Y, for HD, do Z.

Feel free to share your script in the forum!