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

[Zachs]

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?

Fluid motion is blend FRC, except it uses extremely precise timing to get the best blends. SVP does more than that but does not use precise actual refresh rate timing. They can't be used together.

[Milardo]

So it doesn't matter about gpu? I thought it was amd tech-amd fluid motion? Does the fluid motion present in mediaplayer.net, does it make video look like its live? like your watching a real presentation?

[Zachs]

MPDN fluid motion uses the GPU for blend FRC. I'm aware AMD has their own hardware implementation but this isn't related to MPDN's fluid motion.

[Milardo]

Ok, but what is "blend frc"? How does it impact visuals on video playback?

[Zachs]

It's similar to avisynth's blend mode fps conversion, except it uses precise display refresh rate instead of a constant predefined fps.

Edit: essentially you should get more fluid playback for videos that don't match you display refresh rate.

[river1]

MPDN fluid motion uses the GPU for blend FRC. I'm aware AMD has their own hardware implementation but this isn't related to MPDN's fluid motion.
So is it possible to use AMD fluid motion video in MPDN?

[Zachs]

Nope.

[nekromantik]

Is it normal for black levels to be better with MPDN set to output Full range RBG even if TV and LAV is set to limited?
Also render times for 720 > 2160 is higher then 480 > 2160.
That cant be right can it? More work does need to be done on a SD video to upscale to 4k then a 720P video.

[Shiandow]

Is it normal for black levels to be better with MPDN set to output Full range RBG even if TV and LAV is set to limited?
Also render times for 720 > 2160 is higher then 480 > 2160.
That cant be right can it? More work does need to be done on a SD video to upscale to 4k then a 720P video.

No idea about the black levels but scaling 720 -> 2160 and 480 -> 2160 takes about the same amount of work (or at least computations).

[nekromantik]

No idea about the black levels but scaling 720 -> 2160 and 480 -> 2160 takes about the same amount of work (or at least computations).

Any idea why there is a big render time difference?
For 480 im getting 20 - 25 render time but with 720P im getting 50 - 55.

Edit:
Im using SuperChromaRes + SuperRES NNDI 3 passes.

[Zachs]

When you set MPDN to display full range but not have a corresponding display, you're essentially getting blacks and whites crushed. I.e. your TV displays 16-235 but MPDN has sent it 0-255. So anything below 16 becomes black, making it appear like it had better black levels. IOW you lose some bits per channel.

LAV tv output has no effect unless it's the one converting from YUV to RGB - MPDN does it in GPU.

[Shiandow]

Any idea why there is a big render time difference?
For 480 im getting 20 - 25 render time but with 720P im getting 50 - 55.

Edit:
Im using SuperChromaRes + SuperRES NNDI 3 passes.

Well chroma scaling would take up some time. But the biggest difference is probably with SuperRes (which behaves differently from other scaling algorithms). One of the more recent changes makes it such that rendering with large scaling factors is done in multiple steps, I think 720p -> 2160p is done in 3 steps but 480p -> 2160p is done in about 4, anyway the result of this is that the processing for 480p -> 2160p is done at a lower resolution. This might seem like a disadvantage but it's actually necessary since SuperRes doesn't work well when you scale too much in one go. It's also faster, as you've noticed. With the old version of SuperRes scaling 480p -> 2160p might take up much longer, even longer than 720p -> 2160p currently does.

@all:
The newest MPDN Extensions include a small change to the default settings for debanding, the value of "margin" is changed from 1.00 to 0.25, this value will be used from now on unless you've enabled the advanced settings. This change should preserve more detail while (hopefully) still removing all banding. Feedback on this setting would be appreciated; I'm not 100% sure if this is the lowest possible setting that still removes all banding, or if this new value is already too low. If you think it's too low do keep in mind that the "Debanding" is only supposed to remove banding, not blocking or noise, you're free to use it for that purpose but those kind of settings aren't useful as a default.

[nekromantik]

Thanks guys.

@Zachs if I select limited in MPDN and have limited set on my TV I still get the blacks that turn grey issue. Is this a problem with the TV?

[Zachs]

If that's the case your graphics card drivers may be doing the conversion to limited range before sending it out. There's a registry hack to disable that.

Otherwise you could just use full range and have the driver convert it back to limited range again.

[nekromantik]

If that's the case your graphics card drivers may be doing the conversion to limited range before sending it out. There's a registry hack to disable that.

