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

[Zachs]

Oh thiat reminds me. You can change the default chroma offsets in MPDN's config file. At least until someone creates a player extension that does this in a more use friendly manne.

[huhn]

Oh thiat reminds me. You can change the default chroma offsets in MPDN's config file. At least until someone creates a player extension that does this in a more use friendly manne.

doesn't it read chromaloc from x264?

[Zachs]

Any info on where I can retrieve that chromaloc from the file?

EDIT: It would appear that is x264 specific isn't it?

[nevcairiel]

The H264 spec optionally includes the chroma location. If its signaled in the bitstream, then LAV will also tell the video renderer through DXVA2_ExtendedFormat
In practice, any format that includes the information, LAV should tell you. If its not signaled, then MPEG2 position should be assumed.

In real world, content with any other position than MPEG2 is rather rare anyway.

[Zachs]

Got it. Thanks Nev!

EDIT: Tested a bunch of files and they all have 'unknown' VideoChromaSubsampling (i.e. not specified), so not sure how useful it actually is... Anyway, the default chroma offset is still available as an option in MPDN's config file (no GUI for it yet as I reckon a player extension would be best suited for this). v2.25.13 will now use the info from the bitstream if it's signaled, otherwise it'll fallback to the default value.

[Shiandow]

Cool. Are the defaults for SuperChromaRes what you would recommend for the most accurate chroma? Also do you have any test patterns at all?

I wouldn't dare call it the "most accurate" but they are what I currently use. They are almost certainly not optimal yet.

[nekromantik]

Do we still need to user SuperChromaRes if using SuperRes with NNEDI3 or NNEDI?

[Zachs]

Yes. Chroma needs to be scaled to luma size first. If you don't use it, you'll effectively be using MPDN's internal chroma scaler. There's quite a big difference in quality.

[nekromantik]

Yes. Chroma needs to be scaled to luma size first. If you don't use it, you'll effectively be using MPDN's internal chroma scaler. There's quite a big difference in quality.

Ah Makes sense.
Going to see if I can get viewable render times this weekend upscaling to 4k! Doubt it though as its a i7 laptop with 860m! My gtx760 desktop probably can but its packed away,

[BRM]

Hi again, just managed to replicate my original issue (after 5 minutes, this time):

MPDN "crashes" after a while (after roughly 35~40 mins of continuous playback). Basically the image will freeze, but the audio track will keep playing. GUI is unresponsive, but hotkeys still work (space to pause, for instance).
Don't know if it only happens in full screen.

Here are the event viewer errors: https://i.imgur.com/Odv9Wl8.png

[Zachs]

Do you still get the same problem with the latest version?

[BRM]

Do you still get the same problem with the latest version?

Well, it doesn't happen every time. I have just watched over 50 minutes of continuous video playback and it didn't crash (on the same version as before).
I will update it now though.

[mrcorbo]

When in fullscreen mode, if I bring up the menu by right-clicking and choose to exit the program, the program crashes. It doesn't matter if FSE mode is active or not and it happens even if playback is stopped.

This doesn't happen if I Alt-F4 instead.

[Garteal]

Can't reproduce that here. What are your settings?

Btw Zachs are you from the future? :p

[mrcorbo]

Can't reproduce that here. What are your settings?

I've tried to move to as generic settings as possible from my standard settings and still get the error. As of now my system/settings are:

Windows 8.1 64 bit/Radeon 270X Catalyst 15.3 beta

Enable FSE is off (have tested both on/off)
Presentation is D3D9Ex (have tested both 10.1 and 11)
New windowed mode is off (Have tested on/off)
Let DWM handle VSync is off
Render scripts are none
Dithering - No dithering (normally have set to random)
Fluid Motion Off (normally have this on)


I checked a bunch of old builds also (extracting them to an empty folder with no player extensions or renderscripts) and did find a build that didn't have this crash, but it was all they way back to 2.9.6 (build 2650) and I am missing all of the builds between there and 2.15.1 (build 2858) which has the crash, so I can't really narrow down where it broke (for me). :/

[Garteal]

Seems to be something on your end then.
What type of crash is it? MPDN handled or a "generic" Windows one?
Post the message/log here (or a screeny)? Check your event logs too for anything suspicious.

