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

[Asmodian]

After realizing G-sync activates for 3D type media players (and a friendly poke ) I decided to do some G-sync testing with MPDN.

I am happy to report that MPDN works very well with G-sync. When using any of the D3D modes and entering full screen exclusive G-sync activates and there is no flickering after startup (unlike madVR).

D3D 9Ex has really a lot of flickering right after switching to FSE but within a few seconds it settles down and looks great. A lot of dropped and delayed frames reported during startup but none after it settles down.

D3D 10.1 starts with a brief black screen, one flicker, and no dropped or delayed frames reported. Seems the same as a game starting up with G-sync.

D3D 11 seems the same as 10.1, maybe a tiny bit faster startup. Most of my further testing was done using D3D 11.

Judging motion fluidity 23.976 @ 60 Hz still looks bad, but it should given the 30 Hz lower limit for G-sync and 60 Hz is too slow to use 33.333 ms + 8.375 ms frames even if MPDN would try to do that. After startup playback is very stable and the behavior seems the same with or without fluid motion (with the exception of fluid motion improving motion at low refresh rates, of course).

I do get a crash sometimes when exiting FSE if I use the new windowed mode, leaving that unchecked I have been unable to reproduce the crash.

[Zachs]

Thank you so much for testing MPDN with G-sync, Asmodian!

I'm really curious what MPDN's display rate is reporting when G-sync is active

EDIT: Does anyone know if there's a way to detect if G-sync is active? And how do (can) you make it work under windowed mode?

[Asmodian]

Ctrl-J doesn't update the refresh rate when in G-sync unless I move the mouse and then it slowly counts down as long as I keep moving the mouse but stops at its current value as soon as I stop. I got it down to 120 something Hz from 144 Hz before getting tired, about 8 mins or so.

The power light on the monitor turns red if G-sync is active (white normally).

I understand G-sync can never be active in windowed mode. Nvidia has stressed this since the announcement. I think it has something to do with the way Windows does screen updates. I understand the mouse cursor also has issues with G-sync in that its refresh is "out of sync" with the screen's refresh so you get almost pull-down type judder in the mouse cursor. Still more parts of the OS need to become variable refresh aware.

[ryrynz]

Originally Posted by Zachs

Does anyone know if there's a way to detect if G-sync is active?

Would be good to have a G-Sync / Freesync active line in the Ctrl - J readout if you find a way to detect them.

[romulous]

I imagine this is because it is written in .NET, but is there any reason why the MPDN interface is unresponsive for a couple of seconds after you start it? So you run MediaPlayerDotNet.exe, MPDN opens up - but you can't click on any of the menus (eg View) for a couple of seconds because the Windows 'busy' icon is showing (the animated circle icon in Win 7, it was an hourglass on XP I think). Once the busy icons goes away, you can interact with the program, but I can't say that I can recall seeing any other programs off the top of my head that show a delay like this at startup.

romulous

[ryrynz]

Originally Posted by romulous

is there any reason why the MPDN interface is unresponsive for a couple of seconds after you start it?

Yeah, it's the render script system loading.. Maybe Zach can improve things a little in this area, I've noticed it myself once I installed the scripts.
Install only the player and things load up quickly.

[Zachs]

Originally Posted by ryrynz

Would be good to have a G-Sync / Freesync active line in the Ctrl - J readout if you find a way to detect them.

There's not a lot of information on G-sync / Freesync APIs at the moment. There's a lot to be done if it can be detected. However, it should be easy enough to add an option under Fluid Motion to "Enable support for G-sync / Freesync" that is manually set by the user and it only gets activated in FSE mode. That said, quite a few changes would need to be implemented to properly support variable display rate.

Originally Posted by romulous

I imagine this is because it is written in .NET, but is there any reason why the MPDN interface is unresponsive for a couple of seconds after you start it? So you run MediaPlayerDotNet.exe, MPDN opens up - but you can't click on any of the menus (eg View) for a couple of seconds because the Windows 'busy' icon is showing (the animated circle icon in Win 7, it was an hourglass on XP I think). Once the busy icons goes away, you can interact with the program, but I can't say that I can recall seeing any other programs off the top of my head that show a delay like this at startup.

romulous

It's mainly because it has to compile all the scripts and load them. This could be improved (caching compiled scripts so they don't get recompiled each time MPDN starts up) but on any modern systems, it's already quite fast so it's not a high priority for the moment.

[ryrynz]

Originally Posted by Zachs

It's mainly because it has to compile all the scripts and load them. This could be improved (caching compiled scripts so they don't get recompiled each time MPDN starts up) but on any modern systems, it's already quite fast so it's not a high priority for the moment.

