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

[Zachs]

What about audio renderer? Using the default directsound?
I'm out of ideas, seeing as I can play it without any troubles. I have yet to encounter a file that would hard crash MPDN.

[romulous]

Yep, default audio renderer. I have no ideas either, it is very strange.

[Zachs]

Perhaps try updating your LAV filters to the latest version?
Does it only crash with this particular file?

[romulous]

Already using the latest LAV (just set to software decoding, no hardware acceleration). This was the first file that MPDN crashed on that I had found - but I have since found another that causes problems. It's not the same crash, but MPDN hangs instead:
http://forum.doom9.org/showpost.php?p=1701865&postcount=701

For what it is worth, here is the report from Windows Action Center (for the crash, not the hang):

Problem signature
Problem Event Name: APPCRASH
Application Name: MediaPlayerDotNet.exe
Application Version: 2.12.4.2808
Application Timestamp: 5483baf5
Fault Module Name: VideoFrameServicesNative.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 5428e6cc
Exception Code: c000001d
Exception Offset: 00000000000014d7
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 3081
Additional Information 1: 237f
Additional Information 2: 237f43c2238b444448f2ca41ae9944ef
Additional Information 3: 5b72
Additional Information 4: 5b7284c99f1b466f036e33b40ef09d7f

[Anime Viewer]

I have a test file (download link below) that instantly crashes MPDN on my system (no render scripts in use):
https://mega.co.nz/#!YMAwwTja!blxHH99-7dEPBTxncUUw4SwULDZqUEEYjU7Y80C46DI

It's an 800MB ProRes encoded game trailer. So I just go file->open, select the file and click ok, and a couple of seconds later, MPDN crashes.

romulous

The game trailer plays fine on my system using MPDN.

Already using the latest LAV (just set to software decoding, no hardware acceleration). This was the first file that MPDN crashed on that I had found - but I have since found another that causes problems. It's not the same crash, but MPDN hangs instead:
http://forum.doom9.org/showpost.php?p=1701865&postcount=701



Your 55mb file crashes on my system too, but not just with MPDN, but other video players as well (MPC-HC). MPC-HC generates a crash dump report. You should open it with MPC-HC and submit the crash dump that way you have another means of researching the crash to find out what is causing it.

[Shiandow]

Shiandow, could you please double-check your implementation of the SuperRes serie algorithms? I still believe there's something wrong within it, the symptom is that rendering time will increase gradually until my GPU (nVidia 640M) cannot handle it (noticed by a lot of dropped frames).

Maybe it is due to my weak GPU that reveals some potential bugs, while for a stronger GPU, it will always be enough power left after playback of a 2 hours movie.

Edit: To be more specific, after more testing, it was found that the behavior of SuperChromaRes is quite stable, and does not suffer from rendering time increase at all.

Actually, it was SuperNEDIRes I was talking about that suffers from gradually increasing of rendering time.

That's odd. I haven't noticed anything like that. Could you try running DebugView (http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx) and see if that turns up anything interesting?

[Anima123]

BTW, I was running 64-bit MPDN, can DebugView handle 64-bit too?

Edit: Please check the dropbox log files: https://www.dropbox.com/s/uhtl4sk1j3pkfbw/MPDN_SuperNEDIRes.LOG?dl=0

[Shiandow]

Well those "Frame dropped" errors are definitely from MPDN so it is logging something but unfortunately it's not logging much else. Whatever is happening doesn't seem to be causing errors, which also means that it's unlikely to be a mistake in SuperNEDIRes but it could be a mistake in some of the other renderscript code. Or it could be related to the hardware, especially since SuperNEDIRes is the most demanding of all SuperRes scripts. Any chance that the GPU is getting hot or running out of memory?

[Anima123]

That has been into my consideration, util I found using SuperChromaRes when watching 1080p videos also demanding, the fan is more active than using SuperNEDIRes, yet without such problems.

It seems to me, that the implementation of SuperNEDIRes seems to suffer from some kind of resource leak or something else similar.

I have to disagree with you on the hardware problem, since SuperNEDIRes works just fine in the beginning, even it's demanding, and as a comparison, SuperChromaRes works steady like a charm.

I will try SuperRes later to see if it has similar behavior as SuperNEDIRes.

Edit: Shiandow, once you have idea on debugging further with this problem, please don't hesitate to let me know.

[Shiandow]

Edit: Shiandow, once you have idea on debugging further with this problem, please don't hesitate to let me know.

Well, you could run some utility like GPU-Z to check if anything weird happens to GPU usage / GPU memory usage or anything else. And maybe check CPU usage / RAM usage as well for good measure. That should at least give a rough idea of where the problem is. But if those are all stable then there's not much else I can think of, unless someone figures out a way to reproduce the problem.

[Anima123]

