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

[XRyche]

The behavior is the same for both subtitle renderers as well as going back the same time/position as the subtitle not appearing. The subtitle dosen't appear in the same time/position every time.

[Zachs]

Originally Posted by XRyche

The behavior is the same for both subtitle renderers as well as going back the same time/position as the subtitle not appearing. The subtitle dosen't appear in the same time/position every time.

If the behaviour is the same with both subtitle renderers, there's not much I could do about that, seeing that DirectVobSub gives me the frame as an image - MPDN simply presents it to the screen.

Does it behave differently with MPC-HC?

[XRyche]

It hasn't that i can recall, but I will double check again to make sure.

[Anima123]

Cannot download the 64-bit version of v2.18.8 correctly. Would you guys please double-check it?

[XRyche]

I am very very sorry. It does appear to exhibit the exact same behavior in MPC-HC. I'm now 90% sure it displayed the vobsubs correctly the last time I watched this particular DVD, which in all honesty was probably well over a year ago. Sorry about making you run circles.

[Zachs]

Hey guys, don't download v2.18.8 yet!
I'm fixing the broken build right now -- will re-upload in a minute!

EDIT: Fixed. Those of you who've downloaded v2.18.8 before, you'll need to download again.

These are the md5 sums in case your browser still keeps a cache of the broken build.
x64 md5: 494eb6452eb198c873f4403d57eef304
x86 md5: 40a64f7f7176fbade19e695b9ceb1651
AnyCPU md5: 3c7e8175fac88e146c19cf2a57013058

[Anime Viewer]

Originally Posted by Zachs

Hey guys, don't download v2.18.8 yet!
I'm fixing the broken build right now -- will re-upload in a minute!

EDIT: Fixed. Those of you who've downloaded v2.18.8 before, you'll need to download again.

These are the md5 sums in case your browser still keeps a cache of the broken build.
x64 md5: 494eb6452eb198c873f4403d57eef304
x86 md5: 40a64f7f7176fbade19e695b9ceb1651
AnyCPU md5: 3c7e8175fac88e146c19cf2a57013058

Woops too late, I'd already downloaded it. Are Optimus users still reporting the ms increasing problem when watching long videos? I just tested the same video that I had the issue with before, and didn't encounter it this time (through 30 minutes of the video it had remained at 12ms). I don't know if that should be attributed to recent updates to the MPDN program, having it use "Graphics Adapter ID*" 1, or maybe the fluke of running a broken cache version. (Previously I'd always left it to use Graphics Adapter ID* on 0, but I think 0 might be the Intel, and 1 might be the Nvidia. I could probably confirm it by running GPU-Z at the same time).
I'll test out the new build, and see if it has any problems in order to rule out/in the broken cache as having an effect.
edit: The new build worked fine, so the broken cache doesn't seem to have been a factor.

[madshi]

Originally Posted by Zachs

Doesn't make much sense then to say the bitstream is 1920x1088 to begin with and then decide later that it should be 1920x1080. Anyway I tested with a PNG file - and those 8 lines you spoke about aren't garbage for sure!

Well, you could ask nevcairiel to not report 1088 to start with, that might make sense if he always cuts the resolution down to 1080 later, anyway.

Do you really want a PNG image with 1920x1088 to be displayed as 1920x1088 in MPDN? This would result in scaling becoming active for every user on the planet earth, when most users have 1920x1080 displays and as a result wouldn't need scaling with a 1920x1080 image. Of course it's a good argument to say that a PNG should not be touched. But then, where does a 1920x1088 PNG image likely come from? It's probably a screenshot from a movie, and as such it's likely to be 1920x1080. But even if it is true 1088 lines, isn't it still better to show it unscaled then to activate X+Y scaling just for 8 lines?

[Zachs]

If it came from a movie screen shot wouldn't it be 1920x1080 to begin with since like you said 8 lines are garbage and trimmed?

Also the question was why pull the rug from under the player when it knew 1920x1088 was always going to be 1920x1080 in the first place, since by your argument it always is even for PNG?

[Anima123]

Thanks for the new version. Using the arrow key to adjust volume seems not working anymore when playing a video in FSE.

[madshi]

Originally Posted by Zachs

If it came from a movie screen shot wouldn't it be 1920x1080 to begin with since like you said 8 lines are garbage and trimmed?

Also the question was why pull the rug from under the player when it knew 1920x1088 was always going to be 1920x1080 in the first place, since by your argument it always is even for PNG?

Some decoders & players don't force 1088 down to 1080, so the screenshot could have come from such a player/decoder.

