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

[Garteal]

Nice, one Zachs as always. Going to give it a try this weekend.

[Anima123]

Unlike previous versions, from maybe 2.44.1，switch from window mode to full-screen mode, the video will flicker for several times, the last flicker almost paused the playback, no matter if the script chain is used or not.

Is it because of the on-screen algorithm display feature, and can it be optimized further more to avoid such flickers?

[Zachs]

Nice! No jarring playback lag at the start of the next file! Can the mouse cursor flash be prevented when the next file is being loaded at all? I guess windowed mode playback might be the only mode with the possibility of that happening.

Does this work alongside 'play next file in folder'? Because with that option enabled it's still a smooth start to the next file which TBH I wasn't expecting.

The lag of the current stable build happens when I start the playback of the second file in the playlist (off SSD) but not when there's only one file in the playlist and 'play next file in folder' is active.

Yeah I'm still trying to hunt down the cause of the mouse cursor appearing when transitioning from one file to another.

Current stable build doesn't have the preload mechanism. If there's a lag it's due to something else. I think the new preload implementation doesn't do anything for play next file in folder but I'm not too sure. I'll take a look when I get some time. It's more of a proof of concept at this stage. It should only preload the next item in your playlist.

Nice, one Zachs as always. Going to give it a try this weekend.

Could you take a look and see if there's anywhere else that might benefit from the new preload mechanism? Obviously as mentioned above "play next file in folder" could definitely use the same improvement. I'd restrict it to preload just one file in the background though as loading too many may cause excessive memory usage.

Unlike previous versions, from maybe 2.44.1，switch from window mode to full-screen mode, the video will flicker for several times, the last flicker almost paused the playback, no matter if the script chain is used or not.

Is it because of the on-screen algorithm display feature, and can it be optimized further more to avoid such flickers?

I don't think it's due to that. I personally haven't seen the problem though so I'm not sure what it could be. I had to "disable" Optimus recently on Win10 too since the latest drivers suffer the same problem I encountered on Win8.1, except this time it crashes Chrome instead of .NET apps. So I haven't been able to test the newer versions on Optimus systems (technically speaking my dev laptop is an Optimus system but Optimus technology isn't enabled - i.e. the NV GPU only drives an external display)

[aufkrawall]

I tried how fluid motion looks on Intel. The result is, it doesn't work there at all (Haswell, newest driver on Windows 10), frames are repeated.
madVR works. :confused:
And also with madVR on Intel I'm seeing some minor judder with smooth motion. However, this is really hard to judge since many displays aren't totally judder free.

Edit: 2.44.0 is still definitely smoother than build 3521 for me with Nvidia. Tested it with 72fps juddertest video@75Hz display.

[Anima123]

I don't think it's due to that. I personally haven't seen the problem though so I'm not sure what it could be. I had to "disable" Optimus recently on Win10 too since the latest drivers suffer the same problem I encountered on Win8.1, except this time it crashes Chrome instead of .NET apps. So I haven't been able to test the newer versions on Optimus systems (technically speaking my dev laptop is an Optimus system but Optimus technology isn't enabled - i.e. the NV GPU only drives an external display)

Now I realized it probably is related to the driver upgrade. You might want to look at the way MPDN entered FSE mode. As I tested, full-screen windows mode works fine.

[Zachs]

Going into FSE mode is very driver dependent. There is really nothing much an app has to do to go into FSE mode so not much could really go wrong. NVIDIA driver is really bad in this regard unfortunately. For example the NVIDIA has a known bug in D3D10/11 that goes into the wrong refresh rate when both AMD and Intel work fine when driving the same monitor. In fact the reports about it taking a long time to get into FSE mode is due to that bug. Only happens if you have a display that reports both 59hz and 60hz in its EDID though.

[cascardian]

Going into FSE mode is very driver dependent. There is really nothing much an app has to do to go into FSE mode so not much could really go wrong. NVIDIA driver is really bad in this regard unfortunately. For example the NVIDIA has a known bug in D3D10/11 that goes into the wrong refresh rate when both AMD and Intel work fine when driving the same monitor. In fact the reports about it taking a long time to get into FSE mode is due to that bug. Only happens if you have a display that reports both 59hz and 60hz in its EDID though.

I'm on 358.50 on a Fermi card (so WDDM 1.3 on Win10 for now) and it seems I'm affected by this with my Dell U2414H. That combination gets me a native HDMI connection only (no DP on the card, no DVI-D on the monitor) and NVIDIA is already annoying me by having to change output to Full Range every driver update, because it can't figure out this is not a TV usage case... which AMD apparently still can, despite the EDID reporting the HDTV 1080p parameters.