I know you could simply just remove some scripts, but would a simple disable button in the renderscripts page for individual scripts (disable all you don't need) help with load performance? No point in loading them all when you're only using the one, just enable em on the fly..

[Zachs]

Originally Posted by ryrynz

I know you could simply just remove some scripts, but would a simple disable button in the renderscripts page for individual scripts (disable all you don't need) help with load performance? No point in loading them all when you're only using the one, just enable em on the fly..

I'm afraid that's not possible in the current version of .NET framework. Caching them is easy and small enough and they don't take up much memory at all. MPDN already loads all the RenderScripts in one go, so by splitting them up and dynamically loading them isn't going to be much faster. In fact, it'll use more, not less memory.

Caching them is a simple thing to do and I've been meaning to do it since when I first implemented scripting for MPDN (the comment that says "Todo: Cache compiled scripts" is still in among the code)

[romulous]

Originally Posted by ryrynz

Yeah, it's the render script system loading.. Maybe Zach can improve things a little in this area, I've noticed it myself once I installed the scripts.
Install only the player and things load up quickly.

I just tried deleting the RenderScripts folder (after setting MPDN to 'none'), and when I relaunch MPDN, it still has the delay, and it pops up an error now about the missing folder ("could not find a part of the path"). It must still look for them even if they are not present.

Edit: If I create an empty RenderScripts folder, the error disappears, but I still see a delay. Guess MPDN just does not like my system.

[ryrynz]

Originally Posted by romulous

I just tried deleting the RenderScripts folder (after setting MPDN to 'none'), and when I relaunch MPDN, it still has the delay, and it pops up an error now about the missing folder ("could not find a part of the path"). It must still look for them even if they are not present.

Edit: If I create an empty RenderScripts folder, the error disappears, but I still see a delay. Guess MPDN just does not like my system.

Curious, download the zip or re extract again into a new directory and run it and see if you still have the delay. Also is this x64, x86 or anycpu edition? on my i5 3570K a fresh x64 extraction starts up (fully usable) in about 2 seconds (and I'm not even running an SSD ATM)

[Blackfyre]

Originally Posted by Zachs

There's not a lot of information on G-sync / Freesync APIs at the moment. There's a lot to be done if it can be detected. However, it should be easy enough to add an option under Fluid Motion to "Enable support for G-sync / Freesync" that is manually set by the user and it only gets activated in FSE mode. That said, quite a few changes would need to be implemented to properly support variable display rate.



It's mainly because it has to compile all the scripts and load them. This could be improved (caching compiled scripts so they don't get recompiled each time MPDN starts up) but on any modern systems, it's already quite fast so it's not a high priority for the moment.

I've never faced this delay, not visible at all. So if it exists it's in the milliseconds and I've never noticed it. Both on a 3570K and on my current setup with a 4790K.

[Zachs]

You shouldn't delete the folder. Delete the contents, but not the folder please.

On my machine (i5-3470), without any scripts (i.e. no LinaerCustomScalers, no PlayerExtensions too), the busy cursor only shows for less than half a second.
On my 2nd gen dual core i5 laptop (2.5Ghz) with fully compiled scripts (yes you can fully compile them yourself even now if you know how to do that), the busy cursor is also only shown for less than 1 second.

EDIT: I don't have a core 2 quad / duo that old to test I'm afraid. Even my 7 years old Core 2 Duo doesn't take that long to compile, but it's running at 3.6Ghz.

[nevcairiel]

Couldn't you compile them in the background and not block the UI with it? Just need to sync to the compilation thread once playback actually wants to start and they need to be used.
That way opening a blank player at least wouldn't show the problem.

[Zachs]

There's lots I could do to speed it up like I said. It's not even multithreaded yet (the compilation part).

Anyway, caching the compiled scripts should be even faster. All there is to check is if the source files have been modified.

[Zachs]

BTW, since LAV already does dxva cb, wouldn't it be easy to do DXVA deinterlacing too?

[romulous]

Originally Posted by ryrynz

Curious, download the zip or re extract again into a new directory and run it and see if you still have the delay. Also is this x64, x86 or anycpu edition? on my i5 3570K a fresh x64 extraction starts up (fully usable) in about 2 seconds (and I'm not even running an SSD ATM)

Yeah, that does seem to have improved the delay a little (ie made it smaller - I deleted my config file as well). It was the Any CPU version.

[Zachs]

What's the frequency of your Q6600 BTW?

[romulous]

@Zachs: Here is what CPU-Z has to say:
http://i.imgur.com/qH98hu7.png

[nevcairiel]

Originally Posted by Zachs

BTW, since LAV already does dxva cb, wouldn't it be easy to do DXVA deinterlacing too?

Its possible to implement it, but I refrained from doing it since it would greatly complicate the logic and double the performance hit from CB as twice the frames would need to be copied to system memory, while a renderer can do it without this performance hit at all.

The reason CUVID and QuickSync offer it is that its just a boolean flag to enable, and not any extra code otherwise, so its an effortless option.