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

[Zachs]

Originally Posted by Anima123

Found a guy who has similar problems of Optimus + nVidia 880M system, which was also related to texture usage.
http://us.battle.net/heroes/en/forum/topic/13733923564

It seems that it's the drivers fault, am I right? We will just have to wait until nVidia give us a 'perfect' driver version.

I will test if debanding has any affect on rendering time later today. From my experience, the new debanding code is much more faster than previous version.

You could also add a few Resizers that resizes to different sizes in the chain to see if it worsens the problem as that forces the chain to create more textures (you'll probably get garbage output but image quality is not the purpose of the test).

Would be good if more people with Optimus could try to replicate the issue as well.

[Zachs]

Originally Posted by ryrynz

I wouldn't just wait. Have you posted your issue in the nVidia forums or provided feedback?

You have access to an Optimus setup haven't you? Perhaps you could help test and see if you could replicate the problem before reporting the bug to nvidia collectively.

[ryrynz]

Originally Posted by Zachs

You have access to an Optimus setup haven't you? Perhaps you could help test and see if you could replicate the problem before reporting the bug to nvidia collectively.

Yeah, I'll have a play on it see what happens.

[Zachs]

Originally Posted by ryrynz

Yeah, I'll have a play on it see what happens.

Great!

I think the settings to replicate the issue were as follows.

SuperChromaRes -> SuperRes with NEDI + 5 passes
Optionally:
Add deband
Resize to 150%
ImageProcessor - LumaSharpen
Resize to 200%
ImageProcessor - LumaSharpen
Resize to 50%
ImageProcessor - LumaSharpen
...
Resize to 100%

@Anima123 is that right?

[Anima123]

It's quite easy to trigger the problem now, you just use the new SuperRes and playback a video file with lower resolution like 720x404 toward a target 1080p resolution.

[Zachs]

Starting v2.20, MPDN's extensions (PlayerExtensions, RenderScripts and CustomLinearScalers) will be merged into one repository and one folder called "Extensions".

Within it, you will still have the three separate extension folders but they are no longer loaded independently - and all scripts will be recursively loaded from the "Extensions" folder. This change is necessary seeing as how much code duplicates are starting to occur between PlayerExtensions and RenderScripts. With that, we can now move the common code into a subfolder, reduce code duplicates, and generally have better synergy between the various scripts.

The interfaces (IPlayerExtension, IRenderScript, ICustomLinearScaler) remain mostly the same with some minor changes.

Also note that we have merged RenderScripts and PlayerExtensions repositories into MPDN_Extensions on GitHub. Please make sure you switch to this repository for any further works.


Cheers,
Zachs

[Blackfyre]

Thanks for the heads up. Really appreciate the hard work. Well done mate. Hopefully it's a smooth transition to version 2.20 (whenever it's released).

Edit: It's released, we'll test soon.

[Zachs]

v2.20.0 released.

Note for all users.

All scripts have now been combined into one zip file (link in OP) and from now on that is the link to use to download the latest scripts. Note that the scripts will be updated from time to time that is outside of MPDN's release cycle, so to get the latest updates, make sure you download the scripts whenever there's an announcement from the developers.

To find out when the extension scripts was last updated, see MPDN_Extensions page on GitHub (e.g. "... authored X minutes/hours/days ago").

[Anime Viewer]

Originally Posted by Zachs

v2.20.0 released.

All scripts have now been combined into one zip file (link in OP) and from now on that is the link to use to download the latest scripts. Note that the scripts will be updated from time to time that is outside of MPDN's release cycle, so to get the latest updates, make sure you download the scripts whenever there's an announcement from the developers.

I've only tested a handful of files so far, but so far 2.20 (and the extensions) seems to extract and work fine.

[Zachs]

All developers,

I've just cleaned up the merged repository. I'd appreciate it if you could all do a merge from the latest revision.

Cheers!

[DeadlyEmbrace]

Ok, I've switched to the new repository and fixed the Remote Control extension. It seems the old one sneaked in somehow.

[Anima123]

Shiandow,

I have get through your algorithm of CalculateSize() and found it doesn't work as expected. For 576p -> 1080p upscaling, there's no intermediate resizing steps, the first pass just push the currentSize direct to 1080p. No wonder it does not suffer from rendering time increasing for 576p video, and that might also explain why the NEDI might not working if MaxScale set >= 2.0.

Another question, does SuperRes shader do upscaling of diff itself with bilinear, if useBilinear is 'true'?