Anyway, the U2414H's EDID reports both 59 and 60 Hz. While in DWM mode, this seemingly translates to 60 Hz meaning true 60.00 Hz, while it changes to 59.94 in FSE mode. That leads to the following, measured within MPDN via CTRL+J (DWM VSync and new rendering path were enabled):

With 60 Hz selected in driver settings:
D3D10.1/11 in DWM: 60.00 Hz display output, 60.00 Hz composition rate.
D3D10.1/11 in FSE: 59.94, 59.94.
D3D9Ex in DWM: 60.00, 60.00.
D3D9Ex in FSE: 60.00, 59.94.

With 59 Hz selected:
D3D10.1/11 in DWM: 59.94, 59.94.
D3D10.1/11 in FSE: 59.94, 60.00.
D3D9Ex in DWM: 59.94, 59.94
D3D9Ex in FSE: 59.94, 59.94.

D3D9Ex applications in FSE mode are annoying (older games primarily), of course, because it disables f.lux.

Anyway, changing refresh rates on entering FSE mode actually takes long in both D3D9Ex and D3D10.1/11, but it might just be that this particular monitor is slow at switching, I don't know. If NVIDIA already knows about this, I wonder how long it'll take to fix it.

[nevcairiel]

FSE shouldn't really have a "composition rate" as the DWM compositor is not used in that scenario. Not sure what the second number would really represent then.

[Zachs]

I tried how fluid motion looks on Intel. The result is, it doesn't work there at all (Haswell, newest driver on Windows 10), frames are repeated.
madVR works. :confused:
And also with madVR on Intel I'm seeing some minor judder with smooth motion. However, this is really hard to judge since many displays aren't totally judder free.

Edit: 2.44.0 is still definitely smoother than build 3521 for me with Nvidia. Tested it with 72fps juddertest video@75Hz display.

P4600 on an i7 Haswell (admittedly on Win7) is one of my main development platforms so it definitely works. I also frequently test it on Broadwell (Atom) and HD3000 (both on Win10). In fact Intel gets the most attention since I have so many systems with integrated GPUs. That said, do you get the same problem with all the different source frame rates?

Anyway, changing refresh rates on entering FSE mode actually takes long in both D3D9Ex and D3D10.1/11, but it might just be that this particular monitor is slow at switching, I don't know. If NVIDIA already knows about this, I wonder how long it'll take to fix it.

NVIDIA aren't too interested in fixing bugs in the HTPC arena unfortunately. They aren't even interested in fixing their Optimus bug which crashes Chrome, Visual Studio etc. I took the time and effort to report the bugs, only to get their frontline customer service reps asking me to do nonsense tests. And when I did, they went silent (been a few months now).

FSE shouldn't really have a "composition rate" as the DWM compositor is not used in that scenario. Not sure what the second number would really represent then.

The display refresh rate reported by Windows.

[Zachs]

Can the mouse cursor flash be prevented when the next file is being loaded at all?

Should be fixed in 3525.

Edit: 2.44.0 is still definitely smoother than build 3521 for me with Nvidia. Tested it with 72fps juddertest video@75Hz display.

Build 3525 is now smoother on all my test systems vs 2.44.0. Can you try that and see if it's the same for you?

[ryrynz]

Should be fixed in 3525.


Slick. Not a mouse cursor blink or a window flash in sight.

[Garteal]

^ can you check if preloading with "Play next file in directory" works fine now if you grab the latest from my fork & playlist branch? If not, feel free to open an issue about it.

[aufkrawall]

Build 3525 is now smoother on all my test systems vs 2.44.0. Can you try that and see if it's the same for you?
OSD is logging lots of delayed frames as long as it is turned off.
Yes, when OSD is activated, it doesn't count such rendering problems.
But playback is not smooth, whether OSD is enabled or not.

[Zachs]

OSD is logging lots of delayed frames as long as it is turned off.
Yes, when OSD is activated, it doesn't count such rendering problems.
But playback is not smooth, whether OSD is enabled or not.

How are you testing it? On all of my 5 different test machines with 9 different GPUs, the latest build gives much smoother playback with fluid motion on.

@ryrynz How's fluid motion for you in this latest build?

[Shiandow]

By the way, it seems that script group hotkeys no longer work with the latest build. They'll change the settings, but I can't get MPDN to reload the renderscripts, so the settings won't be applied until you resize / play a new file.

[Zachs]

By the way, it seems that script group hotkeys no longer work with the latest build. They'll change the settings, but I can't get MPDN to reload the renderscripts, so the settings won't be applied until you resize / play a new file.

I'll investigate.

EDIT: Fixed. https://github.com/zachsaw/MPDN_Extensions/commit/1e2a874cd4081456b95e526386c8b5625c520b14

[Shiandow]

I'll investigate.

