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

[Anima123]

Within about half an hour for it to become unwatchable.

[Zachs]

I'll try to see if I could replicate it. Can you give me your exact settings for render script? Dithering and media info would be good too.

[Anima123]

Thanks Zachs.

The video resolution is 576p, 23.976 fps, target resolution is 1080p, SuperRes settings as: passes = 5; strength = 0.25; Anti-aliasing = 0.20; Anti-Ringing = 0.15; Sharpness = 0; NEDI enabled.

Dither settings as default: random dithering, with strength 2.0, colored noise and regenerate noise pattern both ticked.

Fluid motion off.

The rendering time started as around 20.60 ms after put to full-screen mode, and end with more than 42.00 ms after around 30 minutes playback.

[Blackfyre]

Thanks Zachs.

The video resolution is 576p, 23.976 fps, target resolution is 1080p, SuperRes settings as: passes = 5; strength = 0.25; Anti-aliasing = 0.20; Anti-Ringing = 0.15; Sharpness = 0; NEDI enabled.

Dither settings as default: random dithering, with strength 2.0, colored noise and regenerate noise pattern both ticked.

Fluid motion off.

The rendering time started as around 20.60 ms after put to full-screen mode, and end with more than 42.00 ms after around 30 minutes playback.

Happy new year everyone,

If it's starting at 20ms and ending at around 40ms after 30 minutes could be an issue of throttling (CPU or GPU speed automatically decreasing?)...

Have you put your laptop on High Performance mode? or is it on balanced or power saving modes? Try and run your laptop on high-performance and see if render times change?

Go to the "Control Panel" (Windows 8.1 right click on the start button at the bottom left corner and select Control Panel) then select "Power Options" then switch it to "High Performance" Mode.

You might need to click the arrow which says "Show additional plans" in the "power options".

[Zachs]

Thanks Zachs.

The video resolution is 576p, 23.976 fps, target resolution is 1080p, SuperRes settings as: passes = 5; strength = 0.25; Anti-aliasing = 0.20; Anti-Ringing = 0.15; Sharpness = 0; NEDI enabled.

Dither settings as default: random dithering, with strength 2.0, colored noise and regenerate noise pattern both ticked.

Fluid motion off.

The rendering time started as around 20.60 ms after put to full-screen mode, and end with more than 42.00 ms after around 30 minutes playback.

I just tried this on my GTX 560 but with 2 passes SuperRes (everything else unchanged). I ran a 576p, 50fps media, also to 1080p in FSE mode for 30 minutes. It started with avg render time ~17.5ms (+/- 0.25) and finished exactly the same.

I'm running x86 version on Windows 7 64-bit. Nvidia driver version 340.52.

Is anyone else experiencing this problem?

[Anima123]

Double checked with 'high performance' mode, still the same.

Could you test on a laptop, Zachs, since it might be related to the Optimus thing I guess?

[Zachs]

I don't have an Optimus laptop.

Can you test it on a desktop with Nvidia card? If the problem doesn't happen on a desktop card with the same driver then you should report the bug to Nvidia.

Have you tried the driver version I am using?

BTW, do you have to restart mpdn to get render time back down? Or does restarting playback cure it?

[Anima123]

Unfortunately I don't have a desktop to do comparison test.

Restarting playback doesn't help, the only way to get back the rendering time is to restart mpdn.

Edit: And, as I mentioned earlier, SuperRes only suffers from gradually rendering time increasing only NEDI enabled.

[Zachs]

I'm afraid there's only one plausible explanation of you need to restart MPDN.

The only thing that doesn't get recreated when you playback another media file is the direct 3d device itself. Or worse it could be keyed against a process id...

I'm not sure why only that specific settings trigger this problem. Does it help if you turn render scripts off then on again?

Do report the bug to Nvidia though since their non Optimus cards work fine and this Optimus technology is meant to be transparent.

BTW are you using dx9 or 10 as your presentation API? Could you also try resizing the window say every 30 seconds and see if that changes the behavior. Every time the target rect gets resized everything except the direct 3d device and textures that are similar in size as the source textures gets recreated.

And also try playing back a media file of a different resolution to see if that changes anything.

I'm trying to figure out if it is indeed tied to the direct 3d device because if it is, there's nothing much I could do from the player's end. This problem would manifest itself in games too if the conditions are similar.

[Anime Viewer]

Thanks Zachs.