[Shiandow]

Originally Posted by Anima123

Shiandow,

I have get through your algorithm of CalculateSize() and found it doesn't work as expected. For 576p -> 1080p upscaling, there's no intermediate resizing steps, the first pass just push the currentSize direct to 1080p. No wonder it does not suffer from rendering time increasing for 576p video, and that might also explain why the NEDI might not working if MaxScale set >= 2.0.

That is expected behaviour, doing 576 -> 1080p in more than 1 step would require at least one step with a scaling factor less than or equal to sqrt(1.875) which is slightly lower than the minimum allowed scaling factor sqrt(1.9). Also that comment about NEDI not working no longer applies, that bug was fixed recently. For technical reasons NEDI had problems with scaling factors of exactly 2.0.

Originally Posted by Anima123

Another question, does SuperRes shader do upscaling of diff itself with bilinear, if useBilinear is 'true'?

Yes it simply turn hardware bilinear interpolation for the SuperRes shader on, that way the input is automatically interpolated. This costs less memory and seems to be at least as fast as doing it manually.

[Anima123]

Siandow,

Read from http://forum.doom9.org/showthread.ph...11#post1703811, you mentioned that in MPDN, the new texture is used to avoid unnecessary computing of NEDI. I wonder if you can add an option for the user to choose if new texture be used.

Since current Optimus drivers have bug in terms of texture, I wonder if this bug can be avoided somehow by invoke NEDI in a 'traditional, unoptimized' way.

Another simple quick question: Scaler.Bicubic(1.0f, false) or Scaler.Bicubic(0.0f, false), which one is equivalent to Catmull-Rom?

[Anime Viewer]

Originally Posted by Anima123

Since current Optimus drivers have bug in terms of texture, I wonder if this bug can be avoided somehow by invoke NEDI in a 'traditional, unoptimized' way.

What bug are you referring to (is it a 800/900 series bug)? I haven't noticed any texture problem(s) with my 680m GTX Optimus system.

[Anima123]

Originally Posted by Anime Viewer

What bug are you referring to (is it a 800/900 series bug)? I haven't noticed any texture problem(s) with my 680m GTX Optimus system.

Mine is 880M. As I reported in this thread, it will cause rendering time increase gradually when using SuperRes with NEDI enabled.

[Zachs]

*Devs only*

I've added support for .resx (XML) and .resources (compiled resource) file. Here's the guideline to use them correctly with MPDN.

Resource files needs an identifier allocated for it to be accessible in your code and this identifier is generally created automatically when the IDE invokes the compiler, based on the information it gathers from csproj file.

Since there's no csproj file requirement for MPDN's scripts to function, this identifier cannot be automatically generated. As such, you'll need to rename the .resx / .resources file such that the name itself is the identifier.

For example, PlaylistForm.resx would be dependent upon PlaylistForm.cs. Since the PlaylistForm class has a full type name of Mpdn.PlayerExtensions.GitHub.PlaylistForm, you'll need to name the resx file to Mpdn.PlayerExtensions.GitHub.PlaylistForm.resx (or if you pre-ResGen the .resx file, you'll need to name it Mpdn.PlayerExtensions.GitHub.PlaylistForm.resources). As you could see in the following code which is inserted by the designer (in PlaylistForm.Designer.cs), typeof(PlaylistForm) is the reason for naming our resource files the way that was described.

PHP Code:

System.ComponentModel.ComponentResourceManager resources = new System.ComponentModel.ComponentResourceManager(typeof(PlaylistForm)); 


I've updated the PlaylistForm to use an external .resx file to serve as an example.

In conclusion, this change should make it easier for devs who need to embed icons/images in a resource file - all you need to do is rename the file from the IDE generated name to the type's full name (+.resx) before pushing it to GitHub; or you could simply add a postbuild event that ResGen a .resources file with the type's full name, whichever way you feel is easier.

[nekromantik]

I reported before on my 860M there is no bug with render time increases.
Watched a 45 min video with SuperRES NNDI enabled and no bug present. Might be a Keplar bug as my 860M is Maxwell.

[Garteal]

Awesome Zachs, thanks for the quick responses and implementation. Will start updating things here in a bit.

[poorplayer]

Originally Posted by Zachs

No streaming support - No plans for MPDN to support streaming at the moment either. Not even sure if LAV splitter does streaming...

Not sure if it counts as streaming, but MPDN doesn't work for me with SVPtube. It does work with MPC-HC using LAV.