[mrcorbo]

Seems to be something on your end then.
What type of crash is it? MPDN handled or a "generic" Windows one?
Post the message/log here (or a screeny)? Check your event logs too for anything suspicious.

It's a Windows crash in nt.dll (access violation).

It's difficult to debug the error because the crash causes a black screen (a remnant of the fullscreen video playback) to stay on top of any active windows.

[Shiandow]

MPDN extensions have been updated again, some improvements to Super(Chroma)Res and also added a few hotkeys to modify chroma settings.

The changes to Super(Chroma)Res are:
- Softness now has a slightly different effect, resulting in sharper edges (although "softening" still removes some detail).
- Added softness to SuperRes, making it possible to achieve somewhat ridiculous levels of sharpness (not without risk though)
- Changed the defaults to accomodate these changes, although the defaults could probably use some improvement, I didn't have time to check all possibilities
- Setting a value to 0 disables the corresponding part of the code, so you can trade quality for performance.

I've also added 2 hotkeys for controlling chroma:
- Ctrl+Shift+L toggles the chroma levels
- Ctrl+Shift+M switches the chroma matrix
If something has been encoded well you shouldn't need to use either of them.

[BRM]

I've also added 2 hotkeys for controlling chroma:
- Ctrl+Shift+L toggles the chroma levels
- Ctrl+Shift+M switches the chroma matrix
If something has been encoded well you shouldn't need to use either of them.

How come blacks look washed out when using full range (PC 0-255), but look proper when using limited color range (16-235)? Shouldn't it be the other way around?

[Zachs]

It's a Windows crash in nt.dll (access violation).

It's difficult to debug the error because the crash causes a black screen (a remnant of the fullscreen video playback) to stay on top of any active windows.

Did you have any extensions installed at all? Perhaps try it without the extensions and see if it still happens? I've tested it on the various systems I have here as well and they all closed properly without crashing.

[Shiandow]

How come blacks look washed out when using full range (PC 0-255), but look proper when using limited color range (16-235)? Shouldn't it be the other way around?

No that's correct. It overrides the input colour space, not the output.

[mrcorbo]

Did you have any extensions installed at all? Perhaps try it without the extensions and see if it still happens? I've tested it on the various systems I have here as well and they all closed properly without crashing.

Yeah, I actually extracted all of the old builds I had downloaded to new folders and ran them, so no extensions or renderscripts were available.


I'll keep poking away at it on my end to see if I can find something on my system that may be causing it to break.

[Garteal]

Have you checked your event logs for anything useful?
Try deleting ScriptAsmCache.(32 or 64) in %localappdata%\MediaPlayerDotNet. Maybe something got corrupted there?
Heck, might aswell delete it all if that doesn't work and see if that helps.

[Zachs]

Yeah, I actually extracted all of the old builds I had downloaded to new folders and ran them, so no extensions or renderscripts were available.


I'll keep poking away at it on my end to see if I can find something on my system that may be causing it to break.

Try with the latest version - I found a problem that may have been related (not very confident it's what you're seeing though).

[Zachs]

Hi guys,

I've added an OpenCL version of the NNEDI3 render script. Since I don't have an AMD card, I've only tested it on Intel and Nvidia GPUs. It's now available on GitHub.

Cheers.

[Garteal]

Nice. I'll give it a try with my GTX970.

[ryrynz]

I've just submitted details of an out of memory bug to Zach when switching to NNEDI3 during playback in case anyone else encounters it.

Intel doesn't seem to prefer OpenCL.

[Garteal]

^ did it happen instantly or after a (short) while?

Edit: Can't reproduce that here so probably your setup.

[ryrynz]

Can replicate it instantly. Have also informed Zach about the dark screen bug when switching from NNEDI3 to OpenCL NNEDI3.
Have found out the bug mentioned in my previous post doesn't require video to be playing either.

[Zachs]

Only happens in x86 mode - doesn't happen as well if you have your decoder queue set to 16. This is a genuine out of memory error - i.e. your 32-bit app ran out of addressable memory space.

[ryrynz]

