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

[Zachs]

I had two findings for the new version related to SuperRes stuff.

1. Adding SuperChromaRes into the top of the script chain and then remove it, then the video became unwatchable due to lack of a plane of color like, all I saw is shadows of people;

2. When using SuperNEDIRes to playback a video, after scroll the video a few times, it can be very juggy to watch due to lots of dropped and delayed frames, while re-playback this video will get it back to normal.

#1 should now be fixed with latest GitHub commit.

#2 Can't reproduce here either.

[romulous]

This is really shaping up very nicely Zachs (and to Shiandow as well) - good work :) Though I don't really have an understanding of the render scripts (code wise), I do like the UI when it comes to selecting them for use (though instead of a right pointing arrow to signify the currently active script, I would personally prefer to see a tick mark, just to make it a bit more obvious).

Just wondering if the following was intended or not - if you have MPDN fullscreen and go File->Open, and open a new video, MPDN jumps back to windowed mode (I would have expected that it would have stayed in fullscreen mode).

romulous

[Zachs]

Just wondering if the following was intended or not - if you have MPDN fullscreen and go File->Open, and open a new video, MPDN jumps back to windowed mode (I would have expected that it would have stayed in fullscreen mode).

romulous

That was done on purpose, since it resizes to video size too if it's not in full screen mode. I should probably add an option to prevent that.

[romulous]

I should probably add an option to prevent that.

I think that would be nice :)

romulous

[groen]

I just tried this player out and looks good.

Some features that i found missing is keyboard shortcuts. I am sure there are more pressing issues at this point in development. Just want to request that.

The main ones i like to use is the ctrl+1 -3 to change the size of the player. But not critical.

The other "missing" feature is the ability to set file type associations from within the options.

Also the lack of player controls in fullscreen including volume indicator and I would prefer a thinner seek bar but thats just my preference. ill give this a try and see if i notice any issues.

Thanks for developing this.

[cyberbeing]

Zachs, could you add a window resize/zoom setting to the next version, and add it to the context menu similar to MPC-HC?

Improving the resizing behavior when dragging the edges or corners of the video window when "Lock to Video Aspect Ratio" is enabled would also be welcome.

[Anima123]

"Touch window from outside"/"Touch window from inside" options from mpc-hc would also be very useful sometimes.

[Zachs]

Guys,

Please redownload v2.12.1 if you have downloaded before this post as I botched up the release.

[cyberbeing]

MPDN 2.12.1 introduced a new bug with the sample I sent you.

The top 1px of the subtitle frame is being displayed as the bottom 1px, and the entire frame is shifted diagonally up-left.

http://screenshotcomparison.com/comparison/102796

[Zachs]

I can't replicate this issue on nVidia and Intel GPUs. I have no access to AMD GPUs at the moment. Are you using an AMD card?

[cyberbeing]

I'm using an NVIDIA GTX 770.

[Zachs]

Hmm I did manage to replicate the issue of it shifting one pixel -1,-1, but it doesn't overflow.
I'll do another quick build to see if it resolves the problem.

[cyberbeing]

I just discovered it only seems to overflow in v2.12.1 with DirectX 10.1 selected as the Presentation API. This overflow issue did not occur in v2.12.0.

Though with both DirectX 10.1 & 9Ex the subtitles are shifted, and even seem to shake on that sample when viewed at 1280x720 on a 1920x1080 display. No shake when viewed at desktop size.
It appears this shaking issue isn't new and also exists in 2.11 & 2.10 as well.

[Zachs]

Ah ok, replicated the issue.

[Zachs]

Issues reported by cyberbeing have been fixed with v2.12.2.

[Anime Viewer]

Issues reported by cyberbeing have been fixed with v2.12.2.