DirectShow allows resolution changes like that. It can happen in the middle of a stream, too. Of course it would be nicer if it didn't happen. Sometimes the container reports one resolution and the video bitstream decodes to a different resolution. Sometimes aspect ratio handling can result in two different resolutions, depending on whether you round up or down etc. Sometimes [...]. Of course in an ideal world the resolution would be known right at the start and never change again. Anyway. Just trying to explain some of the possible reasons for such resolution changes. I'm not in a position to change any of that, anyway, so I guess I should stop arguing at this point. You asked why, I tried to explain. If you're not happy with the way things are, you can always contact nevcairiel about it. He's the one who can change things.

[Anima123]

Originally Posted by Anime Viewer

Are Optimus users still reporting the ms increasing problem when watching long videos?

Unfortunately the problem still there with the latest version. You will need to use SuperRes with NEDI enabled to trigger it though.

[Zachs]

Originally Posted by madshi

Some decoders & players don't force 1088 down to 1080, so the screenshot could have come from such a player/decoder.

DirectShow allows resolution changes like that. It can happen in the middle of a stream, too. Of course it would be nicer if it didn't happen. Sometimes the container reports one resolution and the video bitstream decodes to a different resolution. Sometimes aspect ratio handling can result in two different resolutions, depending on whether you round up or down etc. Sometimes [...]. Of course in an ideal world the resolution would be known right at the start and never change again. Anyway. Just trying to explain some of the possible reasons for such resolution changes. I'm not in a position to change any of that, anyway, so I guess I should stop arguing at this point. You asked why, I tried to explain. If you're not happy with the way things are, you can always contact nevcairiel about it. He's the one who can change things.

Just trying to make some sense out of why it was even reporting 1088 to the player when it knew what the actual size was in the first place and had no intention of supplying the stream in 1088 either.

Edit: appreciate your explanation, but the above still doesn't quite get explained... Anyway, it's fixed so not too bothered by it. Just curious what the rationale might be behind such an implementation.

[Zachs]

Originally Posted by Anima123

Unfortunately the problem still there with the latest version. You will need to use SuperRes with NEDI enabled to trigger it though.

Nekromantik tried it on his Optimus system and reported no such issues a couple of pages back.

[Zachs]

Originally Posted by Anima123

Thanks for the new version. Using the arrow key to adjust volume seems not working anymore when playing a video in FSE.

Will have a look later.

EDIT: Fixed in next release - apparently all shortcut keys with Shift+Right/Left were not processed in fullscreen mode.

[nevcairiel]

Originally Posted by Zachs

Also the question was why pull the rug from under the player when it knew 1920x1088 was always going to be 1920x1080 in the first place, since by your argument it always is even for PNG?

Consider it a test if resolution changes work in the renderer. It did find a bug, didn't it?
As madshi already mentioned, actual 1920x1088 content which is intentionally this resolution is practically non-existent, and the only content i've ever seen to use this resolution is 1080p content with missing cropping information.

That it doesn't also change this in the initial media type immediately is mostly an oversight, but a change in resolution doesn't hurt anyone, it can happen with every video for various reasons, so I'm not worried.

[Anima123]

Originally Posted by Zachs

Nekromantik tried it on his Optimus system and reported no such issues a couple of pages back.

Nekromantik, could you please share with us how you do the rendering time increasing test, including player configurations, hardware, driver version and the info of the video you're doing testing?

I have tested this on two of my laptops with Optimus, both had exactly the same problem. It should not be a false alarm.

Besides, can anyone with Optimus system confirm this problem? Or better, prove me wrong with your whole configurations so I can solve the problem by just use the proper driver version and maybe the proper configurations?

[snowpiercer]

Hello Zachs, hello everyone else, this is my first post here at the forums. I'm actually following these forums and MPDN for quite some time but never got around to actually post something. I'm quite excited to finally say hello and make a first post here!

First of all, i love the MPDN player. I'm a long time fan of the MPC-HC + madVR combi and this is usually my default player, but when the FluidMotion feature was introduced it convinced me to give MPDN a try and so far it's looking really good and promising.

However, the reason i post here for the first time is that i did encounter some bugs and errors:

First, in DX9 and DX10 (and probably DX11 too) when i play audio only (f.e. .flac) in the player and switch to fullscreen, the following error msg pops up: "HRESULT: 0x8876086C, Module SHARPDX.Direct3d9, APICODE D3DERR_invalidcall, message: unknown".