EDIT: Fixed. https://github.com/zachsaw/MPDN_Extensions/commit/1e2a874cd4081456b95e526386c8b5625c520b14

Thanks!

[Zachs]

^ can you check if preloading with "Play next file in directory" works fine now if you grab the latest from my fork & playlist branch? If not, feel free to open an issue about it.

I've made further changes and I think most (if not all) cases that we could preload files are now covered.

[ryrynz]

@ryrynz How's fluid motion for you in this latest build?

Will give it a shot when I'm home. Everything looked fine when I was checking out the file preloading.


I've made further changes and I think most (if not all) cases that we could preload files are now covered.

Cool, just had a look at the commits and saw Garteal's fix in there too, so I expect things will go smoothly. Are script conditionals still working properly now that we can preload?

[Zachs]

Cool, just had a look at the commits and saw Garteal's fix in there too, so I expect things will go smoothly. Are script conditionals still working properly now that we can preload?

The Conditional script should still work properly.

Oh and you'll need to test the latest commits with the latest MPDN test build 3526.

[ryrynz]

Oh and you'll need to test the latest commits with the latest MPDN test build 3526.

Build 3526 is giving me constant delayed frames on the Intel HD 4000 when Fluid Motion is enabled only when using D3D9. 2.44.3.3480 works fine.

[Zachs]

Build 3526 is giving me constant delayed frames on the Intel HD 4000 when Fluid Motion is enabled only when using D3D9. 2.44.3.3480 works fine.

Can you guys try Build 3528? Found and fixed a glaring mistake that was introduced in 2.44.1.

[ryrynz]

Can you guys try Build 3528? Found and fixed a glaring mistake that was introduced in 2.44.1.

All good here.

[aufkrawall]

The counter for delayed frames is unfortunately still increasing when debug OSD is closed. When it is opened again, it e.g. looks like this:
http://abload.de/thumb/15iu6a.jpg (http://abload.de/image.php?img=15iu6a.jpg)

[Zachs]

And there's no delayed frames when OSD is displayed? Did you test it in FSE mode?

[aufkrawall]

