Log in

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


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 [46] 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96

madshi
25th May 2015, 10:14
Apparently there's quite a few videos out there with out of range chroma values, if that's what indeed caused that issue above. I encountered it straight away on a 720 H.264 rip and mentioned it to Zach.
It appears there's nothing that can be done in this instance, which kinda makes that chroma reconstruction option useful for videos you know don't have that issue.
I'd still like to have a couple of samples. Can't hurt, and maybe Shiandow and/or I will find a way to work around the issue.

huhn
25th May 2015, 11:06
Looks like the kind of artefacts the chroma limiter can cause, try disabling "Improve chroma reconstruction".

dark details are clipped on the character too. is this an issue from "Improve chroma reconstruction" too?

huhn
25th May 2015, 11:07
It was the same scene in that both were taken from 18 minutes and 30 seconds into the video, and the video (and others) had it those large parts of their playback when it came to dark blue/black backgrounds (space, air, etc). Regardless Shiandow was right and the "improve chroma reconstruction" wasn't improving things, but hurting instead.

and min 18 30 sec has 24 or more different frames.

Anime Viewer
25th May 2015, 13:29
I'd still like to have a couple of samples. Can't hurt, and maybe Shiandow and/or I will find a way to work around the issue.

It might be effected by how the file was encoded, but one common scene its noticeable on many of the videos I've watched is the Toei Animation opening credit where there is black and blue space with bubbles floating out.

Like show here:
https://youtu.be/v85egwc9QnI
https://youtu.be/WdFBZKpnVVA

Shiandow
25th May 2015, 14:03
It might be effected by how the file was encoded, but one common scene its noticeable on many of the videos I've watched is the Toei Animation opening credit where there is black and blue space with bubbles floating out.

Like show here:
https://youtu.be/v85egwc9QnI
https://youtu.be/WdFBZKpnVVA

It tends to happen when something is full range, but MPDN (or rather LAV) thinks it's TV range. Or worse, when the video uses both ranges, which I suspect is often the case with that intro. FWIW if the range wasn't detected properly you can switch manually using Ctrl+Shift+L.

Without having a black or white list for use with this option so that the artefacts hopefully won't appear the option isn't very useful.

I could add a shortcut for temporarily enabling / disabling it.

Magik Mark
26th May 2015, 00:29
Is it possible to scale in liniar light? How do we do this?

Zachs
26th May 2015, 02:02
Just add the "ConvertToLinearLight.hlsl" file to an ImageProcessor before scaling and another "ConvertToGammaLight.hlsl" file after scaling.
ScriptedRenderChain is very useful for this sort of thing (e.g. if you only want to use linear light scaling when downscaling) and using it with Script Group (you can name your scripts in there too), you can cycle through your custom chain with a press of a hotkey.
The way I've got it setup at the moment allows me to switch to a different chain during playback easily.

p.s. If you know how to use the ScriptedRenderChain, you can even make it use different chains for different source materials, based on your source fps, resolution etc. For example, for 720p materials, there's really not much need to use NNEDI3. I've got mine scripted such that it uses NEDI for anything >= 720p so my HTPC runs quieter.

Magik Mark
26th May 2015, 04:12
Just add the "ConvertToLinearLight.hlsl" file to an ImageProcessor before scaling and another "ConvertToGammaLight.hlsl" file after scaling.
ScriptedRenderChain is very useful for this sort of thing (e.g. if you only want to use linear light scaling when downscaling) and using it with Script Group (you can name your scripts in there too), you can cycle through your custom chain with a press of a hotkey.
The way I've got it setup at the moment allows me to switch to a different chain during playback easily.

p.s. If you know how to use the ScriptedRenderChain, you can even make it use different chains for different source materials, based on your source fps, resolution etc. For example, for 720p materials, there's really not much need to use NNEDI3. I've got mine scripted such that it uses NEDI for anything >= 720p so my HTPC runs quieter.

Thanks Zachs. Is this useful for scaling exclusively? Can it also be used with other image processor with visible result? Such as denabding, denoise & Fine Sharp

Zachs
26th May 2015, 04:30
Yes. The default script that comes with it should provide you with a good place to start. It's JavaScript so you can use any editors of your choice to write it.
I don't think any player/renderer even comes close to MPDN in terms of how much you can customize it.

