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

[Zachs]

Originally Posted by elraffa

Hi zachs, please dont forget my request

I haven't forgotten but it has a very low priority as it's not a feature I use personally.

[ryrynz]

Looks good, no issues changing from Windowed to FSE. I still get the odd pause for a couple of seconds while seeking (generally backwards seeking using the arrow keys) I might have this happen 1/40 times or so.
The decoder and render queue just sit on 1 & 0 for a bit when this happens then playback continues as normal. This might be a bit of a non issue, and not be related to the player..

Okay just managed it again, this time is stalled for a good five seconds. Generally it's very responsive, guess I'll start testing options now.

I've changed about everything I can with no effect. I can generally cause this delay to happen by seeking about 5-7 steps forward and then a few backward. Audio continues while the picture and OSD is frozen.

[CruNcher]

Originally Posted by Dreamland

I think MPDN is the best player for quality video ! great!

It's really interesting to watch this development

as interesting as to watch Sonys Vegas or the Paint.net development

He does a great job seperating the GUI from the Render Core and that is the most important

[Zachs]

Originally Posted by CruNcher

It's really interesting to watch this development

as interesting as to watch Sonys Sony Vegas or the Paint.net development

If you fully understand how the GC works under .net desktop you'll find it to be a non issue. I've written my own production quality GC that is used for time sensitive applications on embedded platforms and even in those situations, you can always find ways to get around the GC pause. MPDN does a lot of its time sensitive stuff outside of .net. Memory overhead can be higher but GC tends to be faster in a highly multi threaded app, especially vs something like a smart pointer in C++.

[Zachs]

Originally Posted by ryrynz

Looks good, no issues changing from Windowed to FSE. I still get the odd pause for a couple of seconds while seeking (generally backwards seeking using the arrow keys) I might have this happen 1/40 times or so.
The decoder and render queue just sit on 1 & 0 for a bit when this happens then playback continues as normal. This might be a bit of a non issue, and not be related to the player..

Okay just managed it again, this time is stalled for a good five seconds. Generally it's very responsive, guess I'll start testing options now.

I've changed about everything I can with no effect. I can generally cause this delay to happen by seeking about 5-7 steps forward and then a few backward. Audio continues while the picture and OSD is frozen.

It's actually not frozen but waiting for the next frame to arrive so it can be rendered and presented. I've tried seeking back and forth but haven't been able to replicate the issue though.

[ryrynz]

Originally Posted by Zachs

It's actually not frozen but waiting for the next frame to arrive so it can be rendered and presented. I've tried seeking back and forth but haven't been able to replicate the issue though.

I've managed to reproduce this on my HTPC system as well.
I don't have this issue with MPC-BE/madVR, I guess the next step is to try earlier MPDN versions as well, I do know that 3550 has this issue for me as well.

While I'm on the topic, I know I've asked before but what the hell..can MPDN hope to seek any faster than it currently does?
MPC seeks about twice the speed (using same LAV filters, Directsound, Direct3D etc)
I've changed all MPDN defaults to their fastest values but I can't reach anywhere near as fast as MPC.

[eX``]

Hi. I have a little problem with MPDN, but I do not think this is exclusively related to it, for I managed to reproduce the error on MPC-HC. Hope you guys still can help.

Faulting application name: MediaPlayerDotNet.exe, version: 2.45.1.3557, time stamp: 0x562e0218
Faulting module name: nvcuvid.dll, version: 7.17.13.5887, time stamp: 0x563756f0
Exception code: 0xc0000005
Fault offset: 0x0000000000068548
Faulting process id: 0x161c
Faulting application start time: 0x01d117b89f092a87
Faulting application path: C:\Program Files\MPDN\MediaPlayerDotNet.exe
Faulting module path: C:\Windows\system32\nvcuvid.dll
Report Id: dd74865c-83ab-11e5-b707-448a5b219869

Unfortunately I can't give you any MPDN stamp for it crashes before I can fetch it.

[burfadel]

Originally Posted by eX``

Hi. I have a little problem with MPDN, but I do not think this is exclusively related to it, for I managed to reproduce the error on MPC-HC. Hope you guys still can help.



Unfortunately I can't give you any MPDN stamp for it crashes before I can fetch it.

That is an issue with your Nvidia driver. Try updating your driver to the latest and see if the problem persists .

[CruNcher]

Originally Posted by Zachs

If you fully understand how the GC works under .net desktop you'll find it to be a non issue. I've written my own production quality GC that is used for time sensitive applications on embedded platforms and even in those situations, you can always find ways to get around the GC pause. MPDN does a lot of its time sensitive stuff outside of .net. Memory overhead can be higher but GC tends to be faster in a highly multi threaded app, especially vs something like a smart pointer in C++.

Yeah it's interesting to compare the approach vs MPC-BE which i find currently the best win32 optimized Player in time sensitivity in a Multithreaded Scenario (apart from Microsofts own MFT focused work)

And yeah sure GC can get better over time if you optimize it and have full controll over it best example Firefox, but is it enough to compete in the end on resources and would this not endup in performance loses on the time sensitive optimized parts im still skeptical

I mean we not going for nothing into the Low Level API age and leaving DX 11s generic IHVs based GCs for DX 12 and more uniquely approaches tailored specific to the applications requirements

And currently either Firefox or Google Chrome look really old vs Microsofts Edge, especialy in a low power scenario as you seem to care a lot about

[eX``]

Originally Posted by burfadel

That is an issue with your Nvidia driver. Try updating your driver to the latest and see if the problem persists .

Yup I know, but I don't know where it comes from. Just updated this morning, clean install, before posting here, nothing changed. Anyway, I'll look around=). Let me know if rings a bell though.