Yes (they are not reported, but I can see judder which is worse than just the monitor's judder.). In FSE, there is the same problem.

[Zachs]

Is fluidity as good as 2.44.0 though? You still get D3D glitches when playing video that has the same rate as your display right?

[Zachs]

Yes (they are not reported, but I can see judder which is worse than just the monitor's judder.). In FSE, there is the same problem.

Can you try D3D9 to see if the problem is the same?

[Anima123]

Unstopped delayed frames here with the latest test version, with both d3d9 and d3d11 with FSE. The playback is fluent to me though.

Edit: Wow, that's with Fluid Motion on. The delayed frames keep constant without Fluid Motion, at lease with d3d9.

Edit2: No delayed frames with d3d11 once Fluid Motion turned off.

It seems the delayed frames increase constantly with Fluid Motion on, unless OSD is on.

[Zachs]

Can you guys give build 3533 a try?

[ryrynz]

It seems the delayed frames increase constantly with Fluid Motion on, unless OSD is on.


Can you guys give build 3533 a try?

Can confirm this issue is fixed.

[aufkrawall]

Yes. I think now we got it as smooth again as with 2.44.0.
But I must say that I find madVR smooth motion a bit more fluid. There seems to be less erratic judder.

[Zachs]

Can you explain a bit further on what you mean by erratic judder? How often do you get this?

[Zachs]

New test build 3535 (http://mpdn.zachsaw.com/Test%20Builds/3535/) available with FluidMotion improvements. This particular one is the result of intensive testing on ATI 4350, NVIDIA 8400GS / NVS4200M / 560GTX, Intel HD3000 and HD4600 across 3 different machines and 6 different displays. There should be no more erratic jerks. Could you guys give it a go and report back please?

Cheers.

p.s. FSE mode only please - Windowed mode (DWM) is too dependent on what Windows does to be a reliable base for testing.

[aufkrawall]

Very nice work, now it's definitely smooth.
There's btw. no difference for me between FSE or windowed, even DX11 works absolutely glitch-free here.

Some questions:
What exactly does "improve chroma reconstruction" do?
I don't notice any difference whether it's off or on with render script chroma upscaling.

When we do chroma and luma upscaling via render script, main MPDN's scalers are still used for offset correction. Should bilinear be enough for this?

Unfortunately, I have a severe problem with render script level 8 API and my old script chain:
I'm just getting lots of errors with it with any file:
http://abload.de/thumb/mpdntdu7l.png (http://abload.de/image.php?img=mpdntdu7l.png)
My script:
http://pastebin.com/cpQMnqLC

[Shiandow]

SuperRes has been changed a bit to make it work better with the new API, unfortunately this change made old settings invalid. I think most other scripts somehow managed to keep working. So if you just remove all copies of SuperRes and replace them with a new one it should work.

[aufkrawall]

There must be another problem, I deleted everything except of a conditional that defines deband for native resolution and it still shows this:
http://abload.de/thumb/2fgsqp.png (http://abload.de/image.php?img=2fgsqp.png)

[Shiandow]

There must be another problem, I deleted everything except of a conditional that defines deband for native resolution and it still shows this:
http://abload.de/thumb/2fgsqp.png (http://abload.de/image.php?img=2fgsqp.png)

Seems it was not just SuperRes that didn't work then. I'll have a look what goes wrong, but there might not be an easy way to solve it.

[aufkrawall]

I was hoping the times to completely recreate the render script config would be over. :o
Not a big drama, but it may be very inconvenient for some users. :)

[Shiandow]

Not over yet, just more infrequent :(

One way to prevent it that would be worth a try is making the setting system use the default values when the config file doesn't specify one. Currently it just makes stuff up whenever it encounters an unspecified value, which is not too helpful.

Not sure what's going wrong for you though since I'm getting a somewhat different error message, might be something recent that's messing things up.

[DeadlyEmbrace]

Wow, so after ages the Remote Control finally got an update :)
The remote control now supports video tracks, opening of playlist files and URLs and the interface has finally gotten a long overdue overhaul (no more fugly! :o)

Please note that the Remote will not work with extensions v1.22.0 or below.

For the full set of release notes see https://github.com/DeadlyEmbrace/MPDN_RemoteControl/releases/tag/v1.3.0.67

Or grab the release https://github.com/DeadlyEmbrace/MPDN_RemoteControl/releases/download/v1.3.0.67/MPDNRemoteControl.zip

[burfadel]

I mentioned this in the Guru3D forums as I originally thought it was the display driver. A member there suggested I post here about it in case it's a compatibility issue with MPDN and Windows 10 TH2 build 10565+.

I have an issue that seems to be pretty random when playing MPDN in Windows 10 build 10565. It seems to cause a crash in quartz.dll (Directshow runtime) which in turn crashes the desktop explorer, which reloads quickly. If it happens to anyone else, it just looks like the taskbar is refreshing along with the icons (but it does show in event viewer). It has only happened since build 10565, which is why I believe it is Windows related. It is an Insider Preview, hence beta, so I wouldn't expect it to be perfect! I've already reported it through the Insider Preview feedback tool.

[aufkrawall]

Not over yet, just more infrequent :(

Ok, found out it's not related to my old script.
I created the deband example from above completely from the scratch and it fails as well when the conditional script is active (when ScalingFactor == 1).

[Shiandow]

As far as I can tell it was still (more or less) working at the time of my last commit, so it'd have to be a very recent bug. For now you could try using an older version of the extensions. And it would also help if you paste a copy of the minimal configuration that triggers the bug, either here or on the git repository.

[aufkrawall]

How can I get an old render script version from Github?
Simple script with error (open video file unscaled to activate conditional):
http://pastebin.com/9duy1paJ

[Shiandow]

How can I get an old render script version from Github?
Simple script with error (open video file unscaled to activate conditional):
http://pastebin.com/9duy1paJ

If you browse through the commits (https://github.com/zachsaw/MPDN_Extensions/commits/APILevel8), you can click on the "<>" button to browse the repository as it was at the time of that commit (including the commit itself). I think it was all still working at the time of my latest commit (although there have been some fixes and improvements since then) but if you want to you could reasonably quickly check at which point it stops working.

[aufkrawall]

With this commit it has been broken:
https://github.com/zachsaw/MPDN_Extensions/tree/08de818de103e1a4a15cc8430f048ad07e939fa5

[Shiandow]

Ah, yeah I think I see what went wrong, I knew something was bothering me about that commit. I'll just revert the commit for now, then it should work again. I fear the bug is a symptom of a more fundamental problem, though.

[Zachs]

Ah, yeah I think I see what went wrong, I knew something was bothering me about that commit. I'll just revert the commit for now, then it should work again. I fear the bug is a symptom of a more fundamental problem, though.

Looks like changes to Options by introducing ActiveOptions failed. Any idea why it's failing yet? I'll have a look into it anyhow.

[Shiandow]

Looks like changes to Options by introducing ActiveOptions failed. Any idea why it's failing yet? I'll have a look into it anyhow.

Probably because "Initialized()" was never called. It technically should be called whenever a RenderChain is used, but so far it's largely been ignored. Which was fine since it didn't really do anything, but then "ActiveOptions" was introduced, which was only ever intialized when "Intialized()" was called.

Edit: seems it's also initialized in the constructor, but only if "Options" isn't null, which it won't be because we're in the constructor.