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

[Anime Viewer]

No. Ryrynz pointed out that if you tried downloading youtube videos, the stream encoding info isn't copied across, so for anything below height of 720 and width of 1280, bt.601 has to be assumed. There's nothing a player can do in that case - blame the faulty container repackager.

EDIT: In this situation you can toggle the YUV matrix via shortcut (Ctrl+Shift+M) until you get to the correct one.

On that note might it be beneficial to have the system default to certain color spaces if certain resolutions are detected. In the case you gave resolutions below 1280x720 automatically switching to bt.601. Likewise if Improve Chroma Reconstruction is buggy, or not beneficial at certain resolutions have it automatically disable at those resolutions to reduce issues. Not everyone is likely to know when to toggle, what to toggle to, or remember to toggle when they open certain resolution content; so having the system do it for them (under certain conditions) could be beneficial.

[Shiandow]

On that note might it be beneficial to have the system default to certain color spaces if certain resolutions are detected. In the case you gave resolutions below 1280x720 automatically switching to bt.601. Likewise if Improve Chroma Reconstruction is buggy, or not beneficial at certain resolutions have it automatically disable at those resolutions to reduce issues. Not everyone is likely to know when to toggle, what to toggle to, or remember to toggle when they open certain resolution content; so having the system do it for them (under certain conditions) could be beneficial.

I've seen it behave both correctly and incorrectly for anything from 360p to 4k.

[nevcairiel]

Edit: I have just spent the last couple of hours retesting the clips with artefacts and they turn out to be genuine PC ranges that did not have their bitstream reporting it properly. I have to say so far I haven't encountered any btb/wtw ones yet, or at least they haven't caused any problems with the algo. It's easy to find out if they are meant to be PC ranges. If the whites are blown out in TV ranges but reveal extra details in PC ranges then it's not reporting it correctly. I went the extra step to verify that with screen capture and checking its actually a blown out and not just my display being inept at showing bright details.

At this point, I have to say it's actually very common to have a source with PC range! Which comes back to the original question I had now that both are common - how do we detect them?

I have no idea what kind of sources you test, but there is no commercial consumer content which is PC range, which is to say that 99% of all relevant content is not going to be PC range.

For detecting, if its actually meant to be PC range and then not flagged in the bitstream, then the video is just broken and will look wrong no matter if you use fancy chroma reconstruction or not.

[Zachs]

On that note might it be beneficial to have the system default to certain color spaces if certain resolutions are detected. In the case you gave resolutions below 1280x720 automatically switching to bt.601. Likewise if Improve Chroma Reconstruction is buggy, or not beneficial at certain resolutions have it automatically disable at those resolutions to reduce issues. Not everyone is likely to know when to toggle, what to toggle to, or remember to toggle when they open certain resolution content; so having the system do it for them (under certain conditions) could be beneficial.

The actual problem is the source may have been encoded with PC ranges and could come in any resolution but they don't provide that info in their bitstream. All we could reasonably assume is that they are BT.601 for resolutions lower than HD, which will be wrong. There's a lot of these sort of materials out there unfortunately, contrary to what Nev said.

[Zachs]

I have no idea what kind of sources you test, but there is no commercial consumer content which is PC range, which is to say that 99% of all relevant content is not going to be PC range.

For detecting, if its actually meant to be PC range and then not flagged in the bitstream, then the video is just broken and will look wrong no matter if you use fancy chrome reconstruction or not.

Perhaps not commercial consumer contents but things people download off the net e.g. YouTube. They're the ones that have been giving me these artefacts.

Anyway the point of the post was that I haven't encountered any artefacts yet with the chrome reconstruction option when the correct yuv matrix was used. That was basically my original point as well when I replied to madshi.

[huhn]

but this doesn't change the fact that these files are broken.
i mean they are not even unlimited flagged...

think about a hot key to treat files as PC range or TV range and a toggle hot key for BT 709/601. if this isn't already part of your player.

@nev don't underestimate commercial streamer. funimation can break everything!

[nevcairiel]