[Zachs]

Originally Posted by CruNcher

Yeah it's interesting to compare the approach vs MPC-BE which i find currently the best win32 optimized Player in time sensitivity in a Multithreaded Scenario (apart from Microsofts own MFT focused work)

And yeah sure GC can get better over time if you optimize it and have full controll over it best example Firefox, but is it enough to compete in the end on resources and would this not endup in performance loses on the time sensitive optimized parts im still skeptical

I mean we not going for nothing into the Low Level API age and leaving DX 11s generic IHVs based GCs for DX 12 and more uniquely approaches tailored specific to the applications requirements

And currently either Firefox or Google Chrome look really old vs Microsofts Edge, especialy in a low power scenario as you seem to care a lot about

Like I said you really need to fully understand GC as it is implemented in .net but this is not the forum to discuss it.

[Anima123]

There's controversial discuss around the topic: should SuperRes using high-quality downscaler or not, in madVR thread? However when I was playing around the options kept within the MPDN version of SuperRes, I found the high-quality downscaler altered straight lines in the video, which is obvious when playing video with hard-encoded subtitles. Only enabled the high-quality downscaler will cause that kind of artefacts, no matter which image-doubler used. BTW, NNEDI3 itself does not have that kind of 'effect'.

I will upload some images for comparison later today.

Shiandow, it would be nice if you can comment of this, maybe after I uploaded the images for camparison?

The pic with HQ downscaling off:
https://www.dropbox.com/s/jqm4ssqe1n...caler.png?dl=0

Pic with HQ downscaling on:
https://www.dropbox.com/s/fgbeq7gn6j...aling.png?dl=0

[Zachs]

Originally Posted by ryrynz

I've managed to reproduce this on my HTPC system as well.
I don't have this issue with MPC-BE/madVR, I guess the next step is to try earlier MPDN versions as well, I do know that 3550 has this issue for me as well.

While I'm on the topic, I know I've asked before but what the hell..can MPDN hope to seek any faster than it currently does?
MPC seeks about twice the speed (using same LAV filters, Directsound, Direct3D etc)
I've changed all MPDN defaults to their fastest values but I can't reach anywhere near as fast as MPC.

I just tried seeking on my old i5 laptop via mechanical USB HDD and frame appear as soon as I click on the seekbar. Seek is instantaneous (if there's any delay it's imperceptible). This is with free-to-air footage that is 5GB in file size. With other files that have sparse keyframes it does take longer but in those cases MPDN's just waiting for the decoder to come back with a frame.

I still haven't been able to replicate any problems with audio playing while video waits regardless of how much I tried seeking back and forth and I've tested it on several machines already. Perhaps it's related to certain video files?

[aufkrawall]

ryrynz, are you using the same LAV settings/version for MPDN as with other players?
MPDN seeking is rather "instant" here with H.264 DXVA2 CB & GTX 980.

[Shiandow]

Originally Posted by Anima123

There's controversial discuss around the topic: should SuperRes using high-quality downscaler or not, in madVR thread? However when I was playing around the options kept within the MPDN version of SuperRes, I found the high-quality downscaler altered straight lines in the video, which is obvious when playing video with hard-encoded subtitles. Only enabled the high-quality downscaler will cause that kind of artefacts, no matter which image-doubler used. BTW, NNEDI3 itself does not have that kind of 'effect'.

I will upload some images for comparison later today.

Shiandow, it would be nice if you can comment of this, maybe after I uploaded the images for camparison?

The pic with HQ downscaling off:
https://www.dropbox.com/s/jqm4ssqe1n...caler.png?dl=0

Pic with HQ downscaling on:
https://www.dropbox.com/s/fgbeq7gn6j...aling.png?dl=0

Those look identical to me. In fact there's a decent chance they are identical, I just discovered a bug that essentially forces HQ downscaling on.

[Milardo]

Any chance that MPDN will have support for tv tuner/capture cards-like to apply all these rendering features of MPDN to devices i have like those?

[Anima123]

Originally Posted by Shiandow

Those look identical to me. In fact there's a decent chance they are identical, I just discovered a bug that essentially forces HQ downscaling on.

Was this bug introduced recently? I do see difference with some version before.

[Shiandow]

Originally Posted by Anima123

Was this bug introduced recently? I do see difference with some version before.

Looks like it's been there from the start. Odd, I thought it had worked at some point. Anyway, I just tried the low quality downscaling, and I found it introduced a lot of aliasing and ringing, and it's not really much faster, so generally I don't think it's really worth using. Might need to add HQ downscaling to SuperChromaRes as well.

[eX``]

(Little off) Ok, just wanted to give you the follow-up . So the nvidia "clean install" was screwed, tons of updates above one another had something to do with this problem, for I formated, reinstalled everything and everything is working.
Still one little problem though: i STILL have this FU**NG white veil over my screen. My screen is calibrated, working perfectly, but everytime I install my drivers, it screws with the gamma or anything and I feel like watching at my screen through a white veil ... (like when I open MPDN, the deep black screen is now dark grey....)
(Little off)
édit : like this Before / After

[s]SOLVED: [/s]The god of computers received my calls something in the nvidia panel was screwed. It touched everything 10 times, and thought "what's the point" and then 5min later I thought "ok one more time" and just clicked on the "Digital Vibrance thing (without changing the actual value) and...EUREKA ^^

Not solved in fact. Everytime I put MPDN in fullscreen mode, it screws back, and I have to go back to tweak this "Vibrance". This is not doing it with any game or application or anything.

[eX``]

Forget about it, it is another "driver fail", it does it too sometimes when I launch applications that have to go fullscreen.