The video resolution is 576p, 23.976 fps, target resolution is 1080p, SuperRes settings as: passes = 5; strength = 0.25; Anti-aliasing = 0.20; Anti-Ringing = 0.15; Sharpness = 0; NEDI enabled.

Dither settings as default: random dithering, with strength 2.0, colored noise and regenerate noise pattern both ticked.

Fluid motion off.

The rendering time started as around 20.60 ms after put to full-screen mode, and end with more than 42.00 ms after around 30 minutes playback.

I set all the setting you mentioned, and opened a 576p 23.976 fps file on my Windows 8.1 64-bit system with an Optimus Nvidia 680GTX gpu. I ran the video on a tv screen across an HDMI cable in extended mode. (The only video I had at that resolution was 4 minutes long). It started at 22-23ms render time and finished at that as well. During that time I never saw the current render time get higher than perhaps 33ms briefly during an ending credits. Oddly the max render time number jumped around and had strange sudden spikes where briefly it would flash something like 68ms (even though I never saw the current render time jump that high) and then would quickly jump back down into listing the max render times as being in the 20s. At the end of the clip it has reported 228 dropped frames, and 240 delayed frames (can't say I saw them visually, but then I was staring at the render times more than what was displayed on the screen).

I'll try a longer file later, and see if that behaves any differently.

CTRL+J reported that screen hz rendering the video was 59hz. What is your screen running at when playing that 23.97 fps video (29, 30, 59, 60, something else)?

Have you tried running with running with SuperRes and NEDI as separate scripts in a script chain instead of running with NEDI checked within SuperRes?
What is the file format (mp4, avi, mkv)?

Edit: the dropped and delayed frames only seem to happen at the ending credit part, and only if the video is mkv format. I played the same video in mp4 format, and it didn't have the spiking render times or the dropped and delayed frames. When I opened it in MPC-HC and launched a properties on that file (to find out what video and audio was in the mkv container it reported:
Video: MPEG4 Video (H264) 1024x576 23.976fps [V: Japanese [jpn] (h264 high 10 L5.0, yuv420p10le, 1024x576) [default]]
Audio: AAC 48000Hz stereo [A: Japanese [jpn] (aac, 48000 Hz, stereo) [default]]
Subtitle: Advanced SubStation Alpha [S: ass [default]]
Subtitle: UTF-8 [S: No subtitles]
When I did a properties on the mp4 file from MPC-BE (which doesn't have any problems) it reported:
Video: MPEG4 Video (H264) 1024x576 23.976fps 2638kbps [V: _video.h264:fps=23.976 - Imported with GPAC 0.5.1-DEV-rev4246 (h264 high L4.1, yuv420p, 1024x576, 2638 kb/s)]
Audio: AAC 48000Hz stereo 262kbps [A: _audio.aac - Imported with GPAC 0.5.1-DEV-rev4246 (aac, 48000 Hz, stereo, 262 kb/s)]
Edit: I noticed on the end credits when the problem happens with the mkv file the Decoder Queue is suddenly dropping down to 1/16 and 2/16 and the Render Queue is dropping down to 0/8 before moving back to normal and then dropping again. The avi file in the same scene maintains a constant 16/16 decoder queue and a constant 8/8 render queue.
Edit: I ran it without any scripts, and the queues and frames still reported dropped, so the problem doesn't appear script related.

[Zachs]

If the frame time stamp tells MPDN to present in quick succession all of a sudden, this will cause the render queue to be exhausted as it tries to display all those frames.

MPDN does cap it to a max of your display rate though so any additional frames will be regarded as delayed and / or dropped.

You could try remux the mkv file at fixed fps to see if that fixes the problem.

[jkauff]

I seem to remember a discussion similar to this where the render time culprit turned out to be the GPU going into power savings mode part of the way during playback. The setting is apparently not reachable through the Nvidia Control Panel. I think the original poster solved the problem by changing the power saving setting using a third party tool (might have been nTune or System Tools Utility). Worth a look, anyway.

[Anime Viewer]

I seem to remember a discussion similar to this where the render time culprit turned out to be the GPU going into power savings mode part of the way during playback. The setting is apparently not reachable through the Nvidia Control Panel. I think the original poster solved the problem by changing the power saving setting using a third party tool (might have been nTune or System Tools Utility). Worth a look, anyway.
The problem is not power saving related (at least not the issue that I detailed). I can jump straight to the credits where it happens, and right away at the same part of the video every time the same thing happens. The computer is always running in high powered state away, and is not set to restrict the GPU is any way. Its highly likely that the issue is what Zachs has identified as the frame time stamp issue.

Its also not player related, as I tossed the same video and MPC-HC (with madVR) and MPC-BE (with madVR), and they both had the issue as well. Something that was unexpected however was: When I changed the upscaler in madVR to Mitchell (which is less taxing and generally considered better for anime there was less reports of the dropped frames and high render spikes), however when I went with the MPDN equivalent (BiCubic 66) it went nuts dropping frames (adding ** to the end of the dropped frame report), and the video even stalled at parts. To confirm that scaling shouldn't have been a factor I also ran the video in its native 576p window, and it still had the queue/frame/render issue. I can't say I'm surprised to have seen the issue to occur in the other scaling and non-scaled states, but I am confused why it seemed less when Mitchell was running in madVR yet worse in MDPN with bicubic 66 (which should have been equivalent). Furthermore since they should have just been extra frames that were getting dropped it shouldn't have been visually noticeable or have caused the video to stall like it did.

If the frame time stamp tells MPDN to present in quick succession all of a sudden, this will cause the render queue to be exhausted as it tries to display all those frames.

MPDN does cap it to a max of your display rate though so any additional frames will be regarded as delayed and / or dropped.

You could try remux the mkv file at fixed fps to see if that fixes the problem.
I haven't tried remuxing the video (yet), but even if that fixes it - it would be troublesome if every time someone wants to watch an mkv video that they have to remux it first for fear that it might have this time stamp issue. There may be another solution to the problem that doesn't require converting every file someone is going to watch on their computer. Regardless I don't leave CTRL+J open and reporting when I watch videos (unless I noticed something wrong with the video playback, and want to use that as a means of troubleshooting). Since I didn't notice a visual difference (aside from when I tried bicubic 66) I'd just as well leave it as, and be unaware that whatever video I happen to be watching has a time stamp issue.

Edit: Running with Reclock active in MPC doesn't resolve the problem, but it does seem to reduce it. (Not too surprising since it changes video/auto speed, and the issue is time related). Therefore some equivalent feature if used in MPDN might work to also reduce the problem.

[Zachs]

Can you upload the sample for me to take a look? I haven't paid too much attention to handling of bad encodes to be honest.

BTW I think jkauff was replying to the render times increasing issue. Have you tried a longer clip to see if that issue occurs for you too?

[Zachs]

@AnimeViewer

I've managed to find out what is wrong with the mkv file in your PM - it's the subs. If you disable subtitle, it'll play without a problem. I /think/ it takes too much time for XySubFilter to render the subs, hence causing the drop in decoder queue. Just FYI, when MPDN displays ** for dropped frames, it means MPDN is skipping all rendering until the decoder and sub renderer catch up. Since it worked without the subs, I'd wager that it's XySubFilter that is taking too much time to render in this case.

Could you try disabling subtitle and see if that's the same for you?

[Anime Viewer]

@AnimeViewer

I've managed to find out what is wrong with the mkv file in your PM - it's the subs. If you disable subtitle, it'll play without a problem. I /think/ it takes too much time for XySubFilter to render the subs, hence causing the drop in decoder queue. Just FYI, when MPDN displays ** for dropped frames, it means MPDN is skipping all rendering until the decoder and sub renderer catch up. Since it worked without the subs, I'd wager that it's XySubFilter that is taking too much time to render in this case.

Could you try disabling subtitle and see if that's the same for you?

I didn't even think about the other version of that video was hardsubbed, and that that was why it worked as opposed to the encoding of the file itself. :o
Yep, it was the same for me. Disabling the subtitles stopped the dropped/repeated frames and max render time spikes. Out of curiosity did you try using any other subtitle render-er to see if the issue happens with any subtitle engine, or just XySubFilter? (I don't have any other subtitle systems installed at the moment, so I didn't have a chance to test it myself).


Can you upload the sample for me to take a look? I haven't paid too much attention to handling of bad encodes to be honest.

BTW I think jkauff was replying to the render times increasing issue. Have you tried a longer clip to see if that issue occurs for you too?

I ran a longer 576p video with the settings Anima mentioned using (http://forum.doom9.org/showthread.php?p=1704294#post1704294). I didn't see jkauff's post related to increased render times. Is it the same situation with 576p videos? When the video started it was ~20-24ms, about 10 minutes in it was around 28ms, around 20 minutes in it was 35ms, and at the 30 minute mark it was 34ms. At 40 minutes it was up to 40ms according to the report. Edit: At 50 minutes it was reporting 45ms and a large amount of dropped and delayed frames. The render queue was at 1/8. At 60 minutes it was at 52ms. At 70 minutes 68ms - end edit . From other videos I've watched in the past seeing videos start at less ms during the opening scene/credits is not uncommon. The 28-34 seems like not that big of a rise, or problematic to me. The video I was watching did have a lot of detail drawn in the foreground, background, and a lot of panning scenes. Later I'll try running the same video with subtitles disabled to see if that effects render times.

Edit: Testing longer video with MPC-HC and madVR to see if it has similar experience. With the way MPC-HC/madVR are currently configured on my system it starts at ~9-10ms. 10 minutes in it was at 8.53ms. At 20 minutes it was at 8.52ms. 30 minutes in 8.49ms. Since madVR doesn't seem to be experiencing the problem I'll do some testing later to see if I can rule in our out certain things in MPDN (ex: scripts, subtitles, etc).

Edit: Starting with no scripts in MPDN 7.8ms, 10 minutes in 10.66ms, 20 minutes in 12ms. I don't have time to test the rest of the video now, but I'll try to start it over and report the 30+ minute ms later.

[Zachs]

So it seems this happens regardless of render scripts, which makes more sense (although still no closer to finding out what is causing it).
Does it only happen with 576p video?

[Anima123]

No. I have tried videos with other resolutions below 1080p, all, including 720p, have the rendering time increasing issue.

[Zachs]

Are you sure it doesn't happen without RenderScripts? From AnimeViewer's reports, it would seem that it happens regardless of RenderScript settings.

[Anima123]

Are you sure it doesn't happen without RenderScripts? From AnimeViewer's reports, it would seem that it happens regardless of RenderScript settings.

I haven't noticed that yet. However I was on a business trip, so there's no way to confirm recently.

[Zachs]

When you have the chance, can you find out if there's any issues with 1080p downscaling?

Even 1080p to 1080p requires scaling of chroma. The problem should still exist, perhaps just not as rapid.

[Anima123]

Though I cannot do tests right now, for my experience, the rendering time increasing issue was not noticed when using RenderScript of SuperRes without NEDI enabled. I thought the issue only related to the specific scaling algorithm.

To make sure if it's a more fundamental issue of MPDN itself, I think we would need more testing cases.

[Zachs]

Agreed. I'll definitely need a lot more data points especially since I don't have an Optimus system to test.

[Zachs]

MPDN v2.16.0 has been released.

*** Please make sure you update your RenderScripts to the latest from GitHub as the API has changed.


v2.16.0 Changelog:
Added Direct3D 11 Presentation API (requested by Blackfyre)
Added FSE mode media duration text (requested by ryrynz)
Added the ability to change decoder queue size
Added TV range output support for TVs that do not support full range input (requested by ryrynz)
Increased render queue size to 12
Removed JPEG YUV conversion matrix (shouldn't be used)
Changes to RenderScript API
Includes custom YAXlib build with bug fixes

[ryrynz]

v2.16.0 Changelog:
Added Direct3D 11 Presentation API (requested by Blackfyre)
Added FSE mode media duration text (requested by ryrynz)
Added the ability to change decoder queue size
Added TV range output support for TVs that do not support full range input (requested by ryrynz)
Increased render queue size to 12


Some solid improvements, I've tested D3D 11 support and memory usage is slightly lower and on my 750Ti, it would seem it better adjusts the cards core frequency to suit the content too. The rendering times and present times are a tad higher on both the Intel and Nvidia Graphics in D3D 11 mode, but it would seem 11 is slightly more efficient.. so not a waste of effort there. Transition time from exclusive to windowed mode for the Intel graphics still takes takes about three seconds, maybe Intel could improve something here, Nvidia is near instant. I expect the changes to render and decoder queues will give some people more problem free playback which is nice.

When flicking between windowed and FSE modes I received an error (the picture froze and audio continued) The error was 0x887A0005 in module SharpDX.DXGI.. Device removed, device instance has been suspended.
I tried to reproduce again but couldn't. Only switched in and out a few times after having FSE mode load on start.

[Zachs]

It's a driver error. I've seen that once it twice too when testing with Nvidia card and also a hard driver crash that caused windows to reset it with Intel.

[ryrynz]

I wonder if something could be written to perform this function enough times or fast enough that the error occurred and Nvidia/Intel could fix it.. I'm not sure how easy it is to reproduce so writing something that exposes it easily could be an idea..
But maybe it just doesn't happen enough that it's much of an issue..

[Zachs]

Actually I think I've only seen it happening on Intel GPU, not Nvidia under dx11. The Nvidia one was dx10 with an older driver quite some time ago.

[Razoola]

I have given the player a try but I have a couple of issues.

Is there any reason why I get two instances of the LAV splitter in the system tray when I try this player? I have also selected the ffdshow video decoder as I wanted to give SVP a try with this player. While ffdshow does show in the filter list it does nothing and its icon does not appear in the system tray and thus SVP does not work at all. Is there something I'm missing here in how to set up the filters in this player?

Raz

[Zachs]

I have given the player a try but I have a couple of issues.

Is there any reason why I get two instances of the LAV splitter in the system tray when I try this player? I have also selected the ffdshow video decoder as I wanted to give SVP a try with this player. While ffdshow does show in the filter list it does nothing and its icon does not appear in the system tray and thus SVP does not work at all. Is there something I'm missing here in how to set up the filters in this player?

Raz

Two instance of LAV splitter is because MPDN uses separate graph for audio and video, so this is normal.

SVP definitely works - I tried it some time ago myself (still no closer to liking it though) and Blackfyre more recently got it working without much fuss too. You need to use ffdshow raw video processor not video decoder.

Do a search on this thread and you'll find some help on how to set it up as various people have documented their experience.

[Zachs]

Some solid improvements, I've tested D3D 11 support and memory usage is slightly lower and on my 750Ti, it would seem it better adjusts the cards core frequency to suit the content too. The rendering times and present times are a tad higher on both the Intel and Nvidia Graphics in D3D 11 mode, but it would seem 11 is slightly more efficient.. so not a waste of effort there. Transition time from exclusive to windowed mode for the Intel graphics still takes takes about three seconds, maybe Intel could improve something here, Nvidia is near instant. I expect the changes to render and decoder queues will give some people more problem free playback which is nice.

D3D11 seems like a massive improvement over D3D10.1 as far as transition from/to windowed <-> FSE mode goes. Impressive - it's even faster than D3D9Ex! NVidia seems to have fixed the bug too with D3D11 (or at least the bug doesn't manifest itself) with it going into FSE mode with the wrong refresh rate. And I have yet to see a bug with NVidia's driver in D3D11 mode!

[Razoola]

Two instance of LAV splitter is because MPDN uses separate graph for audio and video, so this is normal.

SVP definitely works - I tried it some time ago myself (still no closer to liking it though) and Blackfyre more recently got it working without much fuss too. You need to use ffdshow raw video processor not video decoder.

Do a search on this thread and you'll find some help on how to set it up as various people have documented their experience.

Many thanks, I got SVP to work now. I'm not sure I like it either but I want to see the kind of results it can give with UHD content or if my setup is even powerful enough to use it with UHD content.

Your player looks very nice so far btw.

[Zachs]

Many thanks, I got SVP to work now. I'm not sure I like it either but I want to see the kind of results it can give with UHD content or if my setup is even powerful enough to use it with UHD content.

Your player looks very nice so far btw.

:thanks:

Don't forget to grab player extensions and render scripts from GitHub. If you're upscaling, SuperChromaRes + SuperRes (NEDI enabled) is truly amazing (both speed and image quality wise).

[romulous]

If you're upscaling, SuperChromaRes + SuperRes (NEDI enabled) is truly amazing (both speed and image quality wise).

Working out what is pre and post in MPDN still has me a bit baffled. How do you use both those at the same time? I've gotten as far as selecting 'Script Chain' in the renderscript dialog, then clicking Configure - but I can't go any further than that.

[Zachs]

Which scalers are you looking to use? If you use SuperChromaRes then pre resize shader should come after it. Followed by SuperRes. Then post resize shader.

[romulous]

The two you said, ie SuperChromaRes + SuperRes (NEDI enabled). I think I may have managed to work it out, not 100% sure though (I'm just guessing at this stuff, I still can't tell which is pre and which is post, it would be nice if MPDN explicity said pre and post beside each entry). Need to do some screenshots I think - only tried one video so far (the same one I posted previously that caused artifacts in MPDN when I resized the player window down), and I think in fullscreen with those two enabled, it has artifacts as well (just different ones). Must be a difficult clip for MPDN for some reason.

I do note as well that MPDN still kicks you out of fullscreen if you try and open another file while in fullscreen - you did mention that though this was on purpose, you would look into an option to prevent it. Did you have a chance to do this?

[Zachs]

Yes. There's now a plethora of options that allow you to choose how you want the player to behave. Reset and resize when opening / closing media files would be the options you want to check out.

Oh you just wanted to use the two without pre resize and post resize filters? In which case, it is really simply. Just add the two into the script chain config dialog in that exact sequence.

Hopefully we will have some sort of documentation or guide soon as someone said they were going to write something up :)


Edit: regarding your corruption problem, no one else seems to be able to replicate it and really doesn't make much sense too from technical perspective unless it's memory corruption. Is you memory or GPU overclocked? Did you try updating your drivers?

[romulous]

Yes. There's now a plethora of options that allow you to choose how you want the player to behave. Reset and resize when opening / closing media files would be the options you want to check out.


Thanks, yes - disabling both those stops MPDN from kicking itself out of fullscreen mode.

Oh you just wanted to use the two without pre resize and post resize filters? In which case, it is really simply. Just add the two into the script chain config dialog in that exact sequence.

Ok, that's what I have done. I'm not really sure about the significance of pre, post and none, which leads to...

Hopefully we will have some sort of documentation or guide soon as someone said they were going to write something up :)

That is what virtually every media playback filter is missing. madVR? Great renderer - no documentation on how it works unless you want to browse 1400 pages of Doom9 thread. LAV? Great splitter, audio decoder and video decoder - same problem as madVR, though not as pronounced because it does not have nearly the same amount of cryptically named options madVR does. ffdshow, AC3Filter, I could go on naming filters who do not bother to document themselves for non-hardcore media users. I won't though - there is no point as it won't change a damn thing.

Anyway, hopefully MPDN documentation does come to fruition and does explain pre, post and none as part of it :)