Anyway the point of the post was that I haven't encountered any artefacts yet with the chrome reconstruction option when the correct yuv matrix was used. That was basically my original point as well when I replied to madshi.

Try to get your hands on one of the Sony Blu-rays marketed as "Mastered in 4K", they use xvYCC, which uses out-of-range chroma by design, if thats the cause for artifacts.

[Zachs]

but this doesn't change the fact that these files are broken.
i mean they are not even unlimited flagged...

think about a hot key to treat files as PC range or TV range and a toggle hot key for BT 709/601. if this isn't already part of your player.

@nev don't underestimate commercial streamer. funimation can break everything!

Ctrl+Shift+L

[Shiandow]

And "Ctrl+Shift+M" to toggle BT 709, 601, 2020.

[huhn]

Ctrl+Shift+L

only shows me what is used but doesn't toggle.

edit:
And "Ctrl+Shift+M" to toggle BT 709, 601, 2020.
switches to BT 709 PC range but that's it.

when i use Ctrl+Shift+L after using Ctrl+Shift+M i get back bt 601 TV range

[Zachs]

Works fine for me... each time you press the hotkeys you get a different range right?

[huhn]

no it didn't do that.

[Zachs]

That's odd. Is yours working Shiandow?

[Anime Viewer]

I've seen it behave both correctly and incorrectly for anything from 360p to 4k.

The actual problem is the source may have been encoded with PC ranges and could come in any resolution but they don't provide that info in their bitstream. All we could reasonably assume is that they are BT.601 for resolutions lower than HD, which will be wrong. There's a lot of these sort of materials out there unfortunately, contrary to what Nev said.

Perhaps not commercial consumer contents but things people download off the net e.g. YouTube. They're the ones that have been giving me these artefacts.



Figures things wouldn't be that simple, and that you guys would have figured out the workaround if thy had been.

How about if the program checks for data, and if it finds it then it switches to that mode. If it doesn't (in the case of the stripped bitstream or youtube videos) instead of defaulting to TV Range with Improved Chroma Reconstruction it instead defaults to the most error free color mode, or disables Improved Chroma Reconstruction. If people know there content fits one of the other color modes he/she could then toggle to it. Perhaps add a sub-check box below Improved Chroma Reconstruction that says something along the lines of "when colormetric not detected disable Chorma Reconstruction" with it checked by default. If someone wants to leave it up to the system to make a guess (like it currently does) then he/she could uncheck that box.


That's odd. Is yours working Shiandow?

Not Shiandow, but both Ctrl+Shift+L and Ctrl+Shift+M both work as they are supposed to on my system (as far as I can tell). Ctrl+Shift+L cycles through TV and PC (with whatever color 601,709, or 2020 is currently in use) while Ctrl+Shift+M cycles through 601, 709, and 2020 for which ever mode (PC or TV) is currently in use.

[nevcairiel]

Much consumer content which is TV range will not actually carry a flag saying that it is TV range, since that is the implicit default value assumed by nearly everyone and everything.
Is the effect of that code even worth all the trouble do worry about it?

[huhn]

Not Shiandow, but both Ctrl+Shift+L and Ctrl+Shift+M both work as they are supposed to on my system (as far as I can tell). Ctrl+Shift+L cycles through TV and PC (with whatever color 601,709, or 2020 is currently in use) while Ctrl+Shift+M cycles through 601, 709, and 2020 for which ever mode (PC or TV) is currently in use.

i just installed MPDN and extension 30 mins ago what version are you using?

[Anime Viewer]

i just installed MPDN and extension 30 mins ago what version are you using?

I was using 64-bit edition of 2.27.0.3110 at the time, but right now I'm testing a debug version with a different D3D9NativeServices.dll that Zach sent me to troubleshoot crashes having to do with Optimus notebooks and DX11 FSE.

[huhn]

i use x64 2.27.0.3100 with extensions 1.0.3 and it clearly doesn't work.

[Zachs]

@huhn Can you clear your MPDN config folder and try again? I can't replicate the problem on the various systems I usually test it on.

