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

[Garteal]

Don't have an issue tracker yet but for the open source extensions, GitHub has one that we could use.
One for the main application itself. I'll edit or reply my findings in a bit.

Edit: scratch that. You've fixed them and I'm certain that for one the actual issue is the video file itself. MPC plays it fine though for some reason.

I've added some RenderScript examples in GitHub, so if anyone's interested to try them out, just copy the contents in Examples\RenderScripts into the Extensions\RenderScripts folder. These only serve as examples of how to do various things with render scripts, so you wouldn't want to use them in your daily video playback.

Cheers.
Awesome. Everything works fine here. I'll have to take some time to play with these.

Some playlist extension requests.

Ability to remove currently playing file from the playlist (stops the video)

Sure, can be done.

Right click context menu for the playlist (nice but no big deal, we have buttons)

I'll add this to the to-do list. Don't mind having it for completion sake.


Docking between MPDN and playlist (Not required? visual thing really which brings me to it's right angled edges vs MPDN's rounded edges)

Hmm I'll take a look at this.


Remembering previous size & window position

This is already done per instance, so I'm guessing you mean permanently saving these? If so, will take a look at it.


On file open add that file to the playlist

So an option (in the menu) to add that file to the playlist or adding any file (in any possible manner) should open it via the playlist?


Option to remember previous played file and display in playlist

Playlist file or the actual media?


Resizing the playlist window I can have the 'End chapter' just say 'End' and I have to manually resize that field to display it all.

Resizing the window really small doesn't and shouldn't make it that small. I see "End chap" minimum here. I did notice some things that have to be fixed though, so thanks for the heads-up.


I think the playlist buttons loook quite nice, thoughts on having the MPDN icons that match them? The playlist could ditch the button look and go with a highlight like the video window.
Could be an idea, will see how it'll look.

[DeadlyEmbrace]

I've been working on extending the playlist of Mpdn into something I've personally been looking for for a while.

Awesome, I love what you did with it: :thanks: Going to integrate Remote capabilities with the playlist at some point in the future so might mess around with it a little. :p

Dark Eiri - Those are the most awesome icons ever! I love them! :)

Zachs - Don't have time atm, but if no one snatches it up I might work on file association somewhere in the future, no promises though. :P

[beastbg8]

Can you please add frame-by-frame seeking?

[ryrynz]

This is already done per instance, so I'm guessing you mean permanently saving these? If so, will take a look at it.



Yup.



So an option (in the menu) to add that file to the playlist or adding any file (in any possible manner) should open it via the playlist?



You got it.



Playlist file or the actual media?



Actual media.



Resizing the window really small doesn't and shouldn't make it that small. I see "End chap" minimum here. I did notice some things that have to be fixed though, so thanks for the heads-up.



You're welcome.

Can you please add frame-by-frame seeking?

Would be great to have the frame number show in the OSD, I would no longer need ffdshow raw for that anymore, that would make MPDN a screenshot champ.

[Shiandow]

Can you please add frame-by-frame seeking?

Do Ctrl+Left, Ctrl+Right not work?

[ryrynz]

Do Ctrl+Left, Ctrl+Right not work?

works fine for me, he probably didn't know about that key combination.

[Zachs]

I've updated the Navigation extension on github to use the latest MPDN extensions API (v2.20.6) for frame stepping. It provides a much smoother stepping behaviour - i.e. try holding Ctrl+Right. Note that frame stepping is only available for forward stepping.

[Zachs]

Zachs - Don't have time atm, but if no one snatches it up I might work on file association somewhere in the future, no promises though. :P

Some research I've done thus far (for anyone else who might be interested as well):

Code reference for file association - http://www.codeproject.com/Articles/17023/System-File-Association?fid=373202&fr=26#xx0xx

You'll need to do what MPC-HC does which is run a separate exe that has admin privileges. This separate exe should be the one doing the file association, as it requires registry write access to HKEY_CLASSES_ROOT. This seems to be where MPC-HC writes its file associations as well.

[Zachs]

BTW, does anyone know if there's a problem with NVIDIA drivers with regards to DirectCompute? For some reason everything seems to work fine under my Intel GPU but not on NVIDIA. I get sudden render time spikes and image glitches with NVIDIA.

[Blackfyre]

BTW, does anyone know if there's a problem with NVIDIA drivers with regards to DirectCompute? For some reason everything seems to work fine under my Intel GPU but not on NVIDIA. I get sudden render time spikes and image glitches with NVIDIA.