Just tried with GPU-Z, nothing peculiar found. The 640M has 2GB memory, only 400M or so used by MPDN, and the GPU load was about 64% with some kind of fluctuations, temperature around 65 degrees, all seems normal.

Anyone else experienced similar phenomenon?

[Zachs]

Problem signature
Problem Event Name: APPCRASH
Application Name: MediaPlayerDotNet.exe
Application Version: 2.12.4.2808
Application Timestamp: 5483baf5
Fault Module Name: VideoFrameServicesNative.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 5428e6cc
Exception Code: c000001d
Exception Offset: 00000000000014d7
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 3081
Additional Information 1: 237f
Additional Information 2: 237f43c2238b444448f2ca41ae9944ef
Additional Information 3: 5b72
Additional Information 4: 5b7284c99f1b466f036e33b40ef09d7f


Exception code c000001d is caused by an attempt to execute instruction that is not supported by your CPU (or it could be simply bad opcode).

This could be due to a couple of things: corrupt DLL file (VideoFrameServicesNative.dll) or your CPU indeed doesn't support an asm instruction I used.

So this begs the question: What CPU are you using?

In the meantime, try redownloading MPDN and verify against its corresponding MD5.

EDIT: The faulting address isn't even an SSE2 instruction - it's a simple xor eax,eax!

[Zachs]

Just tried with GPU-Z, nothing peculiar found. The 640M has 2GB memory, only 400M or so used by MPDN, and the GPU load was about 64% with some kind of fluctuations, temperature around 65 degrees, all seems normal.

Anyone else experienced similar phenomenon?

This is really odd. Perhaps try disabling NVIDIA GPU and run just with the IGP to see if the problem persists? That will rule out NVIDIA driver problems. I know it'll be slow but you should at least get relatively consistent render times.

[Anima123]

Zachs, you're right about it. After revert to the vendor's video driver, instead of the nVidia's latest, all seems right.

Sorry for the false alarm.

[romulous]

So this begs the question: What CPU are you using?


It's an original Intel Q6600 (quad core).

In the meantime, try redownloading MPDN and verify against its corresponding MD5.

I shall download again just to be sure, but the archiver threw no errors when opening the zip files.

[romulous]

Ok, re-downloaded, verified the md5, but no change. No idea why it only appears to crash on my system :(

ehat

[Zachs]

That's just really odd. The assembly instruction that caused it to crash was nothing special too! Xor eax,eax is as old as it gets and runs on 80386!

Anyone else has a core 2 cpu of that generation and face the same problem?

EDIT: MD5 of VideoFrameServicesNative.dll

b2bb9d95c4f685f3251574b24c0a2d4c

[Zachs]

Ah ha! Found the problem.

I have inadvertently used an SSE4.1 instruction! :eek:

BTW, the crash info you gave is for 64-bit edition. I kept thinking it was for 32-bit.

[romulous]

Ah, I wasn't sure what edition it was that I copied that report from to be honest. Both 32bit and 64bit had crashed, and I simply opened up the latest report in Control Panel. Good to hear you tracked down the problem though :)

[Zachs]

Ah, I wasn't sure what edition it was that I copied that report from to be honest. Both 32bit and 64bit had crashed, and I simply opened up the latest report in Control Panel. Good to hear you tracked down the problem though :)

...and fixed in 2.12.5. :)

[romulous]

...and fixed in 2.12.5. :)

Can confirm that MPDN does not crash now. After all that - performance on my system with that clip and MPDN is awful! There are so many dropped frames, MPDN reports a *** after the number! Sigh - if it isn't one thing, it is another (my main player uses the exact same LAV install with madVR, and not a single dropped frame unless I enter FSE with madVR). Oh well, the crash is gone, that is the main thing.

[Zachs]

What's your GPU and CPU usage like?

Edit: this clip can't be decoded on the GPU (tried both cuvid and quicksync) and MPDN doesn't support dxva so that may explain the difference.

[romulous]

Overall CPU usage is between 45% to 50%. GPU usage:
http://i.imgur.com/5cNdF7t.gif

Before this, I had not touched the MPDN defaults - so no renderscripts, and everything was set to whatever the default was (softcubic I think). For this test, I disabled dithering, and set everything to bilinear. Didn't seem to make any difference. Even resizing MPDN down to about 320x240 does not help - it is a slideshow either way.

romulous

Edit: Even enabling hardware acceleration in LAV Video does not help.

[Zachs]

Try playing back on your main player with dxva disabled and you'll probably get the same stats.

BTW anyone knows why this clip causes LAV to use avcodec instead of cuvid or quicksync? It's a P010 clip so that may be the reason but can dxva decode it?

[romulous]

Nope, main player works fine with LAV set to software decoding (which is how I run normally). One single dropped frame - and that was caused when I went from windowed to fullscreen mode. It's purely MPDN only I'm afraid.

