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

[Zachs]

Originally Posted by ryrynz

Jinc is a popular resizer with MadVR users, perhaps Nicolas Robidoux could assist with settings that be be used to improve it. Could be worth having two versions of it, the current implementation and a sharper one more in line with MadVR's version.

It is on my todo list. But it will be a lot slower than the current implementation. I was thinking of implemented it via RenderScript but haven't quite got the time to do it yet.

[Anima123]

Originally Posted by Zachs

With the latest MPDN, could you also try changing the number of backbuffers and render queue size (e.g. reduce to 4) to see if any of the settings makes any difference?

Test using MPDN 2.17.3 and set exactly as you described, it appears no luck. The rendering time increasing issue still there with SuperRes of NEDI enabled.

It seems that reducing render queue size and backbuffers won't help with this problem, the rendering time increasing rate turned to be almost the same as before.

[Zachs]

Originally Posted by Anima123

Test using MPDN 2.17.3 and set exactly as you described, it appears no luck. The rendering time increasing issue still there with SuperRes of NEDI enabled.

It seems that reducing render queue size and backbuffers won't help with this problem, the rendering time increasing rate turned to be almost the same as before.

Does anything increase with render time? GPU usage and/or frequency, GPU ram, CPU usage, system memory. What happens if you open two copies of MPDN and play one after another? Does the other one's render time get affected or does it start afresh?

So no other scales exhibit the same problem?

[Anime Viewer]

Originally Posted by Zachs

Even at maximum size? On my system it is enough to get through that bit where it drains the queue. MadVR does implement multi-subpic support which would explain the difference. MPDN (currently) asks XySubFilter to combine the subpic into one image, so that might be the reason why it's slower. Enhancing XySubFilter support is on my todo list but that todo list seems to be getting longer and longer

Even at max settings it still has drain problems. Since you plan to enhance the XySubFilter support at some point I'm not to concerned about it since there are probably not too many videos that have that issue of miss-using XySubFilter.

Originally Posted by Zachs

Does anything increase with render time? GPU usage and/or frequency, GPU ram, CPU usage, system memory. What happens if you open two copies of MPDN and play one after another? Does the other one's render time get affected or does it start afresh?

So no other scales exhibit the same problem?

I haven't tested for the long video render problem yet, but the XySubFilter one does seem to be effected by how many times you run a video in an open player in a row. The very first time the video is open and it runs it is not as bad as if you run the video and second or more times in that same window after it concludes (even if you just skip to that ending credit scene by taking the progress bar back to the start of the credits). Is it possible the buffers aren't being flushed (even though all queue report dropping to zero at the end of the video playing)?

I'm also seeing an error the first time I launch after setting decoder queue to max (60), closing the player, and then reopening the player (to make it effective). The player opens with a white screen with a red X through it, and reports DXSharp related errors and that backbuffers were not created. If I task manger close it and reopen it (which appears to be the only way to exit out of it in that situation) then the player opens fine with max decoder set and running.

[fairchild]

Woot, the refresh rate changer is working so that's a positive! Whoever worked on it, great job. It is not as robust as some other options out there but it's working. Two things that could be improved upon:

1. have the refresh rate revert back to the original refresh rate once MPDN is closed. (currently it has an option to revert once the file is closed, but if you are changing files often or closing the file all the refresh rate changes can be a bit excessive)
2. have more control over which refresh rates to change to. For instance a media file with a reported 23.976 frame rate is auto changing the display to 24hz (or 23.99 fps) where as optimally it would change to the 23hz option which on my display gives 23.975 fps.

[videonerd]

Zachs / Shiandow - thank you for the hard work on this world class player! We finally have a viable 64 bit alternative to the dormant mpchc/madvr proposition.

UI request - minimalist without window borders

Extension request - increase/decrease play rate + pitch correction

Thank you once again!

[Zachs]

Originally Posted by Anime Viewer

I'm also seeing an error the first time I launch after setting decoder queue to max (60), closing the player, and then reopening the player (to make it effective). The player opens with a white screen with a red X through it, and reports DXSharp related errors and that backbuffers were not created. If I task manger close it and reopen it (which appears to be the only way to exit out of it in that situation) then the player opens fine with max decoder set and running.

