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

[Zachs]

Can't replicate the problem - which audio renderer are you using?

[ryrynz]

Originally Posted by Zachs

Can't replicate the problem - which audio renderer are you using?

I'll let you know if it happens again and I'll look into it, just using default Directsound.

Found a bug, bring up any of the filter options from the context menu and the video will pause.

[Anime Viewer]

Originally Posted by Zachs

It's not possible to know when they can be played back smoothly - it varies from system to system (a combo of driver version, vendor, monitor/TV, etc.).

BTW, could you all help and test with GPU Priority = -7 (this is essentially the renderer priority, not the presenter which is always at max) and see if that improves fluidity further?
On my systems, I found that setting it to -7 fixes a lot of the stuttering problems. Setting it too high will always fill the render queue but starve the presenter causing dropped frames when render queue is still full).

EDIT: I should mention that this only has any effect when your GPU usage is over 75%.

EDIT2: Found a couple more bugs. One is quite critical - switching in/out of FSE mode could cause back buffer not created error. The other is minor - there's one more place I needed to detect delayed frame.

My system seems to have the smoothest playback when I don't have scripts running. (NEDI doesn't seem to be a problem, and there may be others that work fine. I haven't done any extensive testing with most of the scripts.)

I've set GPU priority to -7, but I doubt it will make any difference since I never get above 47% usage.

I was watching a video, paused it near the end, went to my play list and clicked on the next episode/video in the playlist. First I got a report that the Nvidia driver crashed and recovered itself, and then I got a report that MPDN (.7 version) had stopped responding. I'm guessing its more related to the playlist and its connection to MPDN, but it could also be possible GPU priority maybe tied into it as well.

[Zachs]

GPU driver crashing will most likely crash MPDN as well since many of the DLLs it uses are directly tied to the driver.

Can you try the latest MPDN to see if it helps make playback smoother?

EDIT: I fixed a problem (workaround to be more precise) in v2.20.9 where playback seems to judder when fluid motion is enabled with render scripts being used (at least ones that shows non-negligible GPU load). This problem doesn't affect Intel GPUs. Intel seem to provide very high quality drivers these days!

[Anime Viewer]

Originally Posted by Zachs

Can you give .8 a go and see if it makes anything worse (especially playback smoothness)?

First I watched a video with Mpc-hc/madVR where I noticed some non-smoothness with the panning issues. Then I watched the same video in MPDN .8 (with NEDI and Fluid Motion both set *edit - CTRL+J showed that fluid motion was active watching this video*) and didn't notice any smoothness problems.

Originally Posted by Zachs

EDIT: I fixed a problem (workaround to be more precise) in v2.20.9 where playback seems to judder when fluid motion is enabled with render scripts being used (at least ones that shows non-negligible GPU load). This problem doesn't affect Intel GPUs. Intel seem to provide very high quality drivers these days!