Edit: Had a theory it may have been audio related, as my main player was not using LAV Audio (was using LAV Splitter, LAV Video and madVR). So told it to use LAV Audio as well - no change, still works perfectly there. Just don't understand why MPDN set to bilinear for everything can't even handle it at ultra low window size, yet I can use madVR at fullscreen on my main player with algorithms that take considerably more power (such as Lanczos and Jinc) with zero problems.

[Zachs]

I don't think this has anything to do with GPU.

Try disabling p010 & p016 outputs on LAV video decoder. See if it makes any difference.

[romulous]

Yes, that fixed it. So that begs the question - why does having those checked not cause problems for my main player, but does for MPDN?

[Asmodian]

BTW anyone knows why this clip causes LAV to use avcodec instead of cuvid or quicksync? It's a P010 clip so that may be the reason but can dxva decode it?

None of the hardware decoders support anything other than 8-bit. No DXVA for P010.

Yes, that fixed it. So that begs the question - why does having those checked not cause problems for my main player, but does for MPDN?

Could it be GPU memory related? I am not sure what the GPU memory footprint of MPDN is but running out of memory can cause terrible performance.

[Zachs]

Yes, that fixed it. So that begs the question - why does having those checked not cause problems for my main player, but does for MPDN?

Well, that narrows it down to the P010 / P016 code branch, which is good. What is your CPU usage like when you uncheck those boxes?

[pirlouy]

@Zachs: I see you are interested in image improvement. Are you also interested in motion improvement ? For example, Madshi has created an algorithm to avoid 3:2 pulldown. In general I don't see differences between bilinear and Jinc, but I really see a difference between 3:2 pulldown and Madshi excellent smooth motion.

I wonder if you also had an algorithm in mind for this problem. FYI, I can't change refresh rate (60Hz).

[Zachs]

The blend version of FRC isn't hard to implement (MPDN has a render queue that can quite easily enable this), just haven't got around to implementing it. (My TV does 23.976Hz natively so that's why I haven't made it a top priority)

[Zachs]

Yes, that fixed it. So that begs the question - why does having those checked not cause problems for my main player, but does for MPDN?

Well, P210 format isn't supported by MPDN natively (yet).
Like in my initial suspicion, the high CPU usage isn't in MPDN. It's because P210 needs to be converted to P016 first before MPDN can accept it. I suspect LAV is more efficient in converting P210 to NV12 / YV12.

I probably mentioned this before but I'll say it again, I'll implement the various input formats when I run out of pressing issues to fix and higher priority stuff to implement. There just isn't a lot of media with those input formats out there that is worth investing my time into just yet.

[romulous]

I probably mentioned this before but I'll say it again, I'll implement the various input formats when I run out of pressing issues to fix and higher priority stuff to implement. There just isn't a lot of media with those input formats out there that is worth investing my time into just yet.

Ah, ok - future player improvement. Gotcha.

[Zachs]

Yes. You could see from the OP MPDN only supports yv12 nv12 p010 & p016 natively.

BTW what percentage would you say your clips are made up of non yuv 4:2:0 formats?

[romulous]

Yes. You could see from the OP MPDN only supports yv12 nv12 p010 & p016 natively.

Ah, no idea what they even are.

BTW what percentage would you say your clips are made up of non yuv 4:2:0 formats?

I have no idea, I have seen references to 4:2:0 but as with po10 and po16, have no idea what it is.

[Zachs]

BTW does anyone know where I could find test clips of the various formats?

[huhn]

nv12/yv12 = 8bit 4:2:0
p010 = 10 bit 4:2:0
p016= 16 bit 4:2:0
p210= 10 bit 4:2:2

[cyberbeing]

You can find various codec samples at:
http://samples.mplayerhq.hu/V-codecs/

Though if you just force LAV Video to output the color format you want to test (disable all others), that should already cover most anything you'd want to support.

[Zachs]

Ah thanks! Didn't think of that lol

[Zachs]

Does anyone happen to know the matrix for RGB to YUV conversion for both PC.601 and PC.709?

[patul]

Does anyone happen to know the matrix for RGB to YUV conversion for both PC.601 and PC.709?

http://en.wikipedia.org/wiki/YUV
http://www.equasys.de/colorconversion.html

[Shiandow]

Does anyone happen to know the matrix for RGB to YUV conversion for both PC.601 and PC.709?

The exact matrices are given by the following:

RGB -> YUV:
{{Kr , 1-Kb-Kr , Kb},
{-(1/2)Kr/(1-Kb), -(1/2)(1-Kb-Kr)/(1-Kb), 1/2},
{ (1/2) , -(1/2)(1-Kb-Kr)/(1-Kr),-(1/2)Kb/(1-Kr)}}