Otherwise you could just use full range and have the driver convert it back to limited range again.


OK thanks

[Anima123]

Shiandow, does deband has different behavior for different video resolutions?

When I played 576p files with deband -> SuperRes chain, there's no problem at all, no rendering time increasing, however, when playing a lower resolution file 640x480, the same render chain will causes the familiar rendering time increasing, at least to me.

The nVidia driver is the latest, setting to prefer performance.

Edit: BTW, I already set the NoIntermediates to True.

[Zachs]

Finally managed to have a play with an Optimus 750m system today (at a friend's place). Surely nVidia must've tested the product before they sold it!? Within 5 minutes, I found so many bugs with the driver that got me absolutely gobsmacked. There's even a setup that causes it to think it's running perfectly fine when in reality it's playing video as slide show (not more than 1 fps)! It sounds great in theory, until you get into the nitty gritty of what is really needed to make it work (i.e. it's nigh impossible for nVidia to get it fully working). If anyone's looking to buy a new laptop, my advise is avoid Optimus like the plague!

[TheBean]

Just signed up to say thanks for MPDN, it's great and will probably be my primary video player now.

There's a lot of customization available with the renderscripts so I'm a bit confused -- what settings have people found that the best IQ?

The content I primarily watch is live action (no anime), 720p with a pretty decent bitrate (usually x264 @ 4000kb/s+). I've been using VLC for the past couple of years with a small amount of film grain + sharpen and full debanding and this has given me pretty good IQ.

Thanks again.

[Zachs]

Depends on whether your GPU is fast enough but the following would give you very good IQ for upscaling.

SuperChromaRes
Debanding
SuperRes (NEDI enabled)

SuperRes is sharp enough so I wouldn't think you'd need more sharpening, but if you do, you could always throw an ImageProcessor with LumaSharpen (or fine sharp) in there after SuperRes.

Cheers.

[Blackfyre]

Depends on whether your GPU is fast enough but the following would give you very good IQ for upscaling.

SuperChromaRes
Debanding
SuperRes (NEDI enabled)

SuperRes is sharp enough so I wouldn't think you'd need more sharpening, but if you do, you could always throw an ImageProcessor with LumaSharpen (or fine sharp) in there after SuperRes.

Cheers.

That depends on SVP also... If you're using SVP I'd assume it'll be very difficult to do that:

SuperChromaRes
Debanding
SuperRes (Nedi Enabled)

For example for me I do source multiplied by 4x, so if you're doing the above you're actually doing:

SuperChromaRes
Debanding
SuperRes (Nedi Enabled)
SuperChromaRes
Debanding
SuperRes (Nedi Enabled)
SuperChromaRes
Debanding
SuperRes (Nedi Enabled)
SuperChromaRes
Debanding
SuperRes (Nedi Enabled)

So I realized that's the reason why I can't handle it on my 7970. SuperChromaRes-->Debanding-->SuperRes is fine, if I'm doing them alone. But with SVP 4x Every Frame, everything is multiplied by four. But this needs to be explained...

Even though your GPU is working 4 times as much with SVP, it doesn't mean sharpening is being applied four times to the same frame, so if you have luma sharpen, it doesn't multiply by four when you run SVP@4x. But it's applying luma sharpen for every "fake" or extra frame it's making (thus multiplying gpu usage by 4x or thereof)... For example with Luma Sharpen alone GPU usage goes from 15% to 60% after enabling SVP@4xEveryFrame with my HD7970.

[Shiandow]

Shiandow, does deband has different behavior for different video resolutions?

When I played 576p files with deband -> SuperRes chain, there's no problem at all, no rendering time increasing, however, when playing a lower resolution file 640x480, the same render chain will causes the familiar rendering time increasing, at least to me.

The nVidia driver is the latest, setting to prefer performance.

Edit: BTW, I already set the NoIntermediates to True.

Deband doesn't really treat different resolutions differently, it just allocates differently sized textures. For 480p it should allocate smaller textures so I don't see why this would create a problem.

[shaolin95]

Depends on whether your GPU is fast enough but the following would give you very good IQ for upscaling.

SuperChromaRes
Debanding
SuperRes (NEDI enabled)

SuperRes is sharp enough so I wouldn't think you'd need more sharpening, but if you do, you could always throw an ImageProcessor with LumaSharpen (or fine sharp) in there after SuperRes.