Anime Viewer
26th May 2015, 04:44
It tends to happen when something is full range, but MPDN (or rather LAV) thinks it's TV range. Or worse, when the video uses both ranges, which I suspect is often the case with that intro. FWIW if the range wasn't detected properly you can switch manually using Ctrl+Shift+L.


Interesting, so even if LAV Video decoder RGB Output Levels is set to PC (0-255), and MPDN Video Renderer - Composition Video Output Range is set to Full video will still be projected as Limited/TV? This is the first time I've used Ctrl+shift+L to cycle the color spaces, so I wonder how many of the other videos I've played have been converted from PC to TV without me knowing it. I was also surprised to see when I cycled from TV to PC the video image increased in brightness/lost gamma?/became more white saturated. In the past when I'd tested PC/Full (0-255) vs TV/Limited (16-235) I thought it toggled the other way around with TV being brighter/more washed out.
Am I right in guessing that one way to work around the issue (aside from toggling a video when it opens) is for someone to set the Video Input Colormetric in MPDN Composition to one of the PC Ranges which would then prevent MPDN from detecting and over riding PC/Full with TV/Limited? (If someone decided to use the Improve Chroma Reconstruction option - not that I've seen much of a reason to use it).
Edit: On the Chorma/brightness/gamma note. Am I blind, or is there no gamma setting area in the basic options of MPDN?

huhn
26th May 2015, 04:59
Interesting, so even if LAV Video decoder RGB Output Levels is set to PC (0-255), and MPDN Video Renderer - Composition Video Output Range is set to Full video will still be projected as Limited/TV? This is the first time I've used Ctrl+shift+L to cycle the color spaces, so I wonder how many of the other videos I've played have been converted from PC to TV without me knowing it. I was also surprised to see when I cycled from TV to PC the video image increased in brightness/lost gamma?/became more white saturated. In the past when I'd tested PC/Full (0-255) vs TV/Limited (16-235) I thought it toggled the other way around with TV being brighter/more washed out.
Am I right in guessing that one way to work around the issue (aside from toggling a video when it opens) is for someone to set the Video Input Colormetric in MPDN Composition to one of the PC Ranges which would then prevent MPDN from detecting and over riding PC/Full with TV/Limited? (If someone decided to use the Improve Chroma Reconstruction option - not that I've seen much of a reason to use it).

it doesn't matter what you set in lavfilter as RGB video output level as long as you didn't force lavfilter to output RGB.

in general a video file is limited range YCbCr like all BD no exception.

the only case where you should set the MPDN output level to limited TV is when you send a full range RGB signal to a device that can't handle full range to still get correct color.
the description in the video renderer - composition is just wrong.
by default GPU reads the EDID and the EDID tells the GPU what the screen is full range or limited.
the GPU driver always excepts full range values so if you set the range to TV MPDN will output limited range 16-235 and the GPU takes this and thinks this is full range and does a 0-255 to 16-235 conversation for a screen that says limited range.

in short you will get most likely wrong colors with TV settings.

Zachs
26th May 2015, 06:02
Not when you've set your registry to force it to output 0-255. It's hard to cover all the cases in the description which is merely a couple of lines long. There are also a lot of TVs that don't report full range when it's been setup as such (Sammy ones especially). The description assumes everyone has forced their GPU to output 0-255 and ignore EDID which is inaccurate in a lot of cases I've encountered.

Zachs
26th May 2015, 06:05
Edit: On the Chorma/brightness/gamma note. Am I blind, or is there no gamma setting area in the basic options of MPDN?

It was there in a much older version before RenderScripts came about. Changing the gamma is as simple as using the ConvertToLinearLight.hlsl file in an ImageProcessor (you'll have to change the gamma value in the hlsl file though).

foxyshadis
26th May 2015, 12:00
When the playlist extension lands, will it record the last playtime of each file like MPC and WMP? Jumping right back where you left off is so handy I don't know how I did without it.

If not, I'll write an extension that does just that.

huhn
26th May 2015, 13:08
Not when you've set your registry to force it to output 0-255. It's hard to cover all the cases in the description which is merely a couple of lines long. There are also a lot of TVs that don't report full range when it's been setup as such (Sammy ones especially). The description assumes everyone has forced their GPU to output 0-255 and ignore EDID which is inaccurate in a lot of cases I've encountered.

most user will plug in a HDMI cable and didn't hack the registry (with is not needed any more on nvidia and AMD) to get wrong colors on the desktop.

there is one case where TV level are right and that's with GPU 0-255 and TV 16-235. but this is the rares case you will encounter. and it's not a dumb idea to use this with a limited range TV if you only care about video picture quality.

even the number of TV that can do 0-255 is way higher.

ryrynz
26th May 2015, 13:10
When the playlist extension lands, will it record the last playtime of each file like MPC and WMP? Jumping right back where you left off is so handy I don't know how I did without it.

If not, I'll write an extension that does just that.

MPDN already does this. 'Resume playback at last position' under the general options.

Zachs
26th May 2015, 14:46
most user will plug in a HDMI cable and didn't hack the registry (with is not needed any more on nvidia and AMD) to get wrong colors on the desktop.

there is one case where TV level are right and that's with GPU 0-255 and TV 16-235. but this is the rares case you will encounter. and it's not a dumb idea to use this with a limited range TV if you only care about video picture quality.

even the number of TV that can do 0-255 is way higher.

That's exactly what that option is for, but I realised the wording on the description may have been misleading. It wasn't always easy to come up with something precise in a few lines when the issue is rather more complicated.

Anyway, I've changed it to the following.

Full range for all displays, unless you have forced your
GPU to output full range (0-255) but your display still
expects limited range

The previous version of the wording simply assumed everyone's set their GPU to output 0-255. This one should be more accurate, but it's also a bit more vague.

huhn
26th May 2015, 14:56
That's exactly what that option is for, but I realised the wording on the description may have been misleading. It wasn't always easy to come up with something precise in a few lines when the issue is rather more complicated.

Anyway, I've changed it to the following.

Full range for all displays, unless you have forced your
GPU to output full range (0-255) but your display still
expects limited range

The previous version of the wording simply assumed everyone's set their GPU to output 0-255. This one should be more accurate, but it's also a bit more vague.
i wouldn't add a description. i would just add what it does.

TV 16-235 limited range
PC 0-255 full range

the user that doesn't understand what this is for shouldn't touch this anyway.

and a user that is creating a renderer 16-235 -> GPU 0-255 -> TV 16-235 chain usually know what he is doing.

or with other words just hope people don't touch this. the default PC is in 99.9 % of all cases correct.

Miragu
26th May 2015, 20:24
Hi everyone, I'm new here.

I've been setting up MPDN as my main media player for my comp (my old main was KMPlayer) but I can't seem to find a setting that prevents multiple copies of MPDN from opening whenever I default-open a file with MPDN.

With KMPlayer (or any other player I'd imagine) you'd only have one instance of that player and whatever mp3 mp4 you throw at it that one player responds.

Right now the only way for me to do that with MPDN is by dragging&dropping files into the MPDN window. I'm probably overlooking some setting that exists already, can someone enlighten me?

Shiandow
26th May 2015, 22:29
I've made some changes to the debanding script again. I've added grain and made it somewhat better at preserving detail. To remove particularly bad banding it's now reasonably safe to increase the "margin" to 1, or even higher.

Zachs
26th May 2015, 23:11
Hi everyone, I'm new here.

I've been setting up MPDN as my main media player for my comp (my old main was KMPlayer) but I can't seem to find a setting that prevents multiple copies of MPDN from opening whenever I default-open a file with MPDN.

With KMPlayer (or any other player I'd imagine) you'd only have one instance of that player and whatever mp3 mp4 you throw at it that one player responds.

Right now the only way for me to do that with MPDN is by dragging&dropping files into the MPDN window. I'm probably overlooking some setting that exists already, can someone enlighten me?

I'll fix that in the next release.

BRM
27th May 2015, 00:18
A point about Chroma.hlsl: chroma scaling can be made more efficient (80-100% performance boost) by merging the chroma channels first before scaling.

On the topic of colour processing, the gamma curves seem wrong; the sRGB values don't seem to match the spec, and the BT.709 curve doesn't seem like it was implemented correctly (and, by extension, BT.2020).

Regarding Mpdn.Lut3D.cs: Just adding a 3DLUT is not the right solution, unless you intend for your viewers to generate the right files and switch to the right path for every new file they want to view.

Would you mind pming me the part of the code that deals with the colour conversion logic?

Anime Viewer
27th May 2015, 00:47
Anyway, I've changed it to the following.

Full range for all displays, unless you have forced your
GPU to output full range (0-255) but your display still
expects limited range

The previous version of the wording simply assumed everyone's set their GPU to output 0-255. This one should be more accurate, but it's also a bit more vague.

Did you make the changes by updating the extensions in some way as opposed to MPDN? (The MPDN version listed as the latest version in the OP is still version v2.26.4).

Zachs
27th May 2015, 00:48
A point about Chroma.hlsl: chroma scaling can be made more efficient (80-100% performance boost) by merging the chroma channels first before scaling.

On the topic of colour processing, the gamma curves seem wrong; the sRGB values don't seem to match the spec, and the BT.709 curve doesn't seem like it was implemented correctly (and, by extension, BT.2020).

Regarding Mpdn.Lut3D.cs: Just adding a 3DLUT is not the right solution, unless you intend for your viewers to generate the right files and switch to the right path for every new file they want to view.

Would you mind pming me the part of the code that deals with the colour conversion logic?

If you feel you can make something faster or better, feel free to contribute. That's the point of open source after all.

Are you saying BT.601 is correct by BT.709 and BT.2020 aren't? Could you let us know how you're testing it?

I implemented Lut3D based on what Asmodian said in this thread, which seems to be the way madVR works too IIRC. What is your expectation with Lut3D? Then again, it's open source too so feel free to propose changes on Github.

Zachs
27th May 2015, 00:49
Did you make the changes by updating the extensions in some way as opposed to MPDN? (The MPDN version listed as the latest version in the OP is still version v2.26.4).

No no I meant it's been changed for the next release.

BRM
27th May 2015, 01:02
If you feel you can make anything faster, feel free to contribute. That's the point of open source after all.

Will do, unless Shiandow fixes it first. It's pretty trivial though, upscaling each channel individually is considerably more resource intensive, anyone can see that.


Are you saying BT.601 is correct by BT.709 and BT.2020 aren't? Could you let us know how you're testing it?

The gamma logic is broken, and that's what I was talking about, that whole part of the post:
https://github.com/zachsaw/MPDN_Extensions/blob/master/Extensions/RenderScripts/Common/ColourProcessing.hlsl



I implemented Lut3D based on what Asmodian said in this thread, which seems to be the way madVR works too IIRC. What is your expectation with Lut3D? Then again, it's open source too so feel free to propose changes on Github.
My expectation for color management is that I give the program an ICC profile (it can also query the system-wide profile using windows APIs) and it'll handle the rest, then generate a static 3DLUT based on this profile against BT.2020 as the connection space.

foxyshadis
27th May 2015, 01:07
MPDN already does this. 'Resume playback at last position' under the general options.

My bad. OK, so I just need to figure out why it wasn't working for some videos (because it certainly is for others, now that I'm testing), and report that.

I've made some changes to the debanding script again. I've added grain and made it somewhat better at preserving detail. To remove particularly bad banding it's now reasonably safe to increase the "margin" to 1, or even higher.

Awesome! Now I don't need a separate shader adding grain at the end. Actually wait, riddle me this: Is deband best used at native resolution or after resize? If native, I'll keep a soft full-size grain.

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

One last request that is probably also already in the player: ...wait, never mind, just found it. I'm getting less blind! OK, how about this instead: Would it be possible to add Scripted Render Chains to Script Groups and Script Chains? Seems like the lack of those was just an oversight. Also, if Script Group is the selected script, it'd be nice if its contents were listed in a menu and a context submenu, with its shortcut keys shown.

I wouldn't mind a shortcut to open up the properties of the current Render Script, but maybe I can figure out a way to do that with an extension.

Zachs
27th May 2015, 01:25
One last request that is probably also already in the player: ...wait, never mind, just found it. I'm getting less blind! OK, how about this instead: Would it be possible to add Scripted Render Chains to Script Groups and Script Chains? Seems like the lack of those was just an oversight. Also, if Script Group is the selected script, it'd be nice if its contents were listed in a menu and a context submenu, with its shortcut keys shown.

I wouldn't mind a shortcut to open up the properties of the current Render Script, but maybe I can figure out a way to do that with an extension.

Yeah you just have to change ScriptedRenderChain's category to anything other than "Hidden". It's not fully done yet that script and I'm actively working on this, which is why I have chosen to keep it hidden for now.

We'd love to have you as one of MPDN's devs!
Adding a shortcut to open up the properties would be great indeed. It's definitely doable and would be a good starting point!

Zachs
27th May 2015, 01:38
Will do, unless Shiandow fixes it first. It's pretty trivial though, upscaling each channel individually is considerably more resource intensive, anyone can see that.

Not always. But feel free to propose the changes and we can discuss further.

My expectation for color management is that I give the program an ICC profile (it can also query the system-wide profile using windows APIs) and it'll handle the rest, then generate a static 3DLUT based on this profile against BT.2020 as the connection space.

I'm sure you'll be able to extend the Lut3D script to do this. Can't wait for your contribution! Welcome to the team.

Shiandow
27th May 2015, 02:13
The gamma logic is broken, and that's what I was talking about, that whole part of the post:
https://github.com/zachsaw/MPDN_Extensions/blob/master/Extensions/RenderScripts/Common/ColourProcessing.hlsl


Broken in what way exactly? Anyway, if you think you know a way to improve it then feel free to add those changes to github.

ryrynz
27th May 2015, 02:17
riddle me this: Is deband best used at native resolution or after resize?


Everything I've seen online recommends debanding after resizing for better quality.

huhn
27th May 2015, 02:30
Everything I've seen online recommends debanding after resizing for better quality.

debanding at source resolution make way more sense.

resizing adds ringing and and other artefacts and the banding error is spread over a usually larger number of pixel because you are usually upscaling so it is way harder to fix.

Zachs
27th May 2015, 13:21
I double click to enter FSE (I'll try using ALT+Enter to see if it has the same effect). It does happen every time (except for the one file I previously noted) I enter FSE with Direct3D 11 or 10.1 selected (it doesn't seem to happen with 9Ex). It happens immediately once full screen occurs it doesn't appear a single frame plays in fullscreen before the freeze. *Edit: odd ; my tests today don't seem to be freezing. I'm not sure what to attribute the problem going away to, but its nice that the problem is gone (hopefully it will stay that way)...

I know you said the problem is gone but if you encounter MPDN locking up again entering FSE mode, you should now get a crash after a max of 60 seconds (usually much faster though) whenever MPDN locks up. It was actually not working before as I had the conditionals set the wrong way around - i.e. it worked in debug mode but not in release mode when I intended it to work only in release mode. This is now fixed.

Anime Viewer
27th May 2015, 13:32
I know you said the problem is gone but if you encounter MPDN locking up again entering FSE mode, you should now get a crash after a max of 60 seconds (usually much faster though) whenever MPDN locks up. It was actually not working before as I had the conditionals set the wrong way around - i.e. it worked in debug mode but not in release mode when I intended it to work only in release mode. This is now fixed.

Interesting you should mention that. I installed the new version (2.27.0), and had it remove all configuration settings. The first video I tried (one of the ones that crashed it before) it crashed again when I went full screen. This time a (windows?) crash box popped up reporting MPDN had stopped responding with the option to close it. The bad news is the problem is back, but the good news is it now closes out properly when that happens. I thought the settings I set after the install of 2.27 were the same as the previous version, but I'll have to tinker around to see if I'm able to get it back to a non-crash state for FSE+D3D11 and determine where the problem is...

Zachs
27th May 2015, 13:34
Interesting you should mention that. I installed the new version (2.27.0), and had it remove all configuration settings. The first video I tried (one of the ones that crashed it before) it crashed again when I went full screen. This time a (windows?) crash box popped up reporting MPDN had stopped responding with the option to close it. The bad news is the problem is back, but the good news is it now closes out properly when that happens. I thought the settings I set after the install of 2.27 were the same as the previous version, but I'll have to tinker around to see if I'm able to get it back to a non-crash state for FSE+D3D11 and determine where the problem is...

Good! Could you get the dump for me please?

Anime Viewer
27th May 2015, 13:43
Good! Could you get the dump for me please?

Here is what I pulled from Windows Event Viewer Details. If you need me to look up something else in that error log let me know.


Log Name: Application
Source: Application Error
Date: 5/27/2015 5:37:41 AM
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: Sager-NP9150
Description:
Faulting application name: MediaPlayerDotNet.exe, version: 2.27.0.3100, time stamp: 0x5565b10c
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0x00000000
Fault offset: 0x00007ffd87273969
Faulting process id: 0x2500
Faulting application start time: 0x01d09879e1159c4b
Faulting application path: E:\Program Files\MediaPlayerDotNet\MediaPlayerDotNet.exe
Faulting module path: unknown
Report Id: 29f8b9bc-046d-11e5-bf55-4e53504f4f46
Faulting package full name:
Faulting package-relative application ID:
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2015-05-27T12:37:41.000000000Z" />
<EventRecordID>117903</EventRecordID>
<Channel>Application</Channel>
<Computer>Sager-NP9150</Computer>
<Security />
</System>
<EventData>
<Data>MediaPlayerDotNet.exe</Data>
<Data>2.27.0.3100</Data>
<Data>5565b10c</Data>
<Data>unknown</Data>
<Data>0.0.0.0</Data>
<Data>00000000</Data>
<Data>00000000</Data>
<Data>00007ffd87273969</Data>
<Data>2500</Data>
<Data>01d09879e1159c4b</Data>
<Data>E:\Program Files\MediaPlayerDotNet\MediaPlayerDotNet.exe</Data>
<Data>unknown</Data>
<Data>29f8b9bc-046d-11e5-bf55-4e53504f4f46</Data>
<Data>
</Data>
<Data>
</Data>
</EventData>
</Event>

Zachs
27th May 2015, 13:53
Here is what I pulled from Windows Event Viewer Details. If you need me to look up something else in that error log let me know.

Ah not that one - The windows one is pretty useless. I meant the MPDN dump file in %localappdata%\MediaPlayerDotNet\*.dump.

Anime Viewer
27th May 2015, 14:04
Ah not that one - The windows one is pretty useless. I meant the MPDN dump file in %localappdata%\MediaPlayerDotNet\*.dump.

Yeah, I thought that was a pretty useless looking error report. I checked %localappdata%\MediaPlayerDotNet\ , but I didn't see any file(s) with a .dump extension there.

Like the previous windows log this one is probably pretty useless too, but this always seems to follow the error log report as the next report in the system:


Log Name: Application
Source: Windows Error Reporting
Date: 5/27/2015 5:38:14 AM
Event ID: 1001
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: Sager-NP9150
Description:
Fault bucket 94746202975, type 5
Event Name: CLR20r3
Response: Not available
Cab Id: 0

Problem signature:
P1: MediaPlayerDotNet.exe
P2: 2.27.0.3100
P3: 5565b10c
P4: MediaPlayerDotNet
P5: 2.27.0.3100
P6: 5565b10c
P7: 3ea
P8: f
P9: Debugger.Break
P10:

Attached files:
C:\Users\***\AppData\Local\Temp\WERC366.tmp.WERInternalMetadata.xml
C:\Users\***\AppData\Local\Temp\WERCF10.tmp.appcompat.txt
C:\Users\***\AppData\Local\Temp\WERCF30.tmp.dmp
C:\Users\***\AppData\Local\Temp\WERD0D7.tmp.WERDataCollectionFailure.txt

These files may be available here:
C:\Users\***\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_MediaPlayerDotNe_7582a8bebb5aa47c432efd010f3a12a1dcbcb3_73e57eb4_1dc94057

Analysis symbol:
Rechecking for solution: 0
Report Id: 29f8b9bc-046d-11e5-bf55-4e53504f4f46
Report Status: 4104
Hashed bucket: 7a289c426c2e45f2a04efb3925513ac6
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Windows Error Reporting" />
<EventID Qualifiers="0">1001</EventID>
<Level>4</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2015-05-27T12:38:14.000000000Z" />
<EventRecordID>117905</EventRecordID>
<Channel>Application</Channel>
<Computer>Sager-NP9150</Computer>
<Security />
</System>
<EventData>
<Data>94746202975</Data>
<Data>5</Data>
<Data>CLR20r3</Data>
<Data>Not available</Data>
<Data>0</Data>
<Data>MediaPlayerDotNet.exe</Data>
<Data>2.27.0.3100</Data>
<Data>5565b10c</Data>
<Data>MediaPlayerDotNet</Data>
<Data>2.27.0.3100</Data>
<Data>5565b10c</Data>
<Data>3ea</Data>
<Data>f</Data>
<Data>Debugger.Break</Data>
<Data>
</Data>
<Data>
C:\Users\***\AppData\Local\Temp\WERC366.tmp.WERInternalMetadata.xml
C:\Users\***\AppData\Local\Temp\WERCF10.tmp.appcompat.txt
C:\Users\***\AppData\Local\Temp\WERCF30.tmp.dmp
C:\Users\***\AppData\Local\Temp\WERD0D7.tmp.WERDataCollectionFailure.txt</Data>
<Data>C:\Users\***\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_MediaPlayerDotNe_7582a8bebb5aa47c432efd010f3a12a1dcbcb3_73e57eb4_1dc94057</Data>
<Data>
</Data>
<Data>0</Data>
<Data>29f8b9bc-046d-11e5-bf55-4e53504f4f46</Data>
<Data>4104</Data>
<Data>7a289c426c2e45f2a04efb3925513ac6</Data>
</EventData>
</Event>


If you think any of those files dumped in the Temp directory may be of use let me know, and I can provide them.

Zachs
27th May 2015, 14:08
What files have you got in there?

Edit: your MPDN config, not temp folder obviously.

ryrynz
27th May 2015, 14:17
Just had MPDN crash myself (stopped responding) at the time I was deleting some files off another drive whilst it was just sitting there on the desktop. Windows logged the error, no MPDN dump file.
Have ticked the debug dialogue box now.. will see if it happens again.

Zachs
27th May 2015, 14:21
OK hang detection clearly isn't working then. It should've created a dump file.
And I'll add an option to enable it only when necessary.

toniash
27th May 2015, 14:51
I've made some changes to the debanding script again. I've added grain and made it somewhat better at preserving detail. To remove particularly bad banding it's now reasonably safe to increase the "margin" to 1, or even higher.

What about madvr's version?
I'm locked in XP and can't use MPDN

huhn
27th May 2015, 15:03
What about madvr's version?
I'm locked in XP and can't use MPDN

you can replace the deband hlsl data from the renderer extension with the one in madVR.

you find them under legal stuff\Shiandow\Deband

this should work but never tried it my self.

BTW. this is the wrong threads for madVR "problems"

Shiandow
27th May 2015, 15:22
What about madvr's version?
I'm locked in XP and can't use MPDN

You should realyl ask those questions in the MadVR thread. In fact madshi already posted that he would update MadVR's version as well.

you can replace the deband hlsl data from the renderer extension with the one in madVR.

you find them under legal stuff\Shiandow\Deband

this should work but never tried it my self.

BTW. this is the wrong threads for madVR "problems"

That doesn't work, there are some subtle differences between the shaders, and the way they are used. Hopefully it'll be possible some day, but that could be a while.

huhn
27th May 2015, 15:25
That doesn't work, there are some subtle differences between the shaders, and the way they are used. Hopefully it'll be possible some day, but that could be a while.

i replaced it and it still works.
but i'm not going to continue on this topic here you have your own thread right?

toniash
27th May 2015, 17:46
i replaced it and it still works.
but i'm not going to continue on this topic here you have your own thread right?
Ok thanks!

Zachs
28th May 2015, 00:26
Apart from the app hang detection bug, how are you guys finding the improved "Improve chroma reconstruction" option?
From my own tests, I can see clear improvements.

Anime Viewer
28th May 2015, 00:35
Apart from the app hang detection bug, how are you guys finding the improved "Improve chroma reconstruction" option?
From my own tests, I can see clear improvements.

As long as I set the Video Input Colormetric to one of the PC Ranges it looks fine, but if my system mis-detects the video, and sets it to one of the TV Ranges (while set to automatic) then I get the results I previously posted.

Can't say I've seen the clear improvements you mention, but then again I don't know what I'd be looking for to have changed. (I already thought video looked pretty good before it). Are there any particular style of scenes (with particular effects occurring) you'd say are something where the difference should jump out at us?

Zachs
28th May 2015, 00:38
A fully saturated red is the best way to see the changes. Previously you'll get some random pixels appearing overly bright on other parts of the red that is duller.

Anime Viewer
28th May 2015, 00:50
A fully saturated red is the best way to see the changes. Previously you'll get some random pixels appearing overly bright on other parts of the red that is duller.

I paused a scene where there are a couple of different shades of red, but I'm not seeing a difference between it being enabled/disabled.
Does the video have to be running in Full Screen Exclusive Mode for the improvement to happen?
How about settings? Any particular ones that might make it stand out more, or where other effects might make it less noticeable? (For example: with or without render scripts running, with or without debanding, with or without dithering, with any particular Presentation API (D3D 11, 10.1, 9Ex), with any particular color settings (ex: PC Range BT 601, 709 or 2020, Full or Limited Output, 8,10,or 16 bit bit depth, using any particular up/down scalers?