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

[harshal_rio91]

Originally Posted by Zachs

Can you put it on imgur? Your attachment is pending approval and may take quite some time before I can see it.

If you let MPDN run for say 5 minutes, does the display rate stabilise (converges to a stable number)?

here you go : http://imgur.com/j4udczT

display rate stays at 60Hz

[Zachs]

Originally Posted by harshal_rio91

here you go : http://imgur.com/j4udczT

display rate stays at 60Hz

Ah that's the reason it failed to work.
Chances are you'll never get FluidMotion to work properly, unless NVIDIA fixes the bug that's preventing video players from detecting the true refresh rate. It would appear that it's a (driver?) bug that's affecting your generation of Optimus hardware only.

I can put in a work around in the new version but you won't be getting anywhere near the quality MPDN offers in terms of playback smoothness.

[harshal_rio91]

Originally Posted by Zachs

Ah that's the reason it failed to work.
Chances are you'll never get FluidMotion to work properly, unless NVIDIA fixes the bug that's preventing video players from detecting the true refresh rate. It would appear that it's a (driver?) bug that's affecting your generation of Optimus hardware only.

I can put in a work around in the new version but you won't be getting anywhere near the quality MPDN offers in terms of playback smoothness.

oh! I reported Nvidia about this bug and today got a reply from them. They asked stupid questions like whether the player was running on nvidia or intel(I stated in the bug report that the player was running on nvidia gpu). Hopefully I hear positive reply from them.

[Zachs]

You may want to update the bug report to include some details about the cause of the problem.
You should mention to them that this is definitely a bug since other generations of Optimus hardware / driver don't have this problem.

[harshal_rio91]

Originally Posted by Zachs

You may want to update the bug report to include some details about the cause of the problem.
You should mention to them that this is definitely a bug since other generations of Optimus hardware / driver don't have this problem.

Ya will do so

[Zachs]

Can you quickly give this a try and see if it works now?

[harshal_rio91]

Originally Posted by Zachs

Can you quickly give this a try and see if it works now?

yes it works

[Zachs]

Originally Posted by harshal_rio91

yes it works

Great! That's the same version as the released build.
You should now be able to use the latest player extensions / render scripts from GitHub.

[harshal_rio91]

Originally Posted by Zachs

Great! That's the same version as the released build.
You should now be able to use the latest player extensions / render scripts from GitHub.

thanks

[harshal_rio91]

Originally Posted by Zachs

You may want to update the bug report to include some details about the cause of the problem.
You should mention to them that this is definitely a bug since other generations of Optimus hardware / driver don't have this problem.

The nvidia people are asking for the email from the developer stating the problem with nvidia Optimus.
I sent them a link to this forum but they want email.

[RenderGuy2]

Unfortunately I'm ignorant to the possibilities of render scrips. Would it be possible to write a render script that would take a 1920x1080@47.952 fps source and stack even frames over odd frames with a 45 pixel gap/border between frames? The resulting output should be 1920x2205@23.976 fps. Currently I accomplish this by performing these operations with Avisynth and just play the .avs with the player. Seems like these sorts of things could be done faster by a GPU. The point of all this is to produce an HDMI 1.4a compliant frame packed stream I can play on a 3d television. Thanks for the advice.

[Anima123]

Is there developers be kind enough to write nVidia a proper bug report about the rendering time increasing when when textures are used when playing with MPDN with renderscript or renderscript chain?

It seems nVidia guys are trying to improving there drivers by addressing common bugs, I would like to take this opportunity.

[Shiandow]

Originally Posted by RenderGuy2

Unfortunately I'm ignorant to the possibilities of render scrips. Would it be possible to write a render script that would take a 1920x1080@47.952 fps source and stack even frames over odd frames with a 45 pixel gap/border between frames? The resulting output should be 1920x2205@23.976 fps. Currently I accomplish this by performing these operations with Avisynth and just play the .avs with the player. Seems like these sorts of things could be done faster by a GPU. The point of all this is to produce an HDMI 1.4a compliant frame packed stream I can play on a 3d television. Thanks for the advice.

At the moment there's no way to change the timing of frames, so going from 47.952 fps to 23.976 fps is not possible. But does Avisynth really use that much CPU? It shouldn't take that much computation to simply put two frames on top of each other.

[RenderGuy2]