Now that you've done that I'm re-enable the SuperChormaRes -> SuperRes and Fluid Motion combo, and watch the same video to see if I notice anything. *edit - I noticed less smoothness with this setting, but I think it maybe smoother than the previous versions with the same combination of settings. Turning off Fluid motion and leaving the Super chain in place made little if any difference. Re-enabling Fluid, removing the Supers, and adding in NEDI seemed to provide a pretty smooth playback, so my jerky playback (if no one else's) seem to in some way relate to having one or more of the Super render scripts active...

[Zachs]

.9 is actually a bit of an experimental build - I simply disabled v-sync to see if the problem is related to that (which it is for people with conventional GPU setup). So at least I can confirm what you're experiencing is a totally different problem - one I can't solve unfortunately as I can't replicate the problem without an Optimus laptop. In fact it would appear that different generations of Optimus hardware would have different subtle behavioural differences, but looks like most are affected by the use of SuperChromaRes/SuperRes (??)

Anyway .10 now has proper fix for those with fluid motion judder (NVIDIA / AMD card owners). Intel drivers have much better tolerances.

[Blackfyre]

Just a heads up, I doubt this is placebo but the latest version 2.20.10 (haven't updated for over a week), seems to have even less motion artifacts with SVP and DX11. So if anything, for me, the new implementations you made for DX11 Stability and decreasing motion judder issues with Fluid Motion have actually increased performance and decreased artifacts with SVP. Great job again with the last few updates.

[Zachs]

Does anyone have a sample 3dLUT file I could play with?

[Anime Viewer]

Originally Posted by Zachs

In fact it would appear that different generations of Optimus hardware would have different subtle behavioural differences, but looks like most are affected by the use of SuperChromaRes/SuperRes (??)

Upon further testing it appears its likely related to SuperRes as opposed to SuperChromaRes. With SuperRes render queue keeps dropping to 1/12 (using version .10 right now).
I'm going to increase the render queue to higher than 12, and see if that helps any.
Edit: Increasing the render queue does appear to have worked. With render queue set to the max 32 during testing it only seems to drop to 29 (3 points?) during panning scene testing (so far), where as having it set to 12 it dropped to 1 (11 points?) I'll leave it at this setting for awhile, and see if it continues to hold up.

Edit 2: correction render queue continues to drop to 1 again, but it seems it may only be happening after switching between Full Screen (Windowed) and Windowed (Default size). The queue only drops when SuperRes is active. None of the other scripts seem to drop the queue into the 1/0 range.

[Blackfyre]

Originally Posted by Anime Viewer

Upon further testing it appears its likely related to SuperRes as opposed to SuperChromaRes. With SuperRes render queue keeps dropping to 1/12 (using version .10 right now).
I'm going to increase the render queue to higher than 12, and see if that helps any.
Edit: Increasing the render queue does appear to have worked. With render queue set to the max 32 during testing it only seems to drop to 29 (3 points?) during panning scene testing (so far), where as having it set to 12 it dropped to 1 (11 points?) I'll leave it at this setting for awhile, and see if it continues to hold up.

Edit 2: correction render queue continues to drop to 1 again, but it seems it may only be happening after switching between Full Screen (Windowed) and Windowed (Default size). The queue only drops when SuperRes is active. None of the other scripts seem to drop the queue into the 1/0 range.

+1 I can confirm this too. I assumed this was a videocard issue or driver issue. SuperRes would run fine for a while then all of a sudden drop slowly towards 1, delay a few frames (between 1 and 100) then rise back up towards set value (be it 4, 8, 12, 16, or 32).

Then I assumed it was GPU throttling. But after monitoring them with MSI Afterburner turns out it's not a throttling or over-heating issue.

GPU usage does decrease by 5% from around 80% to around 75% and increase back to 80% when the delayed frames issue occurs and when render queue goes down to 1 and rise again.

Edit: I have to mention this ONLY occurs with SVP Enabled - by default SuperRes doesn't cause a decrease to 1. It remains constant at whatever value is set. BUT there is apparent stuttering in the videos. SVP smoothes the video out but the render queue has the aforementioned issue as a result.

[Zachs]

When you resize the target, render queue has to be flushed. The same applies going in and out of FSE mode as well.

[Blackfyre]

Originally Posted by Zachs

When you resize the target, render queue has to be flushed. The same applies going in and out of FSE mode as well.

Yeah but it happens to me while in FSE mode, like once every 5 minutes or so it would slowly start dropping towards 1, hits 1, then a few delayed frames happen, then it slowly rises back up towards the set value. Then it happens again 4 or 5 minutes after. It's probably an issue caused by me, but it does happen only with SuperRes.

[Zachs]

I was replying to Anime Viewer's post about render queue going to 0/1 after going in / out of full screen windowed mode. When render queue gets flushed, it needs to be refilled. The slower the algo, the slower the refill is going to be, which could explain why you're seeing low render queues for a second (or did it remain there for more than that?).

As with your problem, are you sure your card wasn't throttling performance due to thermal / power draw limits?

[Blackfyre]

Originally Posted by Zachs

As with your problem, are you sure your card wasn't throttling performance due to thermal / power draw limits?

http://i.imgur.com/WaWHhXh.png

Have a look at the image above.

Number 2 - Memory and Core Clock Speeds - Shows that throttling isn't occurring.

Number 1 - Shows where I believe the frame delays are occurring, not 100% sure that's exactly where they occurred but I think it correlates with GPU usage. Also this shows there is headroom with the GPU, it's not being stressed to the highest level (70% to 80% GPU Usage), if I increase SuperRes frames from 1 to 4 for example, GPU usage increases to around 99%+ and delayed frames increase like crazy.

This is all of-course with SVP enabled.

Number 3 - Shows GPU Memory usage, which is around 1.4GB out of my GPU's 3.0GB.

I was wondering is there a way to increase GPU Memory Usage? and Isn't VRAM faster than RAM, I wonder if we could use it or utilize it to hold the next few frames, rather than RAM for the decoder? Or it doesn't work that way? (Just a theory).

[Zachs]

Not sure what the problem is then. If it only happens once every 5 minutes, chances are it's external to MPDN since it does the same thing over and over. Does the decoder queue reduce to near zero as well when that happens? Does your render time increase all of a sudden that causes the queue to drop to zero?

[Blackfyre]

Originally Posted by Zachs

Not sure what the problem is then. If it only happens once every 5 minutes, chances are it's external to MPDN since it does the same thing over and over. Does the decoder queue reduce to near zero as well when that happens? Does your render time increase all of a sudden that causes the queue to drop to zero?

I have to pay attention to render time, I don't recall whether or not it was increasing. But I do recall decoder queue decreasing from 60 to around 50 or 40 something simultaneously with render queue. Doesn't the decoder queue dictate how much is saved in the RAM, can we increase it to 256 like Madvr? I remember it helped with MPC+Madvr

Edit: Correction Madvr Decoder goes up to 128 not 256.

[Anime Viewer]

Originally Posted by Blackfyre

Edit: I have to mention this ONLY occurs with SVP Enabled - by default SuperRes doesn't cause a decrease to 1. It remains constant at whatever value is set. BUT there is apparent stuttering in the videos. SVP smoothes the video out but the render queue has the aforementioned issue as a result.

I don't use SVP, so it has nothing to do with SVP when it occurs on my system.

Originally Posted by Zachs

I was replying to Anime Viewer's post about render queue going to 0/1 after going in / out of full screen windowed mode. When render queue gets flushed, it needs to be refilled. The slower the algo, the slower the refill is going to be, which could explain why you're seeing low render queues for a second (or did it remain there for more than that?).

It does indeed occur for more than a second. It occurs indefinitely once it starts. There are only two ways to get it to stop. First is to close MPDN, and after reopening it things work fine again until the problem is triggered again with the Windowed switching from Full Screen (windowed) to Windowed (windowed). The other is to switch to a different, or no script however the second the script is switched backed to SuperRes it immediately drops to 0/1 on the render queue again.
I'm going to test with FSE to windowed original size switching, and see if it occurs switching from those modes as well.

Edit: When opening in FSE render queues start at around 20/32 and maintain that number unless you switch out to Windowed Mode and back to FSE (or the process bar is moved to jump to another part of the video) again at which time the Render queue now displays at a lower constant (example: 20/32, or 4/32) remaining there until the progress bar is clicked to move to another part of the video (in this case to repeat the scene), or the window/full screen mode is switched by double-clicking on the video. The constant lower than full render queue is unique to FSE, and in Windowed mode it is either at 32/32 or rapidly dropped down to 1/32. Windowed mode does not run at fill rates other than full (ex: 32/32) or empty (ex:1/32). Render speeds in FSE tend to be around 32ms when things are stable.
In fullscreen windowed mode the same scenes can play anywhere from 14-20ms. When the render queue is taxed (in the 0-1 area obviously dropped frames and render times rapidly increase to higher numbers).
These tests were done in Direct3D 11 API mode. When I changed to DX9E mode, and then closed/launched the player again I got the following error message (when switching from windowed mode to FSE. It happens regardless of whether queues are set to 60/32 or 16/12. The error message only occurs when maximizing from Windowed to FSE, and not when Windowed to Windowed Full Screen). Render times are much higher in DX9e mode (30-67ms?!?):

TITLE: Mpdn.VideoFrameServices Error
------------------------------

An unexpected error 'SharpDX.SharpDXException' has occurred.

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

HRESULT: [0x8007000E], Module: [General], ApiCode: [E_OUTOFMEMORY/Out of memory], Message: Not enough storage is available to complete this operation.
 (Mpdn.VideoFrameServices)

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

&Abort
------------------------------

Direct3D 10.1 API does not generate an error like 11 does when switching to FSE.
Edit: in Direct3D 10.1 API mode it doesn't look like you have to switch from Windowed to Full Screen (any form) to get the queues to drop from full to partial or decreasing states. Clicking back on the progress bar seems to make it occur. Some times it takes a couple repetitions for it to happen. It seems to occur sooner if you have the video running and jump to a different part of the video. If you pause the video, jump, and then resume it seems to take more repetitions for it to occur.

[Milardo]

Hi is fluid motion the same as what svp can do or dmitrirender? Is it limited in anyway, or is limited by gpu? IF one uses it in combination with svp or dmitrirender, does that produce a better frame interpolation look to a video?

[Zachs]

Originally Posted by Blackfyre

I have to pay attention to render time, I don't recall whether or not it was increasing. But I do recall decoder queue decreasing from 60 to around 50 or 40 something simultaneously with render queue. Doesn't the decoder queue dictate how much is saved in the RAM, can we increase it to 256 like Madvr? I remember it helped with MPC+Madvr

Edit: Correction Madvr Decoder goes up to 128 not 256.

If render time remained the same when the queue dropped then it would appear that you've run out of system memory bandwidth. That's backed up by the fact that your decide queue also dropped at the same time.

[Zachs]

@AnimeViewer

I have tried replicating your issue in my 560gtx but have been unsuccessful. Tried on all the systems I have access to, which covers all 3 GPU vendors, except Optimus. It does feel like an Optimus specific problem.