The next bug happens in DX11, after exiting fse (switching back to windowed mode) i got a similar msg, this time: HRESULT 0x887A0005 Module SHARPDX.DXGI. DXGI_ERROR_DEVICE_REMOVED. Afterthis, the MPDN shows only two red lines and won't exit anymore, instead when trying to exit showing "Back buffer has not been created". The audio weirdly still continues to play, but when trying to skip ahead another msg comes up: "Object reference not set to an instance of an object". After a while it just crashes then. It doesn't occur always, but i can reproduce this most of the time. Usually when switching back and forth to fullscreen and windowed multiple times it eventually shows up.

In DX9 and DX10 everything else plays fine (no bugs except full screen with audio only).

Lastly, yesterday i had a really strange bug that might not have to do with MPDN, but it never happened to me in any other player before. All of a sudden, some ~twenty minutes into a video, the sound constantly got extremely scratchy and noisy, louder than the whole audio mix. I had to stop MPDN and unplug/replug my USB soundinterface. I'm using DirectSound in MPDN, same as with MPC-HC.
I don't know if this was just a bad coincidence, because i can't reproduce it right now, but i also never had this happen in MPC-HC before. It also wasn't the video that produced this, so there's probably nothing you can do, but if i encounter this again i'll let you know about it again.


My configuration: MPDN x64 latest (..18.8), latest MPDN plugins, latest official nvidia drivers (not beta drivers).

Hopefully you can look into these errors that have to do with DX11 and fullscreen audio only. So far i really like the player and i'm sure it will only keep getting better and better. Looking forward to watching more content with MPDN, thanks Zachs and everyone else involved!

[DeadlyEmbrace]

Originally Posted by Zachs

This is fullscreen exclusive mode we're talking about isn't it? Exclusive mode seems to be very dependent on the GPU drivers and it behaves very differently from Dx9 to 11. On my Windows 7 setup, Dx10 causes all the screens to go black except the one playing the video, while Dx11 works like 9 where all screens continue to work just fine. I'm afraid there's not much I could do about that.

No worries, was just curious. Yes, it was indeed fullscreen exclusive mode. Removing FSE solves the problem.

Could you add events for volume change and mute for the extensions? At current the remote has no way to know if the volume was changed directly in MPDN or via another remote.

[Zachs]

Originally Posted by snowpiercer

First, in DX9 and DX10 (and probably DX11 too) when i play audio only (f.e. .flac) in the player and switch to fullscreen, the following error msg pops up: "HRESULT: 0x8876086C, Module SHARPDX.Direct3d9, APICODE D3DERR_invalidcall, message: unknown".

The next bug happens in DX11, after exiting fse (switching back to windowed mode) i got a similar msg, this time: HRESULT 0x887A0005 Module SHARPDX.DXGI. DXGI_ERROR_DEVICE_REMOVED. Afterthis, the MPDN shows only two red lines and won't exit anymore, instead when trying to exit showing "Back buffer has not been created". The audio weirdly still continues to play, but when trying to skip ahead another msg comes up: "Object reference not set to an instance of an object". After a while it just crashes then. It doesn't occur always, but i can reproduce this most of the time. Usually when switching back and forth to fullscreen and windowed multiple times it eventually shows up.

In DX9 and DX10 everything else plays fine (no bugs except full screen with audio only).

Lastly, yesterday i had a really strange bug that might not have to do with MPDN, but it never happened to me in any other player before. All of a sudden, some ~twenty minutes into a video, the sound constantly got extremely scratchy and noisy, louder than the whole audio mix. I had to stop MPDN and unplug/replug my USB soundinterface. I'm using DirectSound in MPDN, same as with MPC-HC.
I don't know if this was just a bad coincidence, because i can't reproduce it right now, but i also never had this happen in MPC-HC before. It also wasn't the video that produced this, so there's probably nothing you can do, but if i encounter this again i'll let you know about it again.


My configuration: MPDN x64 latest (..18.8), latest MPDN plugins, latest official nvidia drivers (not beta drivers).

Hopefully you can look into these errors that have to do with DX11 and fullscreen audio only. So far i really like the player and i'm sure it will only keep getting better and better. Looking forward to watching more content with MPDN, thanks Zachs and everyone else involved!

The first one is fixed in the next release.

The one about Dx11 crashing going in and out of full screen exclusive mode is a driver bug. That said, I've made MPDN show the error and then terminate when the abort button is pressed. This will be how MPDN handles critical errors from now on.

The last one about your sound card shouldn't be due to MPDN since it does its the audio graph no differently to other DirectShow players now.

Originally Posted by DeadlyEmbrace

No worries, was just curious. Yes, it was indeed fullscreen exclusive mode. Removing FSE solves the problem.

Could you add events for volume change and mute for the extensions? At current the remote has no way to know if the volume was changed directly in MPDN or via another remote.

Done in v2.18.9.