I installed 2.12.2 (leaving the user configuration files the same, so the settings carried over from one version to the other), and noticed that double clicking (or pressing the configuration button) on one of the already present scripts in the carried over script chain did the hidden dialogue box again (previously fixed with version 2.9.0 - this time for error messages since that is what is generated when clicking on scripts that don't have configuration settings - like SuperChromaRes and SuperNEDIRes). Interestingly adding a new item to the script chain (regardless of keeping it or deleting it doesn't matter) made the dialogue boxes appear correctly in the foreground. Only appeared to happen with chain items, and once its fixed (by adding sometime to the chain) it can no longer be replicated - since its fixed again.

Expanding on the error dialogue boxes. They only seem to appear when clicking on the scripts when inside the script chain window. They don't occur when clicking on those same scripts in the Video Render - Render Script screen window (where only one script can be used at a time).



Yeah it's probably better to use SuperNEDIRes instead of NEDI ->SuperRes, in fact in that last configuration SuperRes won't do anything unless the image needs to be scaled by a factor > 2.

Using SuperChromaRes should result in slightly more vibrant colours, it should also prevent chroma bleed which is usually visible as a dark outline, especially with a red object on a white background.

Since SuperNEDIRes combines NEDI with SuperRes shouldn't clicking on it to launch a configuration window launch an configuration for Use NEDI image doubling even when not upscaling like clicking on NEDI does when clicking on it?

[Shiandow]

Since SuperNEDIRes combines NEDI with SuperRes shouldn't clicking on it to launch a configuration window launch an configuration for Use NEDI image doubling even when not upscaling like clicking on NEDI does when clicking on it?

Well, SuperRes doesn't make sense when not upscaling so there's not much need for that option. I could add it but then it shouldn't ever be used so I don't see the point.

[Anime Viewer]

Well, SuperRes doesn't make sense when not upscaling so there's not much need for that option. I could add it but then it shouldn't ever be used so I don't see the point.