Cheers.

To clarify, SuperREs (NEDI) does not kick in if you are doing 1080P bluray not scaling to anything, correct?
And Currently I am using SuperChroma Res, Debanding then LumaSharpen (tweaked to reduce the effect) and it looks great so your recommendation made me happy! :D

[Blackfyre]

To clarify, SuperREs (NEDI) does not kick in if you are doing 1080P bluray not scaling to anything, correct?
And Currently I am using SuperChroma Res, Debanding then LumaSharpen (tweaked to reduce the effect) and it looks great so your recommendation made me happy! :D

I scale up to 2560x1440, so I can't use SuperRes, it's too stressful in combination with SVP and my GPU (HD7970) can't handle it. So I use

SuperChromaRes (2 Frames)
Debanding (8 Bits)
FineSharp v1.11

+ SVP running @ 4 times source framerate:

Thus

24fps --> 96fps
25fps --> 100fps
30fps --> 120fps

60fps videos I turn off SVP which becomes redundant unless I get a 120Hz monitor and do 2x Source and run it at 120FPS.

[Anima123]

Finally managed to have a play with an Optimus 750m system today (at a friend's place). Surely nVidia must've tested the product before they sold it!? Within 5 minutes, I found so many bugs with the driver that got me absolutely gobsmacked. There's even a setup that causes it to think it's running perfectly fine when in reality it's playing video as slide show (not more than 1 fps)! It sounds great in theory, until you get into the nitty gritty of what is really needed to make it work (i.e. it's nigh impossible for nVidia to get it fully working). If anyone's looking to buy a new laptop, my advise is avoid Optimus like the plague!

Wish I knew before I bought this new laptop.

[nekromantik]

There are not many laptops without Optimus these days.
Mac's dont have optimus though.

[Zachs]

To clarify, SuperREs (NEDI) does not kick in if you are doing 1080P bluray not scaling to anything, correct?
And Currently I am using SuperChroma Res, Debanding then LumaSharpen (tweaked to reduce the effect) and it looks great so your recommendation made me happy! :D

That's correct.

[ryrynz]

Within 5 minutes, I found so many bugs with the driver that got me absolutely gobsmacked.

Hope you're submitting the bugs found to Nvidia, can't fix what they don't know is broke.

[Zachs]

Understanding the various technologies involved in making Optimus work, I can't imagine them being able to 'fix' it though. It's going to be a testing nightmare for them too seeing how reliant it is on Intel GPU drivers. Different versions of Nvidia / Intel driver combo yield different bugs.

From experience, it's hard enough to get just one driver to behave properly, let alone two from different companies who may or may not like each other.

[Anime Viewer]

Finally managed to have a play with an Optimus 750m system today (at a friend's place). Surely nVidia must've tested the product before they sold it!? Within 5 minutes, I found so many bugs with the driver that got me absolutely gobsmacked. There's even a setup that causes it to think it's running perfectly fine when in reality it's playing video as slide show (not more than 1 fps)! It sounds great in theory, until you get into the nitty gritty of what is really needed to make it work (i.e. it's nigh impossible for nVidia to get it fully working). If anyone's looking to buy a new laptop, my advise is avoid Optimus like the plague!

Question is: Did the experience give you any clues to working around some of the Optimus issues you saw, or did you find any setting changes that you'd recommend to Optimus users to get the best experience they can out of MPDN?

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

Before reading your recent post I had planned to report my Nvidia/Intel settings, and see if you had any recommendations for settings to be altered in configuration/use with MPDN. I still think that's worth a look as some of the default settings, or options people may have elected to set on their systems may not be the best settings for the MPDN program. Its also a good starting point when trying to replicate issues.

Before I post the driver/Windows settings I'm using here is the combination of settings I'm using in MPDN:

DirectShow:
Subtitle: Load Subtitles checked, Subtitle Provider: XySubFilter (version 3.1.0.705), Reduce XySubFilter subtitles aliasing checked
Video Render:
General: Decoder Queue: 60 slots, Render Queue: 32 slots (normally I would run at the default settings, but I've been using these settings to test the render queue drain and see if more slots eliminated the problem or reduced the frequency of occurrence.
Presentation: Presentation API: Direct3D 10.1 (Previously I used Direct3D 11. After the recent tests 10.1 seems to have less problems than both 11 and 9Ex, so that is what I'm using right now). Graphics Adapter ID*: 0 (1 is also an option). Back Buffer Sizes: 16 (for both)
Composition: Automatic, Full, 10-bit
Render Script:
Script Chain: SuperChromRes (I may remove this since I'm no longer using SuperRes with it) -> Deband -> NEDI in that order. In the past (until I encountered the panning smoothness bug) I used SuperChromaRes -> SuperRes, but since since SuperRes seems to be related to the issue I've substituted NEDI for the time being.
Dithering: Ordered dithering
Fluid Motion: All boxes checked (but I'm still not sure about this - since a few people have reported smoother playback with Fluid Motion unchecked)
All scalers: set to Jinc 12 Taps, all with Activate anti-ringing filter unchecked.

Nvidia control panel Manage 3D settings settings set for the MPDN program:
preferred graphics processor: High-performanace NVIDIA processor
Anisotropic filtering: Use global setting (Application-controlled)
Antialiasing - FXAA: Use global setting (Off) (*experimented with forcing On)
Antialiasing - Gamma correction: Use global setting (On)
Antialiasing - Mode: Use global setting (Application-controlled)
Antialiasing - Transparency: Use global setting (Off)
CUDA - GPUs: Use global setting (All)
Maximum pre-rendered frames: Use global setting (Use the 3D application setting)
Mutli-display/mixed-GPU acceleration: Use global setting (Multiple display performance mode)
Power management mode: Use global setting (Adaptive)
Shader Cache: Use global setting (On)
Texture filtering - Anisotropic sample optimization: Use global setting (Off)
Texture filtering - Negative LOD bias: Use global setting (Allow)
Texture filtering - Quality: Use global setting (Quality)
Texture filtering - Trilinear optimization: Use global setting (On)
Threaded optimization: Use global setting (Auto)
Triple buffering: On (this is the only thing I normally force on for applications as it provides improvement for any programs that turn Vertical sync on, and it doesn't hurt to have it on when Vsync isn't being used)
Vertical sync: Use global setting (Use the 3D application settings) (I tried with this forced to Off after the recent post about that working well on non-Optimus Nvidia GPU, but I do not see a change with it forced off).
Virtual Reality pre-rendered frames: Use global setting (1)

PhysX processor: Auto-select (recommended) (I can never understand why that is the recommended settings as I'd think the GeForce GTX 680M physX processor should always be superior to the Intel CPU).

Intel settings:
Display:
Built in display: Display Settings: Advanced: (doesn't supported advanced, so no setting are set here)
Digital Television LG TV : Display Settings: Advanced: IT Content: Enabled (thinking about setting this to disabled since I never view my work on the TV display, and only use it when watching videos).

3D:
Application Optimal Mode: Enabled
General settings: Custom Settings:
Anti-Aliasing: Use Application Settings
Anisotropic Filtering: Application Settings
Vertical Sync: Driver Settings (debating changing this to Application Settings in case the driver settings might be over riding what is set in MPDN).

Video:
Basic:
Standard Color Correction: Application Settings
Input Range: Application Settings
Advanced:
Total Color Correction: Disabled

Power: Plugged In:
Graphics Power Plans:
Maximum Performance

In general I think choosing application settings when given the choice in Windows/Nvidia/Intel settings areas is usually the best as it minimizes the chance of the driver interfering or instituting bugs that may exist at the driver level.

Any thing you'd recommend changing from the above settings?

[Zachs]

The problem with Optimus is that it is too reliant on the various driver and hardware combo (nvidia GPU + intel GPU + nvidia driver + intel driver). We found that with certain drivers on the laptop I tested with, DX11 was unusable - everything gets played as slide show, regardless of what settings you use for MPDN. The permutation of hardware/driver for both nvidia and intel is massive and there's not a lot of correlation among them. This is why I said it's nigh impossible for nvidia to properly fix it, especially when they aren't in control of intel drivers.

[Zachs]

v2.21.0 has been released.

This adds RenderScript 3D texture support API. Using this new API, it is now possible to add 3DLUT support to MPDN.

In fact, I have added an example 3DLUT RenderScript (https://github.com/zachsaw/MPDN_Extensions/blob/master/Examples/RenderScripts/Example.Lut3D.cs) to MPDN Extensions on GitHub (under Examples folder). This example does basic linear color swap (r ==> b, g ==> r, b ==> g) with values generated in the script itself. Again, not quite what you'd want to use for your daily playback but it does demonstrate a working 3DLUT.

With an open source implementation, anyone can add any 3dlut file format they need. That said, I'm looking to kick it off with support of a 3dlut format - does anyone have any preference? If so, point me to the format specs and I'll give it a go.

Lastly, if you use 3DLUT to calibrate the output you should also use deepcolor output for best image quality, so make sure you enable 10-bit or 16-bit output.

p.s. I don't have much experience in the actual usage of 3dlut, so if anyone could explain the following to me I'd appreciate it.
Do we need to have a different 3dlut for each input colorimetric (e.g. bt609/709/2020)?
Do we need to convert the pre-3dlut image to linear colour space before applying 3dlut?
I've read articles that say 65x65x65 LUT is more than enough for professional grade colour correction, why is madVR using 256x256x256?
My current thinking is 3dlut should only get applied at the end of render script chain (after resize / post processing), is that correct?

[Blackfyre]

For those of you with the older Intel CPU's... Sandy Bridge.

Key issues resolved with this driver:

VIDEO

Resolved content protection related issues when upgrading to Windows 8.1.
Resolved error, "Display driver stopped responding and has recovered", seen after closing and re-opening the laptop lid while playing video.

GAMES
CyberCIEGE* game: Some textures and objects are no longer missing.
Quake 4* game: Display no longer blanks during gameplay.
OTHER

3D screensaver such as “3D Text” no longer hangs after running for a long time.
Resolved error, “Display driver stopped responding and has recovered”, seen after unplugging a D-sub cable from a miniDisplayPort-VGA dongle while playing video.
Mouse cursor no longer disappears after the laptop lid is set to Sleep when closed, system restarted, then lid is opened.
Resolved no HDMI display (connected via a dock) seen when attempting to set Extended Display configuration.
Resolved issue where the Operating System Information in the Intel® Graphics Control Panel does not match the installed Operating System’s version.
Resolved issue where secondary display is inactive after changing the display resolution and refresh rate in Extended Display configuration.
Purpose This software driver package will install the Intel® HD Graphics Driver for:


2nd Generation Intel Core i3 Processor
2nd Generation Intel Core i5 Processor
2nd Generation Intel Core i5 vPro™ Processor
2nd Generation Intel Core i7 Processor
2nd Generation Intel Core i7 vPro™ Processor
Intel® Pentium Processor 900/B900/G600/G800 Series
Intel® Celeron Processor 700/800/B700/B800/G400/G500 Series
These drivers will not function with any other product. View the README file for installation information and the RELEASE NOTES for driver version details. This driver package contains version 15.28.23.4101 (9.17.10.4101) for Windows 7/8/8.1*.
See release notes for addition information on issues resolved and supported features.

http://www.guru3d.com/files-details/intel-hd-graphics-9-17-10-4101-driver-download.html

[Asmodian]

v2.21.0 has been released.

This adds RenderScript 3D texture support API. Using this new API, it is now possible to add 3DLUT support to MPDN.

Nice work!

With an open source implementation, anyone can add any 3dlut file format they need. That said, I'm looking to kick it off with support of a 3dlut format - does anyone have any preference? If so, point me to the format specs and I'll give it a go.


I strongly suggest the madVR 3DLUT format, it has already been implemented in a few major calibration packages such as Calman and Argyll. Argyll is open source (http://www.argyllcms.com/downloadsrc.html) so maybe it would be possible to understand its format from there?

Do we need to have a different 3dlut for each input colorimetric (e.g. bt609/709/2020)?

Need? No, but sometimes you want it.

Do we need to convert the pre-3dlut image to linear colour space before applying 3dlut?

This would depend on the LUT but I do not think so for madVR 3DLUTs.

I've read articles that say 65x65x65 LUT is more than enough for professional grade colour correction, why is madVR using 256x256x256?

I believe it is so you can simply use the LUT as a LUT, every possible input can be looked up without interpolation by madVR.

My current thinking is 3dlut should only get applied at the end of render script chain (after resize / post processing), is that correct?

Yes, that is correct.

[Anima123]

Quick seek a video file multiple times, MPDN may crash. As comparison, mpc-hc wouldn't crash on fast seek.

My best guess is that crash most like there's a problem in re-initialization of a queue after seek to a new position. Could the developers take a look at it?

Edit: To be more precise, it happened when seek to other position when the queues (don't know which, most likely the decoder queue?) are not ready yet.

[Zachs]

Quick seek a video file multiple times, MPDN may crash. As comparison, mpc-hc wouldn't crash on fast seek.

My best guess is that crash most like there's a problem in re-initialization of a queue after seek to a new position. Could the developers take a look at it?

Edit: To be more precise, it happened when seek to other position when the queues (don't know which, most likely the decoder queue?) are not ready yet.

What kind of crash is it?

[Zachs]

I strongly suggest the madVR 3DLUT format, it has already been implemented in a few major calibration packages such as Calman and Argyll. Argyll is open source (http://www.argyllcms.com/downloadsrc.html) so maybe it would be possible to understand its format from there?

<snip>


:thanks:

Sounds easy enough - that's exactly what the example render script does, except it doesn't load the values from a 3dlut file. Using a different 3dlut for each colorimetric is very easily implemented as well since the render script API already provides all the necessary info.

That said, I'll take a look at the argyllcms source to see if I can work out the file format.

[nevcairiel]

The madVR 3DLUT format is documented here:
http://sourceforge.net/projects/thr3dlut/files/doc/

[Zachs]

The madVR 3DLUT format is documented here:
http://sourceforge.net/projects/thr3dlut/files/doc/

Wow thanks! That'd save me a lot of time!

[Zachs]

Hi everyone,

I have tweaked the presentation algorithm further in v2.21.1 builds 2969, 2970 & 2971.

Can you test on your systems using Direct3D9 presenter only to see if it improves fluidity for fluid motion (state whether you're running windowed/exclusive, low/high GPU load (percentage), AMD/NVIDIA/Intel etc.) vs v2.21.0? Also which is better among the test builds?

In particular, I want to know if it makes anything worse in cases where there are no dropped / delayed frames / glitches reported. Make sure you wait until the display refresh rate (as seen in Ctrl+J screen) settles down before you do any testing.

Grab the test builds here (http://www.zachsaw.com/downloads/mpdn_test/).


Cheers.

[Anime Viewer]

Hi everyone,

I have tweaked the presentation algorithm further in v2.21.1.

Can you test on your systems using Direct3D9 presenter only to see if it improves fluidity for fluid motion (state whether you're running windowed/exclusive, low/high GPU load (percentage), AMD/NVIDIA/Intel etc.) vs v2.21.0?

In particular, I want to know if it makes anything worse in cases where there are no dropped / delayed frames / glitches reported. Make sure you wait until the display refresh rate (as seen in Ctrl+J screen) settles down before you do any testing.

Grab the test builds here (http://www.zachsaw.com/downloads/mpdn_test/).

Cheers.

I downloaded the AnyCPU build (which I've never used before, so it gave me completely fresh default settings). In its default settings things seemed to work fine, but the second I added in SuperRes script (in a chain that was SuperResChroma->Deband -> SuperRes) it immediately tanked with render queue dropping to 1/12, tons of dropped frames (no doubt caused by the queue), tons of delayed frames (no doubt caused by the queue), and high render times (77ms - again probably because of the queue going down). As you know my system is Optimus with Nvidia forced normally (however that was with it using the default Intel - since I hadn't added it to Nvidia control panel and forced the Nvidia GPU). When I forced the Nvidia GPU those same settings ran fine with 20-24ms render times. So far, so good it appears...I'll continue testing and see if the usual render queue drop when jumping to different parts of the video occurs.
For further reference it was a 848x480 video I had expanded to 1920x1080 Windowed full screen mode.

Edit: Repeating the same 1 minute scene over and over again by jumping back along the progress bar the render times continually increase until eventually dropped and delayed frames continually occur and render times are in the mid-30s. They might continue to go higher, but I stopped at that point. I'm not sure if the same occurs with the non-test previous build, but I'll do some testing to see.

Edit 2: Render time increases occur in the pretest build too, but take many more repetitions to appear. Other setting differences between the 64-bit pretest build and AnyCPU test build may be factors in the amount of repetitions it takes for dropped/delayed frames to occur, render queue to drop, and buildup rate of ms with each repeat.

[Zachs]

... and high render times (77ms - again probably because of the queue going down)

Actually it's the other way around - high render times causes queue to deplete.

Edit: Repeating the same 1 minute scene over and over again by jumping back along the progress bar the render times continually increase until eventually dropped and delayed frames continually occur and render times are in the mid-30s. They might continue to go higher, but I stopped at that point. I'm not sure if the same occurs with the non-test previous build, but I'll do some testing to see.

This might be the same Optimus bug Anima123 has encountered and that no one else seemed to be able to replicate. So for now, it would be good to side step this issue to concentrate on the intent of the test builds first.

[Anima123]

Hi everyone,

I have tweaked the presentation algorithm further in v2.21.1 builds 2969, 2970 & 2971.

Can you test on your systems using Direct3D9 presenter only to see if it improves fluidity for fluid motion (state whether you're running windowed/exclusive, low/high GPU load (percentage), AMD/NVIDIA/Intel etc.) vs v2.21.0? Also which is better among the test builds?

In particular, I want to know if it makes anything worse in cases where there are no dropped / delayed frames / glitches reported. Make sure you wait until the display refresh rate (as seen in Ctrl+J screen) settles down before you do any testing.

Grab the test builds here (http://www.zachsaw.com/downloads/mpdn_test/).


Cheers.

2969 works the best for me, almost no stutter. I am using full screen exclusive mode, with nVidia Optimus, with SuperRes, mild GPU usage, less than 40%. Also tried the other test versions, none can get comparative smoothness.

[Anime Viewer]

2969 works the best for me, almost no stutter.

Odd, that is the one I tested that had problems as soon as I set SuperRes. I haven't tried the other two builds, but I'll give them a try later.

[Zachs]

Intel GPU isn't fast enough for SuperRes. It has nothing to do with build.

[Zachs]

2969 works the best for me, almost no stutter. I am using full screen exclusive mode, with nVidia Optimus, with SuperRes, mild GPU usage, less than 40%. Also tried the other test versions, none can get comparative smoothness.
So far on all the non Optimus systems I have tested (all three vendors), 2971 is the smoothest in both FSE and windowed modes.

I'd appreciate if those with a more traditional setup could post their findings as well.

[GREG1292]

Zach ran the test build last night and was floored by the
improvements on my GTX-770. Everything seemed to work and the image was like looking through a picture window.
For me this build is exactly what my projector needed!
I wanted to add I am using Windows 10 latest preview.

Thanks

[Anime Viewer]

Intel GPU isn't fast enough for SuperRes. It has nothing to do with build.

I don't think I was fully awake when I made that post this morning. Otherwise I should have been able to rationalize that I had posted earlier about how the SuperRes instant playback problem was related to the Intel gpu being used instead of the Nvidia, and that the only Nvidia SuperRes problem is the playback jump issue.

So far on all the non Optimus systems I have tested (all three vendors), 2971 is the smoothest in both FSE and windowed modes.


2969 works the best for me, almost no stutter. I am using full screen exclusive mode, with nVidia Optimus, with SuperRes, mild GPU usage, less than 40%. Also tried the other test versions, none can get comparative smoothness.

Its difficult for me to tell if any one of the three works better for panning scenes in my test. When Fluid Motion is active for all three they all seemed to have some brief hiccup in panning during my test. With Fluid motion inactive/disabled it appeared that 2969 may have been slightly smoother (less hiccups) in my panning scene tests.

[ryrynz]

2969 works the best for me, almost no stutter.

69 seems better than 68 (2.21.0) to me. Comparing a rolling credits scene against MadVR, MPDN still has a ways to go with MadVR being completely smooth on my 750 Ti. On the Intel HD 4000 things are a lot closer, MadVR still winning by a hair, nowhere near the margin it does on the 750. Having a hard time seeing any differences between 69 & 70 on the Intel and I've noticed 71 is out so will give that a shot too.

[Zachs]

I'd appreciate it if you all could indicate whether it is in windowed or full screen exclusive mode you're testing. They have different code paths so I need to know the specifics.

[Garteal]

Some playlist extension requests.
I have pushed and implemented pretty much everything except for the docking. Go ahead and grab the latest MPDN_Extensions and test it and report if you're having issues or suggestions.

I have tweaked the presentation algorithm further in v2.21.1 builds 2969, 2970 & 2971.

Tested all test builds and all of them definitely look smoother than v2.21.0, none of (the test builds) them looks different than the other though to me. This is with FSE, getting around 30% GPU usage on a GTX970.
Video played back was 720x480(24fps) -> 1080p with SuperChroma -> Deband -> SuperRes (+NEDI enabled).