I don't know Zachs, I wanted to try the examples you posted, I don't know where to add them? As image processors? when I done that, MPDN Crashed upon starting a video. So I just removed it from image processor.

[Anime Viewer]

BTW, does anyone know if there's a problem with NVIDIA drivers with regards to DirectCompute? For some reason everything seems to work fine under my Intel GPU but not on NVIDIA. I get sudden render time spikes and image glitches with NVIDIA.

madVR uses DirectCompute for some things, and while I remember madshi making patches and workaround for different things to get it working for different systems (notably ATI equipped systems) I don't recall it having problems with Nvidia gpu when he first enabled it. That being said what madVR uses DirectCompute to do, and what you are trying to have MPDN do may be two very different things.

Let me know what type of file(s) you are having the problem with, as well as when the problem (time-wise) starts to occur and I'll test it on my system.

One thing I have noticed in recent versions of MPDN is video and audio getting out of sync and scenes where panning scenes were slow and clippy (almost slideshow like) after playing for awhile. At first I thought it might be fluid motion related, but after disabling fluid motion and restarting the player/videos the out of sync problem still occurs.

My current thought is it might be render script related (SuperChromaRes -> SuperRes) related, but I haven't had a chance to test that theory yet.
Shiandow what are the default settings for SuperChromaRes and SuperRes? I've done so much troubleshooting using other people's settings that I've lost track of what is recommended and default to those scripts.

Anyone else notice video and audio loosing sync (mouths moving, but audio not coming until later) playing videos?

[Shiandow]

My current thought is it might be render script related (SuperChromaRes -> SuperRes) related, but I haven't had a chance to test that theory yet.
Shiandow what are the default settings for SuperChromaRes and SuperRes? I've so much troubleshooting using other peoples settings that I've lost track of what is recommended and default to those scripts.

Anyone else notice video and audio loosing sync playing videos?

When you add a new SuperRes of SuperChromaRes script to a script chain or preset group then they should have the default settings. Defaults for SuperRes are something like 3 passses, strength 3/4, sharpness 1/2, anti-aliasing 1/4, anti-ringing 3/4. And SuperChromaRes something similar but with less sharpness and only 2 passes.

I can't think of a reason that those scripts themselves would cause problems with smooth playback, unless the increased load on the GPU is causing issues. Although for whatever reason I also haven't been able to get playback with MPDN as smooth as with MadVR.

[Anime Viewer]

When you add a new SuperRes of SuperChromaRes script to a script chain or preset group then they should have the default settings. Defaults for SuperRes are something like 3 passses, strength 3/4, sharpness 1/2, anti-aliasing 1/4, anti-ringing 3/4. And SuperChromaRes something similar but with less sharpness and only 2 passes.