I can understand the SuperRes not being used when not upscaling. I was thinking more along the lines of the NEDI part of the SuperNEDIRes. In the linked image it has the same pictures on top and bottom. The top one is using SuperChromaRes -> SuperNEDIRes and the bottom with only NEDI. With the top one NEDI will not be active (producing more of a aliasing/noisy look) but with vibrant (ex: carpet? grass?) colors (the SuperChromaRes?) while the bottom one has only NEDI active. (Smoother lines -some might say blurrier look- as seen by the lines of characters arms/legs, bill of Chopper's hat, etc on the bottom picture). One work around to get the SuperChromaRes +NEDI+SuperRes is to break them into separate parts of the chain, but like you said previously that may be less efficient.

An odd thing is switching between the two (Script Chain -SuperChromaRes +NEDI+SuperRes-of and NEDI alone) and then clicking apply. It doesn't always appear to active/deactivate the effects in the script chain after clicking the apply button...

http://postimg.org/image/txiasyexh/

Edit: Is SuperRes causing the increased aliasing in that top image? Flipping between different scripts seems to show that aliasing occurring if SuperRes (by itself/no chain), SuperNEDIRes (by itself/no chain), or SuperNEDIRes (inside a chain) is selected, but it doesn't occur if the chain is SuperChromaRes+NEDI+SuperRes, or if any of the other scripts are chosen. I'm a little confused why its not occurring in the NEDI+SuperRes chain, but it does occur in all the other configurations that have SuperRes as a part of them. :confused:

Also odd...customer render script chain (advanced) with nothing configured/set seems to produce a brighter pictures than all other Render Scripts when selected...

[Shiandow]

I can understand the SuperRes not being used when not upscaling. I was thinking more along the lines of the NEDI part of the SuperNEDIRes. In the linked image it has the same pictures on top and bottom. The top one is using SuperChromaRes -> SuperNEDIRes and the bottom with only NEDI. With the top one NEDI will not be active (producing more of a aliasing/noisy look) but with vibrant (ex: carpet? grass?) colors (the SuperChromaRes?) while the bottom one has only NEDI active. (Smoother lines -some might say blurrier look- as seen by the lines of characters arms/legs, bill of Chopper's hat, etc on the bottom picture). One work around to get the SuperChromaRes +NEDI+SuperRes is to break them into separate parts of the chain, but like you said previously that may be less efficient.

An odd thing is switching between the two (Script Chain -SuperChromaRes +NEDI+SuperRes-of and NEDI alone) and then clicking apply. It doesn't always appear to active/deactivate the effects in the script chain after clicking the apply button...

http://postimg.org/image/txiasyexh/

Edit: Is SuperRes causing the increased aliasing in that top image? Flipping between different scripts seems to show that aliasing occurring if SuperRes (by itself/no chain), SuperNEDIRes (by itself/no chain), or SuperNEDIRes (inside a chain) is selected, but it doesn't occur if the chain is SuperChromaRes+NEDI+SuperRes, or if any of the other scripts are chosen. I'm a little confused why its not occurring in the NEDI+SuperRes chain, but it does occur in all the other configurations that have SuperRes as a part of them. :confused:

Also odd...customer render script chain (advanced) with nothing configured/set seems to produce a brighter pictures than all other Render Scripts when selected...

I'm noticing some odd behaviour in the new v2.12.2, did you use that version? And if so could you try v2.12.0?

[Anime Viewer]

I'm noticing some odd behaviour in the new v2.12.2, did you use that version? And if so could you try v2.12.0?

I was indeed using 2.12.2, and I've now gone back to 2.12.0. You are right that the oddities (aliasing, applies not working) appear to be tied to 2.12.2 in some way. The aliasing (if still present - hard to tell) is far less noticeable in 2.12.0, and the apply button applies the effects right away in 2.12.0 unlike 2.12.2.

[Zachs]

Does 2.12.1 exhibit the same odd behaviour?

[Shiandow]

Does 2.12.1 exhibit the same odd behaviour?

As far as I can tell 2.12.1 seems to be behaving correctly (apart from shifting the image 1 pixel).

[Zachs]

I built it on a different machine and I'm guessing the native cpp files which aren't included in the build script are probably out of date.
I don't have my usual build pc with me at the moment but I'll try to find out if I could do a complete build with this pc.

[cyberbeing]

Another issue I'm noticing, is MPDN has dither noise on solid black R0-G0-B0 backgrounds.
I seem to remember madVR came up with a fix for this, so maybe you could do something similar.

[Zachs]

Random dithering with high enough strength (even the default 2.0) is supposed to do that.
Ordered dithering won't.

[Zachs]

v2.12.3 should correct the oddities in v2.12.2.

[Shiandow]

Yep, v2.12.3 seems to work correctly.

[Zachs]

@Shiandow
You won't believe what caused it!
I must've accidentally hit a numeric key and added an extra number in one of the constants in a vertex buffer. It was quite late so I didn't go through my code changes when I checked in and did a build.
Luckily that was easy enough to spot with source control!

[cyberbeing]

Random dithering with high enough strength (even the default 2.0) is supposed to do that.
Ordered dithering won't.

I was seeing 0R-1G-0B noise on Black with Ordered dithering as well, it was just much less than Random dither.
Here is a levels-enhanced example of the 0R-1G-0B pattern MPDN Ordered dithering produces on flat 0R-0G-0B black backgrounds:
http://i.imgbox.com/0UVYsGy9.png

madVR doesn't produce any dither noise on black, except with Colored Random Dither.
Using Ordered dither, Error Diffusion, or Mono Random dither, a pure black video will remain black.

[Anime Viewer]

Another issue I'm noticing, is MPDN has dither noise on solid black R0-G0-B0 backgrounds.
I seem to remember madVR came up with a fix for this, so maybe you could do something similar.

Random dithering with high enough strength (even the default 2.0) is supposed to do that.
Ordered dithering won't.

I was seeing 0R-1G-0B noise on Black with Ordered dithering as well, it was just much less than Random dither.

madVR doesn't have this issue, except with Colored Random Dither.
Using Ordered dither, Error Diffusion, or Mono Random dither a pure black video will remain black.

I thought it looked a bit noiser than I remember too. There is a very noticable pattern/noise to black objects went using ordered dithering, and to a slightly lesser degree random dithering. I took screen shots, saved a comparison picture in mspaint, but the minute I upload it to an image host-er or try to upload it here as an attachment all the sudden it becomes stripped of its dithering. :confused:

I also compared it to madVR, and noticed the two appeared quite different looking even though they should be using the same dithering effects.

By thinking about the differences between madVR and MPDN I reasoned that having render scripts running might be having an effect on the dithering pattern(s)/noise shown in video. Sure enough testing proved that to be true for me. Cyberbeing try changing your scripts to none, and see if the patterns/noise disappears. With the current MPDN/scripts it looks like a trade off either scripts or dithering. Since my screen(s) looks good at 8-bits channel with no dithering that is what I'm going to go with for now as opposed to using a dithering method, but loosing script functions.

Edit: For reference I tested with 2.12.0 and 2.12.3 and it exists in both, so it isn't related just to version 2.12.3

[huhn]

I thought it looked a bit noiser than I remember too. There is a very noticable pattern/noise to black objects went using ordered dithering, and to a slightly lesser degree random dithering. I took screen shots, saved a comparison picture in mspaint, but the minute I upload it to an image host-er or try to upload it here as an attachment all the sudden it becomes stripped of its dithering. :confused:
if you use print screen and not a screenshoot function this can't be happening. and of cause save them as lossless PNG.
I also compared it to madVR, and noticed the two appeared quite different looking even though they should be using the same dithering effects.
AFAIK madshi has tweaked the dithering algorithm so they shouldn't look the same.

and make sure your laptop panel is not a dithering TN panel.
dithering TN panel are still the best panel for gaming so there is a good reason to use such panel for a gaming oriented laptop.

[cyberbeing]

Cyberbeing try changing your scripts to none, and see if the patterns/noise disappears.

FWIW, I've not experimented with any RenderScripts in MPDN since it's not my day-to-day player for actually watching stuff.
I've only been using MPDN for brief XySubFilter testing at the moment, so unless stated otherwise I'm likely using MPDN defaults.

[fairchild]

I was seeing 0R-1G-0B noise on Black with Ordered dithering as well, it was just much less than Random dither.
Here is a levels-enhanced example of the 0R-1G-0B pattern MPDN Ordered dithering produces on flat 0R-0G-0B black backgrounds:
http://i.imgbox.com/0UVYsGy9.png

madVR doesn't produce any dither noise on black, except with Colored Random Dither.
Using Ordered dither, Error Diffusion, or Mono Random dither, a pure black video will remain black.

I noticed this as well, black level is elevated at pure black with the patterns I use to test this. It's very easy to see on my plasma. Only way I can get MPDN to not elevate the black at pure black level and to match MadVR or even EVR.CP is to totally disable dithering in MPDN.

[Zachs]

I'll take a look at this. Which yuv colorimetric was active at the time btw? Or does it affect both 601 & 709?

[Anima123]

Perhaps the NVIDIA GPU is now taxed a lot more and running out of time to do that extra work to copy the frame buffer to the system memory to be accessed by Intel GPU, and then having to wait for that extra delay to have it presented etc. Unless NVIDIA engineers explain how they are doing that frame buffer copying part (e.g. whether it's fully parallel which I highly doubt), it'll just be speculation. The part of which it sends to the IGP frame buffer for presentation definitely isn't being measured by MPDN, so you may find that it's running out of resources without MPDN reporting so.

Unchecking the 'Use new windowed mode rendering path when possible' option help with rendering time detection, it seems. Now MPDN can report rendering time longer than the framerate time of played video file when using SuperNEDIRes only.

It seems there's something to do with the new rendering path in terms of rendering time calculation.

[fairchild]

I'll take a look at this. Which yuv colorimetric was active at the time btw? Or does it affect both 601 & 709?

Mine is set to BT.709 but it shouldn't matter since the file itself is encoded as such. I don't have a BT.601 black clipping pattern to test the other older color standard.

[Zachs]

OK found and fixed the bugs (both random and ordered dithering).
Well, random is really just due to the strength trackbar in options not going down low enough (a value of 0.5 is equivalent to ordered dithering's strength).

[Anime Viewer]

if you use print screen and not a screenshoot function this can't be happening. and of cause save them as lossless PNG.


I'm not understanding your sentence are you saying to use, or not use print screen? I used print screen to capture the shots, and I did save it as a PNG image. Still it strips out the dithering even when I add it as an attachment on this board (which keeps the extension if nothing else).

Regardless I probably will not worry about posting the examples since everyone appears to be able to replicate the dithering effects...
Edit: and because Zachs posted right before my post that he fixed the bugs. :o

[cyberbeing]

I'll take a look at this. Which yuv colorimetric was active at the time btw? Or does it affect both 601 & 709?
BT.709 was active, since I was just testing that same 720p sample I sent before. Same issue occurs when I force MPDN to BT.601 on that sample.

OK found and fixed the bugs (both random and ordered dithering).
I can confirm I'm no longer seeing the issue with MPDN 2.12.4

[Zachs]

Yes. Fixed in v2.12.4.

[Anime Viewer]

BT.709 was active, since I was just testing that same 720p sample I sent before. Same issue occurs when I force MPDN to BT.601 on that sample.
Good to hear.
Did you test the new 2.12.4 version, and if you chose random dithering did you try the 0.5 value Zachs referenced?
Edit: never mind I see you edited your previous post to report that you no longer see the problem.

OK found and fixed the bugs (both random and ordered dithering).

I can confirm that ordered looks much better on my system now. I don't see the distracting diagonal lines that were appearing in previous versions when using ordered dithering.

[cyberbeing]

It's fixed. I just overlooked Zach's bugfix post and the new MPDN 2.12.4 build when I originally posted.

[Anima123]

Shiandow, could you please double-check your implementation of the SuperRes serie algorithms? I still believe there's something wrong within it, the symptom is that rendering time will increase gradually until my GPU (nVidia 640M) cannot handle it (noticed by a lot of dropped frames).

Maybe it is due to my weak GPU that reveals some potential bugs, while for a stronger GPU, it will always be enough power left after playback of a 2 hours movie.

Edit: To be more specific, after more testing, it was found that the behavior of SuperChromaRes is quite stable, and does not suffer from rendering time increase at all.

Actually, it was SuperNEDIRes I was talking about that suffers from gradually increasing of rendering time.

[romulous]

I have a test file (download link below) that instantly crashes MPDN on my system (no render scripts in use):
https://mega.co.nz/#!YMAwwTja!blxHH99-7dEPBTxncUUw4SwULDZqUEEYjU7Y80C46DI

It's an 800MB ProRes encoded game trailer. So I just go file->open, select the file and click ok, and a couple of seconds later, MPDN crashes.

romulous

[Zachs]

When you say crash what exactly do you mean?
After a few seconds of playback or did it not play at all?
Which edition of MPDN?

[romulous]

Both 32bit and 64bit editions crash, and no playback, no (file->open, immediate crash). It just pops up the standard Windows 'program has stopped working' dialog, no information at all otherwise.

romulous

[Zachs]

Well I just downloaded the file and played it from start to end with absolutely no problem.
When you get a hard crash like that, it's always because of a crash in unmanaged code - e.g. a DirectShow filter.
Are you sure it is not due to one of your DirectShow filters crashing?

[romulous]

I suppose it could be - but MPDN uses LAV, right? My main player uses that same LAV installation and works fine.

[Zachs]

You haven't added any additional DirectShow filters?

[romulous]

Nope, none at all. Not even using any render scripts.