[shaolin95]

Zachs, I have been trying to understand some results I am getting from my GTX 750 and BenQ W1070.
I was doing the 10bit test using the gray ramp to compare 8 vs 10bit and in mpc with madvr, I can clearly see how smooth it looks when in 10bit mode vs 8 but in yours I cannot get it to show any difference. Both times it looks the same. Am I missing something?

[Zachs]

Are you certain you're using FSE with MPDN?
MPDN's 10-/16-bit output feature isn't new (it's had it since the early days) and I have extensively tested it across a lot of different links / monitors etc. Various other MPDN users have extensively tested this as well.
Anyway there isn't much that could go wrong - it's a simple "tell D3D to output in 10 bit mode" feature.

[shaolin95]

Are you certain you're using FSE with MPDN?
MPDN's 10-/16-bit output feature isn't new (it's had it since the early days) and I have extensively tested it across a lot of different links / monitors etc. Various other MPDN users have extensively tested this as well.
Anyway there isn't much that could go wrong - it's a simple "tell D3D to output in 10 bit mode" feature.

I will try again with the 32bit version too this time.

[shaolin95]

I will have to test with more time during the weekend but with the same settings and yes FSE, neither one improves the ramp "bands" changing from 8 to 10 to 16. It remains the same way.

[foxyshadis]

Perhaps not commercial consumer contents but things people download off the net e.g. YouTube. They're the ones that have been giving me these artefacts.

Anyway the point of the post was that I haven't encountered any artefacts yet with the chrome reconstruction option when the correct yuv matrix was used. That was basically my original point as well when I replied to madshi.

It doesn't surprise me at all that internet content is a bastion of badly mastered video. It's good that someone is working on it, but I doubt there's ever going to be a fullproof way to detect greater fools, so it might never be something you can enable by default.

[Zachs]

I've made a render script called "Conditional" that allows you to let MPDN automatically choose a preset when certain conditions are met. Based on this, you can do things like create profiles based on frame rate / resolution etc. or even downscale in linear light with any scaler of your choice without having to use the Scripted Render Chain.

See the wiki page (https://github.com/zachsaw/MPDN_Extensions/wiki/The-Conditional-Render-Script) for more details.

http://i.imgur.com/68WYIv4.png

[huhn]

@huhn Can you clear your MPDN config folder and try again? I can't replicate the problem on the various systems I usually test it on.

the folder under C:\Users\"user name"\AppData\Local\MediaPlayerDotNet ?

tried that didn't worked i try i now on a different PC.

[Zachs]

I've tested on 5 different PCs from Win7 to 8.1 (one of which is a tablet!) and they all work as advertised. It's really weird that you're getting a different behaviour. I'm baffled.

[huhn]

doesn't work there too.

can windows 10 be a reason?

i don't see a way where i can mess things up.

it's not hard to press control+shift+m/l a could of times.

[Garteal]

Seems to be related to Windows 10 some way or another as I can replicate your problem on my end ever since I've installed Windows 10.

[Anima123]

Zachs,

Last night is the only time that MPDN didn't have the rendering time increase issue, that's after I used mpc-hc64 + madVR for playback. Not sure if this make sense to you now.

Regards,
Anima123

[Zachs]

With the latest version? Might've been something to do with the Optimus bug I fixed.

[Zachs]

Seems to be related to Windows 10 some way or another as I can replicate your problem on my end ever since I've installed Windows 10.

There's something fundamentally wrong with windows 10 then when both windows 7 and 8 don't have that problem. Might be a bug that Microsoft hasn't picked up yet. Perhaps someone should let them know.

[Garteal]

Everything seems to be working fine again on Windows 10 now since I've installed a newer build (10130). Can you see if it works fine for you too huhn?

[huhn]

still not working.

[Blackfyre]

Hi Zachs and everyone else;

Long time no see... (this is for both Madshi and Zachs).

Just thought I should let you guys know, if you're interested in updating your AMD Drivers for the latest games (or other reasons), but want to remain using "older" driver versions for your media player/s (I know many prefer 14.4, as they see them the most stable)... Then now there's a way to do that; just copy the DLL Files for DX9, DX10 to 11.2, and OpenGL to your media players executable (.exe).

http://forums.guru3d.com/showthread.php?t=399547

Edit: I'll be testing it myself soon with both MPC+Madvr and MPDN and see how it goes, but I don't see why it shouldn't work the way it works with games too.

[huhn]

have you done a test with openCL?

most people prefer 13.12 there.

[nevcairiel]

Hi Zachs and everyone else;

Long time no see... (this is for both Madshi and Zachs).

Just thought I should let you guys know, if you're interested in updating your AMD Drivers for the latest games (or other reasons), but want to remain using "older" driver versions for your media player/s (I know many prefer 14.4, as they see them the most stable)... Then now there's a way to do that; just copy the DLL Files for DX9, DX10 to 11.2, and OpenGL to your media players executable (.exe).

http://forums.guru3d.com/showthread.php?t=399547

Edit: I'll be testing it myself soon with both MPC+Madvr and MPDN and see how it goes, but I don't see why it shouldn't work the way it works with games too.

This seems like a good way to break everything.
For anyone else reading, I would seriously recommend against "experiments" like this. Mix-matching individual driver files will only cause you trouble.

For developers of players and games alike, I would completely ignore anyone that reports any issues trying to use such things.

[Blackfyre]

This seems like a good way to break everything.
For anyone else reading, I would seriously recommend against "experiments" like this. Mix-matching individual driver files will only cause you trouble.

You can check on the thread, people have actually tested, performance changes corresponding with each driver version for different games (using the DLL's).

With all due respect; I haven't tested them myself yet, but to call something "experimental" (which it is, okay), and judging it negatively without even testing it, is narrow minded. If you've tried it, and it has "broken" something for you or others, that's understandable. But it doesn't sound like you even tried it.

Anyway, if anyone finds it helpful, or not, feel free to report back. Personally I don't have issues staying with the latest drivers. I use the latest modded Windows 10 AMD Drivers on Windows 8.1, they increase gaming performance for all DX11 games (which is something the official beta AMD Windows 8.1 drivers have been lacking for a while).

The reason I posted is because I know people are sticking with "OLD" drivers because they feel they perform best with MPDN or Madvr, all I'm saying is, you could potentially get the best of both worlds (upgrade drivers to the latest, use older dll's for mpdn and mpc).

have you done a test with openCL?

most people prefer 13.12 there.

I'll let them know on Guru3D to add the 13.12 drivers for anyone interested.

EDIT:

I've asked PrMinisterGR on Guru3D and this is his reply (Give it an hour or so before it finishes uploading I guess).

I'm uploading the 13.12 driver dlls now. The dlls will work as long as your hardware ids are recongized by the drivers in the dlls.

[Belphemur]

You can check on the thread, people have actually tested, performance changes corresponding with each driver version for different games (using the DLL's).

With all due respect; I haven't tested them myself yet, but to call something "experimental" (which it is, okay), and judging it negatively without even testing it, is narrow minded. If you've tried it, and it has "broken" something for you or others, that's understandable. But it doesn't sound like you even tried it.

Anyway, if anyone finds it helpful, or not, feel free to report back. Personally I don't have issues staying with the latest drivers. I use the latest modded Windows 10 AMD Drivers on Windows 8.1, they increase gaming performance for all DX11 games (which is something the official beta AMD Windows 8.1 drivers have been lacking for a while).

The reason I posted is because I know people are sticking with "OLD" drivers because they feel they perform best with MPDN or Madvr, all I'm saying is, you could potentially get the best of both worlds (upgrade drivers to the latest, use older dll's for mpdn and mpc).



I'll let them know on Guru3D to add the 13.12 drivers for anyone interested.

EDIT:

I've asked PrMinisterGR on Guru3D and this is his reply (Give it an hour or so before it finishes uploading I guess).

I understand the idea behind it, but for a developer this is the worst you could come with. And I agree with Nevcairiel about not supporting this.

To put it easily, there is a lot of cases where it would render a bug report invalid. First one, the user forget he has changed the dll, update to a new version of the player that doesn't support for X/Y reason those old driver, come here to complain. When reporting, he'll use the usual way to find the driver version that won't be the one used by the player...

Also, this is far from being recommended to anybody that is not tech savvy and ready to drop any support from the developer. (You know, the same way game developer don't provide support for mods of their games).

In other words, it's a fun tweak, but not recommended if you're not ready to resolve any issue yourself.

[Blackfyre]

Oh I completely understand now. You guys are viewing this from a developers point of view with regards to bug/instability reporting from the "general public". That's understandable. I didn't look at it that way. I assumed the majority of people here are tech savvy ;) but I get your points now.

[Zachs]

I will have to test with more time during the weekend but with the same settings and yes FSE, neither one improves the ramp "bands" changing from 8 to 10 to 16. It remains the same way.
I think huhn mentioned that the tests for madvr's 10bit output is designed to use RGB48 as input which isn't supported by MPDN. However 16bit YUV input formats are fully supported. You'll find that the problem is the test method used.

[shaolin95]

I think huhn mentioned that the tests for madvr's 10bit output is designed to use RGB48 as input which isn't supported by MPDN. However 16bit YUV input formats are fully supported. You'll find that the problem is the test method used.
Just tried it with the 64 bit version and it did work as well.

[Zachs]

Just tried it with the 64 bit version and it did work as well.

Try it with LAV RGB24/32/48 disabled - but make sure the 16-bit YUV formats are enabled. I'll add support for RGB48 in the next version of MPDN.

EDIT: MPDN v2.28.0 now supports RGB48.

[Zachs]

still not working.

Finally found what the problem was! It only happens if you don't have any render scripts selected. I've fixed it in the next release.

EDIT: Fixed in v2.29.0.

[Zachs]

Hi devs,

I've extended MPDN player extension's menu system capabilities in v2.29.0. In particular, it is now possible to get hold of a verb's menu item object and change it on the fly (e.g. hide / show / enable / disable it).

It is now also possible to create / remove child menu items from a parent verb, so you could do things like adding script group's presets to the menu system.

I've updated the RendererControl player extension (https://github.com/zachsaw/MPDN_Extensions/blob/master/Extensions/PlayerExtensions/RendererControl.cs) to use this new menu API as an example.

Cheers.

[burfadel]

With the latest version, I'm getting v2.29.0:

TITLE: System.Windows.Forms Error
------------------------------

An unexpected error 'System.InvalidOperationException' has occurred.

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

Invoke or BeginInvoke cannot be called on a control until the window handle has been created. (System.Windows.Forms)

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

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


This is with a completely fresh copy of the program. It occurs even when the extensions aren't in the folder (yes, I was using the latest anyway!).

I also tried deleting the Mediaplayerdotnet folder from users\(me)\appdata\local to no avail.

Previous version worked fine. In fact, I was actually using it when I paused for a break, came online, and saw that there was a new version available! BTW this is on Windows 10 x64 build 10130, using the x64 MPDN.

[Zachs]

Hmm can you get hold of the stack trace by enabling debug dialog? I can't get it to happen on my systems...

EDIT: Never mind. Found the problem. I'll fix it in a bit!

[huhn]

the newest version gives me this:
TITLE: System.Windows.Forms Error
------------------------------

An unexpected error 'System.InvalidOperationException' has occurred.

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

Invoke or BeginInvoke cannot be called on a control until the window handle has been created. (System.Windows.Forms)

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

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


clean "install" of mpdn MediaPlayerDotNet_x64_2_29_0_3115 and MPDN_Extensions-1.1.0

edit: i guess i'm late to the party

[Zachs]

LOL. v2.29.1 coming up shortly.
For some reason it wasn't happening here until I deleted the whole MPDN config folder.

EDIT: Fixed in v2.29.1.

[huhn]

the hot keys work now.