This would be the driver error I was talking about regarding Optimus - it doesn't like too many backbuffers whereas the traditional setups prefer 16 backbuffers. I don't think it has anything to do with decoder count though.

Originally Posted by fairchild

Woot, the refresh rate changer is working so that's a positive! Whoever worked on it, great job. It is not as robust as some other options out there but it's working. Two things that could be improved upon:

1. have the refresh rate revert back to the original refresh rate once MPDN is closed. (currently it has an option to revert once the file is closed, but if you are changing files often or closing the file all the refresh rate changes can be a bit excessive)
2. have more control over which refresh rates to change to. For instance a media file with a reported 23.976 frame rate is auto changing the display to 24hz (or 23.99 fps) where as optimally it would change to the 23hz option which on my display gives 23.975 fps.

1. Good idea.
2. Yup, that's a bug. I intended to make it work like you described, but the idea must have eluded me when I was implementing it :P

EDIT: Done and done. Latest version on github.

Originally Posted by videonerd

Zachs / Shiandow - thank you for the hard work on this world class player! We finally have a viable 64 bit alternative to the dormant mpchc/madvr proposition.

UI request - minimalist without window borders

Extension request - increase/decrease play rate + pitch correction

Thank you once again!

I tried the minimialist UI without borders initially (trust me it's a LOT easier than the one with border where I had to do a lot of work behind the scene to make it happen) but I just don't like the look of it - feels out of place in amongst other windows applications? Anyway I'll probably add this feature in at some point for those who prefer it.

Increase/decrease play rate + pitch correction has to be supported natively by MPDN - but I'm not sure how this could be done, seeing that MPDN doesn't have control over the audio graph at all. Any ideas from anyone?

[Anime Viewer]

Am I missing a setting some where, or when new videos launch from the playlist do they always start at the default video size? May other players have it where if you were watching the previous video in fullscreen (be it window or exclusive) the next video will open at fullscreen as well. If this feature isn't already there it would be a useful one to add.

[Zachs]

Originally Posted by Anime Viewer

Am I missing a setting some where, or when new videos launch from the playlist do they always start at the default video size? May other players have it where if you were watching the previous video in fullscreen (be it window or exclusive) the next video will open at fullscreen as well. If this feature isn't already there it would be a useful one to add.

Options | General | Window. Uncheck resize window to fit when opening media.

[Anima123]

Originally Posted by Zachs

Does anything increase with render time? GPU usage and/or frequency, GPU ram, CPU usage, system memory. What happens if you open two copies of MPDN and play one after another? Does the other one's render time get affected or does it start afresh?

So no other scales exhibit the same problem?

Based on my previous test cases, none of abnormal usage found on GPU/CPU nor memory usages.

I will test two copies of MPDN when I returned from business trip.

As I remember, SuperRes with NEDI enabled, and SuperChromaRes + SuperRes with NEDI disabled suffer from rendering time increasing issue. No similar issues found with other scaling algorithms such as SuperRes (NEDI disabled) only.

[Zachs]

Originally Posted by Anima123

Based on my previous test cases, none of abnormal usage found on GPU/CPU nor memory usages.

I will test two copies of MPDN when I returned from business trip.

As I remember, SuperRes with NEDI enabled, and SuperChromaRes + SuperRes with NEDI disabled suffer from rendering time increasing issue. No similar issues found with other scaling algorithms such as SuperRes (NEDI disabled) only.

If GPU usage does not go up but render time does (if this is indeed what you saw), then something is fundamentally wrong - an increase of render time should cause GPU load / frequency to go up as it is a direct measurement of GPU load. If the GPU remains unloaded, there could only be one explanation. It means the driver is taking longer and longer to send commands to the GPU. This could be compounded by the fact that there are a lot more render stages of SuperRes+NEDI which requires more commands to be sent to the GPU for each render pass. I would imagine if you play high end games with a lot of shader effects for an hour and FRAPS it at the beginning and at the end, you'll probably get the same problem as well.

[Zachs]

Github has a new player extension called KeyBindings that adds additional shortcut keys. You can now select next / prev audio (Shift+PageUp/Down) and subtitle tracks (Alt+Shift+PageUp/Down) via shortcut keys. Apart from Escape to exit full screen, F11 also does that (and toggles between them) - just like what a browser does.

With v2.18.0 now supports chapter selection, the Navigation PlayerExtension has also been upgraded to allow Shift+Right and Shift+Left to jump between the chapters.

[shaolin95]

So I am looking for recommendations for maximizing IQ for Bluray rips.
Right now my script is:

SuperChromaRes
SuperRes
Resize
"Image Processor" LumaSharpen

I am running a GTX 750ti btw.
Thanks for any comments.

(BTW, I still cannot get 64bit to run. Not sure what I am missing in my Windows 8.1)

[Zachs]

Originally Posted by shaolin95

So I am looking for recommendations for maximizing IQ for Bluray rips.
Right now my script is:

SuperChromaRes
SuperRes
Resize
"Image Processor" LumaSharpen

I am running a GTX 750ti btw.
Thanks for any comments.

(BTW, I still cannot get 64bit to run. Not sure what I am missing in my Windows 8.1)

You could try the FineSharp shaders too in place of LumaSharpen.

What error did you get for the 64-bit version?
If it's just the generic "Failed to render file", you should use GraphStudioNext (64-bit version) and try building a graph through that. It's a good tool to find out which filter is causing problems.

In particular, you can replicate MPDN's basic filters as follow:
LAV Source Splitter --> LAV Video Decoder --> EVR (any renderer would do as this is only for testing)
LAV Source Splitter --> LAV Audio Decoder --> Default DirectSound renderer

If the above works fine, you should try disabling MPDN's load subtitle option.

[Anima123]

I understand SuperRes with NEDI is actually a new graphic processing GPU application of this kind, i.e. video playback program. I am just wondering if there's a solution on SuperRes side to avoid such kind of issues which, in my mind, would hinder the popularity of this great algorithm.

I also tried NNEDI3 from madVR, which does not suffer similar issue.

Edit: Shiandow seems to have different opinion on the origin of this issue, he think it might related to the texture usage within the algorithms.

[Zachs]

Originally Posted by Anima123

I understand SuperRes with NEDI is actually a new graphic processing GPU application of this kind, i.e. video playback program. I am just wondering if there's a solution on SuperRes side to avoid such kind of issues which, in my mind, would hinder the popularity of this great algorithm.

I also tried NNEDI3 from madVR, which does not suffer similar issue.

NNEDI3 uses OpenCL - and that has its own problems.

Without being able to test this on an Optimus laptop, we're relying on your feedback to try and root cause the issue but so far we haven't got enough data points to even begin changing anything to see if it could side step the problem.

Am I right in assuming the following?

NEDI alone: no problem.
SuperRes without NEDI: no problem.
SuperRes+NEDI (even single pass): bug.

[Anima123]

Originally Posted by Zachs

NEDI alone: no problem.
SuperRes without NEDI: no problem.
SuperRes+NEDI (even single pass): bug.

Yes.

Recently I also noticed that SuperChromaRes + SuperRes (NEDI disabled) suffers the same problem. I'd like to do more tests to double confirm it.

[Zachs]

Originally Posted by Anima123

Edit: Shiandow seems to have different opinion on the origin of this issue, he think it might related to the texture usage within the algorithms.

Yes more textures == more stages per render pass.

[Zachs]

Originally Posted by Anima123

Yes.

Recently I also noticed that SuperChromaRes + SuperRes (NEDI disabled) suffers the same problem. I'd like to do more tests to double confirm it.

Ah this makes more sense, and very much inline with our suspicion.
Does changing pass count affect the outcome (render time grow slower / faster)?

[Anima123]

Originally Posted by Zachs

Ah this makes more sense, and very much inline with our suspicion.
Does changing pass count affect the outcome (render time grow slower / faster)?

As I recall, the rendering time increase rate seems the same between 2 round on my 640M (another laptop) and 8 round on my 880M (current laptop).

Since I didn't do the comparison specifically, I might need more tests to double confirm that later this week.