Shiandow, you are correct, stacking the frames takes very little CPU, however, in order to have the odd frame height (2205px) you need at least 4:2:2 chroma, so I've also been using nnedi3 to double the height of the U and V planes. This is probably overkill and uses a fair bit of CPU. I was thinking it might be nice to do high quality chroma up-sampling and frame stacking all in GPU, but as you point out this will not be possible. Thanks for the information.

[Zachs]

Originally Posted by RenderGuy2

Unfortunately I'm ignorant to the possibilities of render scrips. Would it be possible to write a render script that would take a 1920x1080@47.952 fps source and stack even frames over odd frames with a 45 pixel gap/border between frames? The resulting output should be 1920x2205@23.976 fps. Currently I accomplish this by performing these operations with Avisynth and just play the .avs with the player. Seems like these sorts of things could be done faster by a GPU. The point of all this is to produce an HDMI 1.4a compliant frame packed stream I can play on a 3d television. Thanks for the advice.

This is currently not possible yet as Shiandow explained. However, the ability to access the whole render queue and change a frame's presentation time stamp had been on my to-do list for some time now. It's just a matter of finding some time to implement it.

Originally Posted by harshal_rio91

The nvidia people are asking for the email from the developer stating the problem with nvidia Optimus.
I sent them a link to this forum but they want email.

Sent you a PM.

Originally Posted by Anima123

Is there developers be kind enough to write nVidia a proper bug report about the rendering time increasing when when textures are used when playing with MPDN with renderscript or renderscript chain?

It seems nVidia guys are trying to improving there drivers by addressing common bugs, I would like to take this opportunity.

The problem you're facing no one else seems to manage to replicate though - so it is going to be hard for any devs to report it to Nvidia when we don't even know how to replicate it. harshal_rio91's problem is more specific - it's simply an API function that failed silently.

[Shiandow]

Originally Posted by RenderGuy2

Shiandow, you are correct, stacking the frames takes very little CPU, however, in order to have the odd frame height (2205px) you need at least 4:2:2 chroma, so I've also been using nnedi3 to double the height of the U and V planes. This is probably overkill and uses a fair bit of CPU. I was thinking it might be nice to do high quality chroma up-sampling and frame stacking all in GPU, but as you point out this will not be possible. Thanks for the information.

I see, well you could just put them on top of each other with an even number of lines padding and then change the padding using a render script. That way you wouldn't need to double the chroma beforehand.

[Shiandow]

Originally Posted by vivan

About debanding. I've compared it - and it's not as good as madVR's f3kdb (which is very fast - my implementation takes 4ms on 720p frame on adreno 330 - mobile gpu). It's less effective while nuking a bit more details, compared to "high" in madVR. Also it shifts colors for some reason (and mpdn itself shift colors too).

Well, I've made some changes to the debanding algorithm, it's now far more effective than the old algorithm. The new algorithm is especially better at removing banding in more complicated regions (i.e. quickly varying gradients), MadVR's algorithm just seems to ignore those regions (even when set to high). You'll need to set MadVR's debanding to high to even get close to removing as much banding, but this also seems to remove more detail than the new debanding algorithm.

In short if your goal is to remove all banding while preserving as much detail as possible, I think my algorithm comes out on top. If your goal is to preserve all detail while removing as much banding as possible, then MadVR's debanding set to medium or low might be better.

[ryrynz]

Originally Posted by Shiandow

If your goal is to preserve all detail while removing as much banding as possible, then MadVR's debanding set to medium or low might be better.

Have you considered creating three quality presets like madVR?

[Anima123]

Originally Posted by Zachs

The problem you're facing no one else seems to manage to replicate though - so it is going to be hard for any devs to report it to Nvidia when we don't even know how to replicate it. harshal_rio91's problem is more specific - it's simply an API function that failed silently.

I would like to do whatever MPDN developers need me to, in order to locate the origin of this problem, like have some debug build for me to run?

Edit: My laptop are all Dell's, one XPS and one Alienware, is there someone also use a Dell's laptop that be kind enough trying to replicate my frustration?

[Zachs]

Originally Posted by Anima123

I would like to do whatever MPDN developers need me to, in order to locate the origin of this problem, like have some debug build for me to run?

Edit: My laptop are all Dell's, one XPS and one Alienware, is there someone also use a Dell's laptop that be kind enough trying to replicate my frustration?

Problem is we don't even know where to begin looking. The fact that it's not a hard failure and that it takes so long to replicate make it really hard to do anything beyond blindly stabbing at the ... shader code (I'm not even sure if that's the problem)??

BTW, did you test with the latest MPDN?