Edit: regarding your corruption problem, no one else seems to be able to replicate it and really doesn't make much sense too from technical perspective unless it's memory corruption. Is you memory or GPU overclocked? Did you try updating your drivers?

No overclocking at all, on RAM, GPU or CPU. Using the latest WHQL NVIDIA drivers. I think the artifacts are definitely SuperRes related. When resizing down, you may recall that the artifacts only showed when SuperRes was enabled. Shiandow said that at that low res, SuperRes shouldn't be enabled, but I suspect there is a fault there that does mean it is enabled at resolutions it should not be.

I'm not sure about the artifacts when resizing up now. Comparing with my main player with madVR, I think I can see the same thing. It is difficult to compare two different players - MPDN does not have a screenshot function and when I use a third party screenshot app, the screenshot I get does not match what MPDN is showing. Also, MPDN does not show you which frame number you are on - it only shows a timecode. That is a problem, because due to the differences in the various video renderers, using time codes is not necessarily a reliable way to get to the same frame in two different renderers. Of course, when your screenshot app won't play ball (I guess it captures a different thing to what is on screen due to frame buffers), it is hard enough to compare a video at 100% in MPDN against the same video at fullscreen in MPDN, to see if there is any noticeable change in quality.

Anyway, crux of it is that artifacts when resizing down are definitely there for 320x240 videos, but when resizing up, may not be after all.