SuperChromaRes appears to have all the settings you noted except Sharpness is set to 0.15 instead of the 0.50 you noted. (Did you change it in a recent script update? I'll go update my scripts now to see if it changes that setting).
SuperRes settings are: passes 2, strength 0.80, sharpness 0.50, anti aliasing 1.00, and anti ringing 0.80 with use NEDI checked so those after being freshly added differ as well. (Going to update MPDN and script versions to most current now...)
Edit: after copying over the new version of MPDN and Extensions SuperRes now reads: Passes 3, Strength 0.75, Sharpness 0.50, Anti Aliasing 0.25, and Anti Ringing 0.75, so that did the trick to reset them. Sharpness still reads 0.15 in SuperChromaRes, so I'm guessing that is the default instead of 0.50 unless the default number is set to the wrong number.

Edit:
Zachs, etc: After copying the latest extensions folder from within the master folder on top of the latest version of MPDN 64-bit I get the following error message on launch. (I'll try recoping the extension folder again, but I'm not expecting different results).


TITLE: Error
------------------------------

An unexpected error 'Mpdn.CriticalException' has occurred.

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

One or more extensions failed to load

------------------------------

e:\Program Files\MediaPlayerDotNet\Extensions\PlayerExtensions\PlayerExtension.cs(45,27): error CS0101: The namespace 'Mpdn.PlayerExtensions' already contains a definition for 'PlayerExtension'
e:\Program Files\MediaPlayerDotNet\Extensions\PlayerExtensions\PlayerExtension.cs(47,27): error CS0101: The namespace 'Mpdn.PlayerExtensions' already contains a definition for 'PlayerExtension'
e:\Program Files\MediaPlayerDotNet\Extensions\PlayerExtensions\PlayerExtension.cs(51,27): error CS0101: The namespace 'Mpdn.PlayerExtensions' already contains a definition for 'PlayerExtension'
(CSScriptLibrary)

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

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


edit: no change after recopy. This brings up a suggestion. How about adding a way (or instructions if there is already a way) to launch in an application safe mode type state where extensions and scripts are disabled. In this launch condition all that can be done is abort, and have MPDN close. We can't get into a setting area to change possible settings. Granted people could just delete the extensions directory, and that would get them in.
Edit #2: Resolved the problem. I had to delete the old extensions directory before copying the new one over...feel like I read that before, but forgot about that step.

[Shiandow]

Some versions of script chain didn't load the default settings, so it might be that.

[Anime Viewer]

I can't think of a reason that those scripts themselves would cause problems with smooth playback, unless the increased load on the GPU is causing issues. Although for whatever reason I also haven't been able to get playback with MPDN as smooth as with MadVR.

The panning issue appears connected to the scripts/settings as I'm seeing it when SuperChromaRes and SuperRes (with NEDI enabled) are active. I wouldn't think GPU load is the issue (GPU-Z reports 9-11% load with them removed, and 44%-46% with them enabled using the Nvidia GPU). I wouldn't think that would be a high enough load to cause problems...
I'm going to try without NEDI checked, and see if that makes a difference next.

Edit: It happens without NEDI active, so NEDI doesn't appear related. I confirmed its not load related as I could run it with only SuperChromaRes running (with GPU-Z reporting 13% load), and it still had slight panning issues. However it doesn't appear to be specifically related to SuperChromaRes, as I can run with only SuperRes running by itself in the chain and it still occurs.

Edit #2: Oddly while the panning shuddering occurs every time one of those scripts is active when I'm continually dragging the progress bar back to the same area to watch a scene over and over again where there are noticeable panning problems occasional the render queue will drop to 1/12 (which of course leads to other things like dropped frames, delayed frames, etc). Odd thing is the queue doesn't always drop, and the slideshow effect during panning occurs even if the queue is 12/12. I've ruled out subtitles being related as with subtitles disabled queues still (occasionally) drop to 1/12 when repeating the same scene over and over. With the scripts disabled the queues have yet to drop that low. I've ran with just NEDI script enabled, and it doesn't seem to have the panning issue nor the queue drop issue (that I've noticed yet).

[GREG1292]

No problems with GTX-770 2GB with everything maxed out very smooth playback with Nvidia.

[Garteal]

BTW, does anyone know if there's a problem with NVIDIA drivers with regards to DirectCompute? For some reason everything seems to work fine under my Intel GPU but not on NVIDIA. I get sudden render time spikes and image glitches with NVIDIA.
Can confirm. Played a 720p video and I noticed my render time increase randomly from 6ms to 12ms. This is on a GTX970.
I don't know Zachs, I wanted to try the examples you posted, I don't know where to add them? As image processors? when I done that, MPDN Crashed upon starting a video. So I just removed it from image processor.
Do you have the latest Mpdn? Download the latest MPDN_Extensions and after you unzipped the Extensions folder to the right place (where Mpdn.exe is), unzip the Examples/RenderScripts folder (from the zip) to the Extensions/RenderScripts folder (from Mpdn).

[ryrynz]

One thing I have noticed in recent versions of MPDN is video and audio getting out of sync and scenes where panning scenes were slow and clippy (almost slideshow like) after playing for awhile. At first I thought it might be fluid motion related, but after disabling fluid motion and restarting the player/videos the out of sync problem still occurs.

Anyone else notice video and audio loosing sync (mouths moving, but audio not coming until later) playing videos?


Yup I noticed the de-sync and PM'd Zach about it, he's fixed it in 2.20.6.

I also mentioned the panning issue to him earlier and that problem is still there, and generally is more noticeable with fluid motion active.

Re-watching the same scene I'll find sometimes it's choppy & sometimes it's smooth, it occurs on all output modes and nothing I've changed seems to affect it in any way. My Intel HD 4000, behaves a lot better for some reason.

The panning issue appears connected to the scripts/settings as I'm seeing it when SuperChromaRes and SuperRes (with NEDI enabled) are active.

If you're experiencing the same issue I am then it's not related to the scripts at all, I set bicubic resizing on luma and chroma and it still occurs. It would seem to be a presentation issue, which I've mentioned to Zach a couple of times already.

[Zachs]

While I found a couple of issues that could affect smoothness in some situations, I'm not sure if it is related to what you are experiencing. Have you tried DX9Ex presenter? Using new render path instead of old / vice versa? Changing back buffer sizes?

That said, I'll be releasing a new version with the bugs I discovered. With any luck, you may find that it fixes the problem you're seeing as well!

[ryrynz]

While I found a couple of issues that could affect smoothness in some situations, I'm not sure if it is related to what you are experiencing. Have you tried DX9Ex presenter? Using new render path instead of old / vice versa? Changing back buffer sizes?

That said, I'll be releasing a new version with the bugs I discovered. With any luck, you may find that it fixes the problem you're seeing as well!

Yup, I tried everything. Will give .7 a shot.

[Shiandow]

While I found a couple of issues that could affect smoothness in some situations, I'm not sure if it is related to what you are experiencing. Have you tried DX9Ex presenter? Using new render path instead of old / vice versa? Changing back buffer sizes?

That said, I'll be releasing a new version with the bugs I discovered. With any luck, you may find that it fixes the problem you're seeing as well!

I think that did the trick :thanks:

Playback seems perfectly smooth so far using Dx9Ex in windowed mode (exclusive mode doesn't seem to make much of a difference in my case).

[ryrynz]

I think that did the trick :thanks:

Playback seems perfectly smooth so far using Dx9Ex in windowed mode (exclusive mode doesn't seem to make much of a difference in my case).

Agreed, I can't duplicate the same behavior anymore, have tested on all output API's and depths.

Zach could you improve windowed to FSE transitions? If I start playing back before it switches to FSE, it stutters. I'd like to see frames delivered only when they can be played back smoothly. If you need some usage examples let me know.

Real pleased to see those bugs fixed in .6 & .7, nice job!

[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.

[ryrynz]

Still getting a stutter or two here, the largest of which happens straight after doing a seek backwards regardless of presentation mode and window mode. Will play with buffers and render priority a bit and see what happens.

[Zachs]

Did you get delayed/dropped frames when stutter occurs? If so then it's normal (from MPDN's viewpoint) - something external is causing the delay.

[ryrynz]

Did you get delayed/dropped frames when stutter occurs? If so then it's normal (from MPDN's viewpoint) - something external is causing the delay.

Nope nothing shows on the OSD.

Tried changing everything, buffers, queues, DX output modes, render priority etc and nothing changes the stuttering. I almost thought the old windowed mode had no issues as at first it seemed smoother, but I had a stutter there too, I'm just using the left and right arrows to seek.

I have two panning scenes one almost right after the other so it's fairly easy to replicate, I might cut a sample and you can take a look and see if you can't spot the problem. Sometimes it's perfect and other times you get some small stutters or a group of medium sized ones. It's definitely better now after the latest release.

Whatever it is doesn't affect MPC-BE/madVR. I think I'll check fluid motion off and have another go.

[Zachs]

What happens if you back up much further back and see if it still stutters?
DirectShow adjusts the reference clock by a large amount when you start playing, which will cause stuttering and it's normal - just trying to rule out that possibility.

[ryrynz]

DirectShow adjusts the reference clock by a large amount when you start playing, which will cause stuttering and it's normal - just trying to rule out that possibility.

I think you may have hit the nail on the head there. It only happens within some five odd seconds of having done a seek. If that stuttering is considered normal I have to wonder how MadVR seems to get around it.
At least with Smooth Motion on, it delivers consistent results.

[Zachs]

Can you give .8 a go and see if it makes anything worse (especially playback smoothness)?
That race condition fixed should at least see going in/out of FSE mode more stable in Dx11...

[ryrynz]

Can you give .8 a go and see if it makes anything worse (especially playback smoothness)?
That race condition fixed should at least see going in/out of FSE mode more stable in Dx11...

Nothing is worse, there's still some stuttering at times after seeking and also upon initial playback as well.
Thought it might be related to the network location so tried it directly off the SSD and had a similar issue.

I'll see if I can get it happening again, I didn't check if it showed delayed/dropped frames.

Changing from windowed mode to FSE is pretty awesome now.

Could be imagining it, but video seems a little bit smoother.

[Zachs]

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

[ryrynz]

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]

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]

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.


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]

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]

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]

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]

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]

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]

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.

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]

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.