My decoder Queue is 16 and I'm running 64 bit edition, just checked.

[Zachs]

Can replicate it instantly. Have also informed Zach about the dark screen bug when switching from NNEDI3 to OpenCL NNEDI3.
Have found out the bug mentioned in my previous post doesn't require video to be playing either.

Seems to happen only on NVidia (not sure about AMD). Intel doesn't have this problem.

[Zachs]

My decoder Queue is 16 and I'm running 64 bit edition, just checked.

Can't replicate this on the 64-bit edition.

[ryrynz]

Can't replicate this on the 64-bit edition.

Kay, I'll see if I can duplicate on the Intel machine.

Only happens with New windowed mode activated.

[Anime Viewer]

Hi guys,

I've added an OpenCL version of the NNEDI3 render script. Since I don't have an AMD card, I've only tested it on Intel and Nvidia GPUs. It's now available on GitHub.

Cheers.

I tested both the original NNEDI3 and OpenCL versions with my Optimus system using the Nvidia GPU, and they both look like they work without problem. Both seem to preform equally on my system (30-32ms render times on the video I tested them both on). NEDI seems like the better performing video doubler on my system (compared to NNEDI3). NEDI renders the same video in 17-18ms on my system (nearly twice as fast as NNEDI3).

[ryrynz]

Both seem to preform equally on my system (30-32ms render times on the video I tested them both on)

The difference will be in the GPU usage.

[Zachs]

The difference will be in the GPU usage.

Actually on my 560 GTX both versions ran with similar GPU usage, with the shader version winning by the slightest margin.

[ryrynz]

Actually on my 560 GTX both versions ran with similar GPU usage, with the shader version winning by the slightest margin.

Across all neurons? I guess it's a case of YMMV aye.

[Zachs]

Across all neurons? I guess it's a case of YMMV aye.

It depends on the source resolution too. For 720p sources, OpenCL wins by the same margin. Lower resolution sources it's the other way around. And yes, that's true for all neurons.

[ryrynz]

For 720p sources, OpenCL wins by the same margin. Lower resolution sources it's the other way around

That's just begging for profiles now..

[Zachs]

That's just begging for profiles now..

That's quite easy via the custom render script (https://github.com/zachsaw/MPDN_Extensions/blob/master/Extensions/RenderScripts/Custom.MyRenderScript.cs).

For my case, it's a ~1% GPU usage difference. Like I said, slightest margin.

[Zachs]

Anyone else getting out of memory problem after switching between the two NNEDI3 versions running x64 Edition? I can't replicate the problem on my machine...

EDIT: BTW, I can't even replicate this problem on x86 Edition if I don't set my decoder queue too high.

[ryrynz]

Anyone else getting out of memory problem after switching between the two NNEDI3 versions running x64 Edition? I can't replicate the problem on my machine...

Not necessarily switching between the two NNEDI versions, just simply changing from no renderscript to either NNEDI3 version will do it, I did focus on the shader version though and I think it was more likely to happen with that.

[Zachs]

Just a heads up. I released v.16 which works around NV's blank screen / no luma problem when NNEDI3 OpenCL is used following a device reset. Let me know if this 'fixes' the problem for you (it's likely you'll still see the broken image for a split second before the proper one replaces it).

[Garteal]

^ still getting the brief black screen on my end. (GTX970)

[Zachs]

Yeah that's normal. As long as it shows the proper one after that when playback is paused, I wouldn't be to worried about it.

[Garteal]

Ah okay, I see what you guys meant now. Same issue is still present upon maximizing and resizing the window and going to fullscreen.

[Anime Viewer]

Anyone else getting out of memory problem after switching between the two NNEDI3 versions running x64 Edition? I can't replicate the problem on my machine...

EDIT: BTW, I can't even replicate this problem on x86 Edition if I don't set my decoder queue too high.

I haven't encountered it. Does it occur instantly, or after a certain amount of time with NNEDI3 running?

[Keiyakusha]

Hey guys, assuming I have a container with one audio and 2 video streams, how do I switch the video stream?

[Zachs]

Hmm it doesn't support multi video streams yet. Haven't come across any clips that contain more than one video stream. Any chance you could get me a sample?