YUV -> RGB:
{{1, 0 , 2(1-Kr)},
{1,-2(1-Kb)Kb/(1-Kb-Kr),-2(1-Kr)Kr/(1-Kb-Kr)},
{1, 2(1-Kb) , 0}}


Just set Kr = 0.114, Kb = 0.299 for BT.601 and Kr = 0.2126, Kb = 0.0722 for BT.709.

[Zachs]

The exact matrices are given by the following:

RGB -> YUV:
{{Kr , 1-Kb-Kr , Kb},
{-(1/2)Kr/(1-Kb), -(1/2)(1-Kb-Kr)/(1-Kb), 1/2},
{ (1/2) , -(1/2)(1-Kb-Kr)/(1-Kr),-(1/2)Kb/(1-Kr)}}

YUV -> RGB:
{{1, 0 , 2(1-Kr)},
{1,-2(1-Kb)Kb/(1-Kb-Kr),-2(1-Kr)Kr/(1-Kb-Kr)},
{1, 2(1-Kb) , 0}}


Just set Kr = 0.114, Kb = 0.299 for BT.601 and Kr = 0.2126, Kb = 0.0722 for BT.709.

:thanks:

[Zachs]

Ah, no idea what they even are.

I have no idea, I have seen references to 4:2:0 but as with po10 and po16, have no idea what it is.

Can you check if your CPU can play that P210 file with the latest MPDN version?

The slowest CPU I could get hold of is an i5-2520M @ 2.5GHz (dual core with HT). It plays fine with its built-in Intel GPU. CPU usage ~37%. GPU wasn't being taxed much but it barely just managed to play the clip without dropping any frames. However, I did notice with this laptop that it was running out of memory bandwidth (both CPU and GPU share the same dual channel DDR3 bandwidth), which accounts for the low GPU utilization (GPU frequency remains in power save state) but high render times (33.33ms).

On the other hand, I've tested the clip on an i7 (4 cores + HT) with an old and very low end ATI 4350HD DDR2 card and found it to be more than capable of running the clip with MPDN's default settings. CPU usage on the i7 was ~10%.

Interestingly, I then switched the output formats of LAV Video Decoder to YUV 4:4:4 16-bit (Y416) and found madVR to also behave in the same manner - i.e. CPU usage was around 50%, GPU usage was very low, yet dropping frames like crazy.

I would say the problem you encountered was probably due to the fact that your system ran out of *system* memory bandwidth. MadVR probably required less memory bandwidth and you found it to work on your machine whereas MPDN just used that little bit more.

I've optimized how MPDN uses system memory bandwidth as well as some general CPU performance optimizations. See if that helps your machine.

[Anima123]

I have the following error messages when I tried to use DirectX 10.1 interface with MPDN:
TITLE: SharpDX Error
------------------------------

An unexpected error 'SharpDX.SharpDXException' has occurred.

------------------------------
ADDITIONAL INFORMATION:

HRESULT: [0x887A0005], Module: [SharpDX.DXGI], ApiCode: [DXGI_ERROR_DEVICE_REMOVED/DeviceRemoved], Message: The GPU device instance has been suspended. Use GetDeviceRemovedReason to determine the appropriate action.
(SharpDX)

------------------------------
BUTTONS:

&Ignore
&Abort
------------------------------


Any idea what the problem is?

[Zachs]

My guess is your nvidia driver crashed probably due to overclock or unstable drivers.

EDIT: read https://forums.geforce.com/default/topic/786554/pc-games/call-of-duty-advanced-warfare-issue-direct3ddevice-present-failed-the-gpu-device-instance-has-been/

[Anima123]

The latest nVidia whql driver I am using.

[Zachs]

Did it happen with older drivers? I certainly haven't seen that error before and I've got 3 nvidia cards from different generations.

[Anime Viewer]

I have the following error messages when I tried to use DirectX 10.1 interface with MPDN:
TITLE: SharpDX Error
------------------------------

An unexpected error 'SharpDX.SharpDXException' has occurred.

------------------------------



Any idea what the problem is?

I recall encountering a SharpDXException error that talked about device removed (like yours is) once after a install of a new version of MPDN. If I recall correctly it had to do with shader chain settings, where the files were copied, and maybe the version Rederscript files I was using.

Are you using the most recent version of Render Scripts?
http://forum.doom9.org/showpost.php?p=1698272&postcount=322

Do you have the RenderScripts folder copied from that file into the directory your MPDN executable is installed in?

As a test if you've any render scripts set to run try temporarily removing them, close out the player, and re-open it. Does the error still occur with no scripts selected in settings?

Also do you have a check in new windowed render mode? I seem to also recall seeing that message when that was checked and DX10.1 was also chosen. If so uncheck the new windowed render mode box, restart the MPDN program, and see if it still occurs.

[feelingblue]

Could you give me an explanation?

How "Video Output Levels" interacts with "Pixel Format" in the Video Card Control Panel?