[Blackfyre]

MPDN v2.16.0 has been released.

*** Please make sure you update your RenderScripts to the latest from GitHub as the API has changed.


v2.16.0 Changelog:
Added Direct3D 11 Presentation API (requested by Blackfyre)
Added FSE mode media duration text (requested by ryrynz)
Added the ability to change decoder queue size
Added TV range output support for TVs that do not support full range input (requested by ryrynz)
Increased render queue size to 12
Removed JPEG YUV conversion matrix (shouldn't be used)
Changes to RenderScript API
Includes custom YAXlib build with bug fixes


Oh Zach you legend, I go away for two days and come back to this... Happy new year mate! Downloading now.

:thanks:

[Zachs]

Well time to download again :)


v2.16.3 Changelog:
Fixed bug where changes to render script settings do not take effect unless user selects another script

v2.16.2 Changelog:
Added DWM presentation glitches to Ctrl+J player stats screen (MPDN now shows desktop window manager glitches too)
Restructured player stats screen

v2.16.1 Changelog:
Fixed dialogs hiding behind main form in full screen mode


If you get any DWM presentattion glitches, it means Windows (Desktop Window Management) has essentially failed to show a frame (system wide, not just MPDN's video frame) on the screen. Usually this means it's ran out of GPU resources or a driver bug.

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

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]

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]

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.

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]

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]

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]

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.