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

[Shiandow]

Originally Posted by 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.

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]

Originally Posted by 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.

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!

[Blackfyre]

Originally Posted by shaolin95

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!

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]

Originally Posted by 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!

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]

Originally Posted by shaolin95

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!

That's correct.

[ryrynz]

Originally Posted by Zachs

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]

Originally Posted by 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!

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?

Originally Posted by Zachs

@AnimeViewer

I have tried replicating your issue in my 560gtx but have been unsuccessful. Tried on all the systems I have access to, which covers all 3 GPU vendors, except Optimus. It does feel like an Optimus specific problem.

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 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/...-download.html

[Asmodian]

Originally Posted by 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.

Nice work!

Originally Posted by Zachs

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 so maybe it would be possible to understand its format from there?

Originally Posted by Zachs

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

Need? No, but sometimes you want it.

Originally Posted by Zachs

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.

Originally Posted by Zachs

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.

Originally Posted by Zachs

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]

Originally Posted by 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.

What kind of crash is it?

[Zachs]

Originally Posted by Asmodian

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 so maybe it would be possible to understand its format from there?

<snip>

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]

Originally Posted by nevcairiel

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.


Cheers.

[Anime Viewer]

Originally Posted by Zachs

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.

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.