View Full Version : Media Player .NET (MPDN) - D3D HQ GPU Video Renderer [v2.49.0/v1.31.0 27 Dec 2018]
Keiyakusha
6th May 2015, 01:44
Hmm it doesn't support multi video streams yet. Haven't come across any clips that contain more than one video stream. Any chance you could get me a sample?
Certainly, but I haven't visited this forum for quite a while and don't know what is ok to post, what is not. So I'll PM it to you, if you don't mind.
ryrynz
6th May 2015, 02:03
Zach, reverting to Nvidia's driver 347.88 fixes the out of memory error.
Ah, that might be a 750ti specific bug in Nvidia's driver then because I'm running the latest 350.12 and I didn't get this problem at all.
Ah okay, I see what you guys meant now. Same issue is still present upon maximizing and resizing the window and going to fullscreen.
I'll see what else I can do to work around this bug.
EDIT: Found out what the problem is - it was my bad :o Turns out I made a tiny little error in the OpenCL NNEDI3 render script so I've reverted MPDN back to v2.25.15 and fixed the script. This should now work properly with the latest scripts from github. Oh and it should now be even faster.
ryrynz
6th May 2015, 08:25
~checks Zach's homepage~ .15? Didn't I download .16? He hasn't updated his homepage.. but doesn't he link from his homepage?
~checks forum~ Ahh, reverting builds and improving performance, that's a + 0.1 surely.. ah renderscipt based changes.. Roll on 2.26!
Hahaha... .16 didn't do anything, so I went back to.15.
There'll be a proper .16 later today which fixes a bug when you chain up multiple OpenCL scripts...
ryrynz
6th May 2015, 09:15
Zach, reverting to Nvidia's driver 347.88 fixes the out of memory error.
Ah, that might be a 750ti specific bug in Nvidia's driver then because I'm running the latest 350.12 and I didn't get this problem at all.
Oh it fixed it alright.. and I found an even bigger bug, OpenCL NNEDI3 silently just fails to work and MPDN behaves as if it hasn't even been selected.
Huh? Strange! I haven't seen anything like that!
ryrynz
6th May 2015, 10:17
Happens only with max render performance set, I've resolved the out of memory error with a clean graphics driver install, guess it's best to do that every time..
Yup. Replicated. Not sure if I should spend any time fixing it though - max render performance should only be used with systems that is so low end even hardware bilinear is a little too much for it... In fact, it doesn't even have enough precision to convert YUV to RGB properly!
ryrynz
6th May 2015, 12:26
Well if you think it's useful.. BTW do you experience any benefit to enabling render performance? It didn't really do much for me, GPU usage was pretty much the same.
I'm getting about 0.5ms less rendering time on the HD 4000 uses a slightly less memory as well, guess it's worth having there.
It's mainly for tablets SoC with LPDDR3 - i.e. very low memory bandwidth systems. On those systems, you could choose to sacrifice quality for features like Fluid Motion.
EDIT: BTW, DirectCompute won't work with Max Performance selected either. I think I'll just update the scripts so they fallback to MPDN scalers when Max Perf is selected. There's really no reason to use OpenCL or DirectCompute if your GPU has to run with Max Performance.
any idea on how to stop delayed frames?
mrcorbo
7th May 2015, 00:29
Have you checked your event logs for anything useful?
Try deleting ScriptAsmCache.(32 or 64) in %localappdata%\MediaPlayerDotNet. Maybe something got corrupted there?
Heck, might aswell delete it all if that doesn't work and see if that helps.
I tried this and no joy. Thanks for the suggestion, though.
mrcorbo
7th May 2015, 00:36
Try with the latest version - I found a problem that may have been related (not very confident it's what you're seeing though).
Still get the crash. Thanks for giving it a shot. Since no one else is seeing this, it's got to be something weird with my system.
any idea on how to stop delayed frames?
It shouldn't happen if you don't go near the limits. Delayed frames happen when the GPU is so busy it doesn't even have time to present the frame when it was asked.
Still get the crash. Thanks for giving it a shot. Since no one else is seeing this, it's got to be something weird with my system.
Does it happen if you close the file with CTRL+C first?
mrcorbo
7th May 2015, 01:17
Does it happen if you close the file with CTRL+C first?
No. But that exits fullscreen and being in fullscreen is part of the trigger. The other seems to be either having the menu open or the exit option specifically as alt+f4-ing exits with no crash.
Hmm, perhaps I could do something to make sure it exits full screen exclusive mode first before closing. It only happens in exclusive mode right?
Hmm i'm getting delayed frames still with these settings on an amd 290
dx9ex
no fluid
no dithering
bicubic no ar for all scalers
no render scripts
8 bit
max render performance
What is your present duration like? It should be less than 1ms. If not you could play around with new render path on/off, DWM sync on/off, go into full screen exclusive mode to see if it changes present duration.
ryrynz
7th May 2015, 01:52
No. But that exits fullscreen and being in fullscreen is part of the trigger. The other seems to be either having the menu open or the exit option specifically as alt+f4-ing exits with no crash.
Not display driver related is it? Try a clean install? or previous versions?
Have you checked your .NET installation with the repair tool?
What is your present duration like? It should be less than 1ms. If not you could play around with new render path on/off, DWM sync on/off, go into full screen exclusive mode to see if it changes present duration.
I tried all that and i still get delayed frames. Average render times is between 6-7ms
What was your present time?
That looks OK. Besides the delayed frame count, does it actually feel like it's stuttering when you have fluid motion enabled?
I only notice it when its a lot of delayed frames. When its 1 delayed frame I don't notice it.
Max present duration is also less than 1ms?
Max present is very random its 6-15ms
That's the problem!
The only time I've seen that is if the hardware is overclocked a little too much, or a driver that is misbehaving.
I tried stock settings for my gpu and its still the same Max present times. So you think its a driver issue?
Try different driver versions perhaps? My old ATI card had this problem too but changing those settings I pointed out earlier, I managed to find some that the driver was happy with. Oh maybe try direct 3d 11 too. But in exclusive mode I've never seen it with any GPUs.
Oh and try changing back buffer counts too.
mrcorbo
7th May 2015, 13:30
Hmm, perhaps I could do something to make sure it exits full screen exclusive mode first before closing. It only happens in exclusive mode right?
No, it does it even if exclusive mode is disabled. I think MPDN exits exclusive mode when you activate the right-click menu anyway, or at least it seems like it does.
mrcorbo
7th May 2015, 13:39
Not display driver related is it? Try a clean install? or previous versions?
Have you checked your .NET installation with the repair tool?
I haven't tried different drivers yet. The crashes have been in ntdll.dll or clr.dll, so probably .NET related. I'll check out the repair tool when I have some time. Thanks.
Just a quick heads up. I've updated the OpenCL NNEDI3 scripts on github. Let me know if it's faster / slower for you.
Anime Viewer
8th May 2015, 04:02
Just a quick heads up. I've updated the OpenCL NNEDI3 scripts on github. Let me know if it's faster / slower for you.
The updated OpenCL NNEDI3 is completely unusable for me. When I first tried to set it I got a black screen (no video) with 3-4ms being listed. When I exited MPDN, went back in changed to the original NNEDI3 (to confirm it still worked), and then tried to go back to OpenCL NNEDI3 it had a frozen video screen and the hour glass spinning indefinitely. I couldn't escape the freeze or shut down MPDN, and had to log off then re-log in to get it to close.
Hmm, might have encountered an NVIDIA OpenCL compiler bug there. I don't have access to my 560 GTX at the moment so I think I'll revert the changes until I can fully test it on NV's latest drivers.
EDIT: I tested this on an NV 8400GS with driver v341.44 and it's fully working... What version are you running by the way?
EDIT2: Anyone else with the same problem?
ryrynz
8th May 2015, 05:53
EDIT2: Anyone else with the same problem?
Can confirm you borked it.
OK I'll revert it then, at least until I get a chance to test it on my 560 GTX.
It does run on your Intel HD4000 though right?
ryrynz
8th May 2015, 06:02
Yup, fine on HD graphics.
Anima123
8th May 2015, 06:11
Same here as 'Anime Viewer'.
Yeah looks like a bug in NV's newer drivers.
ryrynz
8th May 2015, 10:39
Yeah looks like a bug in NV's newer drivers.
Shame, it sped up NNEDI3 16 taps on my HD4000 by over 20%, getting similar performance gains on Nvidia would deliver better performance than madVR (at least on my card)
Still can't recommend it for Intel though it's almost twice as slow as the shader version 'prefer vector & small code'. I would quite like to see what NNEDI3 performance is like on Skylake's GT4e.
Ah it was never meant to speed up NV hardware!
Are you saying MPDN's OpenCL NNEDI3 is slower than madVR on your card? That's not the case on my 560GTX...
Btw I've uploaded the changes to GitHub, reverting only NV's code path.
I'd like to get some feedback on whether AMD users are gaining/losing performance from the changes at all. As for Intel, it is ~20% faster.
Anime Viewer
8th May 2015, 13:23
Hmm, might have encountered an NVIDIA OpenCL compiler bug there. I don't have access to my 560 GTX at the moment so I think I'll revert the changes until I can fully test it on NV's latest drivers.
EDIT: I tested this on an NV 8400GS with driver v341.44 and it's fully working... What version are you running by the way?
I'm running v350.12 (which uses OpenCL 1.2). Your v341.44 runs OpenCL 1.1 correct? There probably is a good chance that the problem is related to how Nvidia's OpenCL 1.2 and 1.1 differ as opposed to something else in the driver. I wouldn't be surprised if the other people who are encountering the same problem as me are running Nvidia's OpenCL 1.2 as well.
Running it with my Intel 4000 gpu NNEDI3 was still unusable (running at 246ms by itself, and 300ms as part of a script chain with debanding and superchromares).
Well it won't do 720p on my Intel HD4600 but for lower res upscaling it works just fine. It's those lower res sources that arguably need NNEDI3 more than the higher res ones.
flacattack
9th May 2015, 02:35
Starting with the newer builds (around April 30th), I get a blank screen when trying to use SuperRes with my r9 290x. The other scripts work perfect.
InvalidArgument=Value of '0' is not valid for 'SelectedIndex'.
Parameter name: SelectedIndex
Shiandow
9th May 2015, 03:03
You probably need to reset SuperRes's settings. There should be a "SuperRes.config" file somewhere, you can just delete that. Or if it's in a script chain you can just remove it and then add it back again.
flacattack
9th May 2015, 04:26
Worked like a charm, thank you Shiandow!
ryrynz
9th May 2015, 05:16
Hey Zach, feature request! Reset to defaults! :)
That was always in the plan but it's not that easy. There are a few 'reset to defaults' that I'd like to see - within each render script / player extension, and a global one that resets all of MPDN's config to default as well as one that wipes both MPDN, render scripts and player extensions config. Haven't figured out a way to do that yet...
Just a quick heads up. I've added OpenCL NNEDI3 as a prescaler of SuperRes.
You'll need to delete "%localappdata%\MediaPlayerDotNet\RenderScripts.x??\SuperRes.config" again for this option to appear after you've downloaded the new scripts from GitHub.
nekromantik
9th May 2015, 14:25
To upscale anything to 4k is this chain good enough? if not any suggestions.
NNEDI -> SuperChromaRes + NNEDI
Zachs
10th May 2015, 04:18
I'm not sure I understand your script chain at all.
Specifically what does NNEDI -> SuperChromaRes + NNEDI mean?
nekromantik
10th May 2015, 11:25
I'm not sure I understand your script chain at all.
Specifically what does NNEDI -> SuperChromaRes + NNEDI mean?
Sorry ignore the + NNEDI.
It goes NNEDI image doubling and then SuperChromaRes upscaling.
Or is SuperRes with NNEDI and then SuperChromaRes better?
Zachs
10th May 2015, 12:27
You have to scale chroma before you can use any render script upscalers. SuperChromaRes has to come before NNEDI in your case. I usually do deband right after chroma upscaling, then followed by NNEDI3 with SuperRes (very low strength). Even when running NNEDI3 with 64 neurons on my gtx680, I still find SuperRes to increase image quality both in sharpening and reducing aliasing.
nekromantik
10th May 2015, 16:26
You have to scale chroma before you can use any render script upscalers. SuperChromaRes has to come before NNEDI in your case. I usually do deband right after chroma upscaling, then followed by NNEDI3 with SuperRes (very low strength). Even when running NNEDI3 with 64 neurons on my gtx680, I still find SuperRes to increase image quality both in sharpening and reducing aliasing.
Thanks will give that a go.
Shiandow
11th May 2015, 00:20
Hi there! I made some changes to the renderscripts again, based on the feedback on the MadVR thread and some of things madshi noticed while implementing them.
A short summary:
- Tried to improve the quality of the debanding, it should have less artifacts around edges and might be slightly faster.
- SuperChromaRes now works in rgb, this should improve quality and be slightly faster, although the anti-ringing still needs some work, it'll work correctly, but the performance isn't too good at the moment.
- Some minor performance tweaks / fixes to SuperRes and SuperChromaRes.
- Better defaults for SuperRes and SuperChromaRes.
Zachs
11th May 2015, 00:50
Hmm just found out madVR is in violation of the LGPL license (section 4d and/or 4e) - i.e. including the source isn't enough. Section 4d requires that the user be able to modify the LGPL source and have the app run the modified version and/or link to it. MadVR is also in violation of section 4c which requires that it displays a proper copyright notice. The ancillaries required to run those shaders have also been converted to closed source, which is also in violation of LGPL.
On a similar note, it would appear that its NNEDI3 implementation is also in violation of LGPL, as changing the included source in the zip file won't affect madVR's implementation. The original NNEDI3 OpenCL source code by SEt is LGPL and is in full compliance with LGPL.
Anima123
11th May 2015, 04:03
I hate to mention it, especially in such a circumstance, but, using NEDI with SuperRes via madVR does not suffer from rendering time increasing for my laptop.
Zachs
11th May 2015, 05:29
Seeing as no one else with Optimus has seen this problem, could it be something to do with your .NET installation?
Anima123
11th May 2015, 08:12
How can I tell if my .NET is damned? Any suggestions on how to get a 'clean' installation of it?
ryrynz
11th May 2015, 08:21
How can I tell if my .NET is damned? Any suggestions on how to get a 'clean' installation of it?
.NET Framework Repair Tool (https://www.microsoft.com/en-us/download/details.aspx?id=30135)
madshi
11th May 2015, 08:36
Hmm just found out madVR is in violation of the LGPL license (section 4d and/or 4e) - i.e. including the source isn't enough. Section 4d requires that the user be able to modify the LGPL source and have the app run the modified version and/or link to it. MadVR is also in violation of section 4c which requires that it displays a proper copyright notice. The ancillaries required to run those shaders have also been converted to closed source, which is also in violation of LGPL.
On a similar note, it would appear that its NNEDI3 implementation is also in violation of LGPL, as changing the included source in the zip file won't affect madVR's implementation. The original NNEDI3 OpenCL source code by SEt is LGPL and is in full compliance with LGPL.
Ok, sorry. I thought providing the source code would be enough. I will do the necessary changes in the next build. FWIW, I'm only using Shiandow's code, not yours, and he had allowed me via PM to hard code his algorithms into madVR as a stop-gap measure until my own "extended custom shader" feature is implemented. Anyway, as I said, it was not my intention to violate any licenses, so I'll fix that.
BTW, since you mentioned NNEDI3: I think MPDN is in violation, too. The OpenCL kernel is LGPL, but the weight database is GPL. SEt wrote a "new" kernel, so he probably had the right to license it under LGPL (and I'm happy that he did), but he didn't recreate the weights, so the weights are still part of the original NNEDI3 package, which is GPL. Nobody can recreate the weights because that part of NNEDI3 was never published, not even under GPL, AFAIK. tritical has explicitly allowed me to use the weights in closed source madVR. Has he allowed that for MPDN, too?
Zachs
11th May 2015, 09:12
Uh, you do understand what GPL is, don't you? They cover source code, not data files. And the weights are freely available on GitHub from Avisynth plugin source. Unless Tritical makes specific mention of the use of the trained datasets, I'm not sure how you could claim it cannot be used.
Zachs
11th May 2015, 09:14
Btw MPDN does not have NNEDI3.
Zachs
11th May 2015, 09:33
Also your NNEDI3 is based on SEt's source which is LGPL. Whether or not you have permission from tritical isn't relevant at all.
madshi
11th May 2015, 10:03
The GPL says: "“The Program” refers to any copyrightable work licensed under this License". I see no limitation to source code. E.g. there are also icons available under GPL (e.g. http://genericons.com). From what I can see, tritical has released the whole NNEDI3 package under GPL, which AFAICS would include the weights. See here:
http://bengal.missouri.edu/~kes25c/
You do understand that the weights are the very core of the NNEDI3 algorithm? The kernel we're using is just a small part of NNEDI3. The weights are where all the magic comes from. Without the weights the kernel is just an empty shell. And whether or not something is "freely available" on some website has no effect on licenses - unless tritical has officially changed his license on that website.
Anyway, I'm out of here. I wouldn't have said anything about your use of the NNEDI3 weights. But since you seemed so interested in clearing up any NNEDI3 related legal issues, I thought I'd mention this potential issue, too...
Belphemur
11th May 2015, 11:40
Ok, sorry. I thought providing the source code would be enough. I will do the necessary changes in the next build. FWIW, I'm only using Shiandow's code, not yours, and he had allowed me via PM to hard code his algorithms into madVR as a stop-gap measure until my own "extended custom shader" feature is implemented. Anyway, as I said, it was not my intention to violate any licenses, so I'll fix that.
BTW, since you mentioned NNEDI3: I think MPDN is in violation, too. The OpenCL kernel is LGPL, but the weight database is GPL. SEt wrote a "new" kernel, so he probably had the right to license it under LGPL (and I'm happy that he did), but he didn't recreate the weights, so the weights are still part of the original NNEDI3 package, which is GPL. Nobody can recreate the weights because that part of NNEDI3 was never published, not even under GPL, AFAIK. tritical has explicitly allowed me to use the weights in closed source madVR. Has he allowed that for MPDN, too?
If we come to the Licenses used, and from my understanding. The version of SEt can't be LGPL, it's a violation of the GPL license of the original NNEDI3 that is under GPL.
GPLv2 is a very restrictive license asking the developer that use a GPL lib/source code to be GPL also. In other word, if SEt used even a fraction of the code of NNEDI3, he can't release it as LGPL but must use the same license (since you can only go to more and more restrictive). This is were the first mistake was done.
Again, this my understanding of the way the license work, it can be wrong, and I'd be happy to be corrected.
NNEDI Orignal : http://forum.doom9.org/showthread.php?t=147695
OpenCL SEt : http://forum.doom9.org/showthread.php?t=169766
License compatibility : https://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing
Zachs
11th May 2015, 11:40
Thanks for bringing that to my attention. I am very serious about licensing issues, especially when it comes to free software as I fully believe all credits should always be given to the rightful owners.
However, I'll quote SEt and my believe is in line with his.
Somewhat unknown issue is nnedi3 nn coefficients data: no idea how they are related to licenses since it's not a code. Preprocessed but conceptually unchanged version of them is currently embeded in dll. If tritical has any issues with current situation – I'm ready to listen.
And another quote from yourself,
FWIW, many months ago I had asked tritical about implementing NNEDI3 in madVR, even though madVR is closed source, and he allowed it. So it seems to me he's quite generous with licensing issues, so I don't think you need to worry about that part. Haven't heard from him in a while, though. Not sure if he's still around...
And another from tritical (from your link above),
All filters presented here are either licensed under the GPL or have no license at all (check the source code) *** operative keywords - source code.
The weights we're using for MPDN extensions (see note1) are similar to SEt's preprocessed ones. They came from tritical's bin file. While the whole package is GPL, SEt chose to not open source the coefficients and it is his believes that it does not fall under GPL. MPDN extensions have not put any explicit licenses on it so it falls under the default license which is LGPL. This can be changed though and MPDN extension's NNEDI3 would simply be GPL.
note1: MPDN is render script agnostic - in fact, MPDN does not come distributed with MPDN extensions. This is no different from a user using AviSynth (GPL) and have madVR (closed source) render the frames served. Or the fact that madVR users can use MPC-HC's pixel shader filters.
However, the issue still remains that you can't claim the files you have are under LGPL license when in fact you have not adhered to the licensing terms. This applies for madVR's NNEDI3 code, which as you've said,
SEt wrote a "new" kernel, so he probably had the right to license it under LGPL and your code is based on his OpenCL version.
I'm just trying to make sure everyone respects free software licenses.
Zachs
11th May 2015, 11:52
If we come to the Licenses used, and from my understanding. The version of SEt can't be LGPL, it's a violation of the GPL license of the original NNEDI3 that is under GPL.
GPLv2 is a very restrictive license asking the developer that use a GPL lib/source code to be GPL also. In other word, if SEt used even a fraction of the code of NNEDI3, he can't release it as LGPL but must use the same license (since you can only go to more and more restrictive). This is were the first mistake was done.
Strictly speaking that is correct - but it does fall into a bit of a grey area. GPL is not the right license to use from the very beginning (I'm sure if tritical picks a license today he'd have picked LGPL since he was creating an AviSynth plugin), seeing as it's for programs (read applications) rather than libraries (which LGPL was specifically created to address). So anything that isn't suitably covered by GPL (e.g. icons) falls under that grey area. There's something called the spirit of a contract when lawyers write them up. The spirit of GPL is to make sure the program as a whole and/or any parts of it do not become closed source (LGPL's spirit is inline with GPL in this regard, and naturally so). However, it's being used as a viral licensing term in recent years.
LGPL has a more user-centric spirit, which is why MPDN extensions use it. It mandates that everything that has been done to it can be modified by the end-user (for fixing bugs, optimizing etc.) without having the need to recompile or have access to the host app. However, taking away users' ability to change LGPL portions of the code definitely violates the very spirit of LGPL.
Belphemur
11th May 2015, 12:01
Strictly speaking that is correct - but it does fall into a bit of a grey area. GPL is not the right license to use from the very beginning (I'm sure if tritical picks a license today he'd have picked LGPL), seeing as it's for programs (read applications) rather than libraries (which LGPL was specifically created to address). So anything that isn't suitably covered by GPL (e.g. icons) falls under that grey area. There's something called the spirit of a contract when lawyers write them up. The spirit of GPL is to make sure the program as a whole and/or any parts of it do not become closed source. However, it's being used as a viral licensing term in recent years.
LGPL has a more user-centric spirit, which is why MPDN extensions use it. It mandates that everything that has been done to it can be modified by the end-user (for fixing bugs, optimizing etc.) without having the need to recompile or have access to the host app. However, taking away users' ability to change LGPL portions of the code definitely violates the very spirit of LGPL.
From what I learned LGPL is mostly for libraries since it mean you can use it (when provided with the location of the source and a copy of the licence) in any program under any licence (when used in a compiled version). It was created to keep the open-source spirit but still let proprietary solution use it without stealing.
Of course, if you modify it, you need to republish it and provide it to the end-user but just using it, you need to give credit and it need to be separate from the rest of your code.
Edit: If you put NNEDI3 as GPL, it can't be used in MPDN since the license will propagate to it. (or that's my understanding of GPL) : https://programmers.stackexchange.com/questions/158789/can-i-link-to-a-gpl-library-from-a-closed-source-application
Shiandow
11th May 2015, 12:03
Ok, sorry. I thought providing the source code would be enough. I will do the necessary changes in the next build. FWIW, I'm only using Shiandow's code, not yours, and he had allowed me via PM to hard code his algorithms into madVR as a stop-gap measure until my own "extended custom shader" feature is implemented. Anyway, as I said, it was not my intention to violate any licenses, so I'll fix that.
It seems the LGPL license was slightly more restrictive than I thought, regardless I'd still prefer if you could make MadVR's use compatible with it. So, just to clear up any ambiguity. If you could make it possible to "relink" the shader files as outlined in LGPL in the next build and implement them using the "extended custom shader" support when it is ready, then I have no issues with MadVR using those algorithms (Debanding, Superes and SuperChromaRes).
Zachs
11th May 2015, 12:06
Nobody can recreate the weights because that part of NNEDI3 was never published, not even under GPL, AFAIK.
From what I can see, tritical has released the whole NNEDI3 package under GPL, which AFAICS would include the weights.
So what are you actually saying?
Zachs
11th May 2015, 12:08
It seems the LGPL license was slightly more restrictive than I thought, regardless I'd still prefer if you could make MadVR's use compatible with it. So, just to clear up any ambiguity. If you could make it possible to "relink" the shader files as outlined in LGPL in the next build and implement them using the "extended custom shader" support when it is ready, then I have no issues with MadVR using those algorithms (Debanding, Superes and SuperChromaRes).
I have no issues with that too for any of MPDN's extension files.
Like I said, I'm just trying to make sure the license is respected. LGPL only helps, not hinder - e.g. the typical dev gets run over by a bus scenario, any LGPL portions can still be updated.
Zachs
11th May 2015, 12:11
From what I learned LGPL is mostly for libraries since it mean you can use it (when provided with the location of the source and a copy of the licence) in any program under any licence (when used in a compiled version). It was created to keep the open-source spirit but still let proprietary solution use it without stealing.
Of course, if you modify it, you need to republish it and provide it to the end-user but just using it, you need to give credit and it need to be separate from the rest of your code.
Edit: If you put NNEDI3 as GPL, it can't be used in MPDN since the license will propagate to it. (or that's my understanding of GPL) : https://programmers.stackexchange.com/questions/158789/can-i-link-to-a-gpl-library-from-a-closed-source-application
Well it'll be the user 'linking' it then, in the same manner as anyone who's using MPC-HC's GPL shader files in madVR.
Belphemur
11th May 2015, 12:12
It seems the LGPL license was slightly more restrictive than I thought, regardless I'd still prefer if you could make MadVR's use compatible with it. So, just to clear up any ambiguity. If you could make it possible to "relink" the shader files as outlined in LGPL in the next build and implement them using the "extended custom shader" support when it is ready, then I have no issues with MadVR using those algorithms (Debanding, Superes and SuperChromaRes).
All the code that you wrote, that is not based on any other code, you have full control on the license AND on the written permission. You can give madvr a permission to MadVR to use your code in his environment/program.
Even the GPL state this :
10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.
Belphemur
11th May 2015, 12:15
Well it'll be the user 'linking' it then, in the same manner as anyone who's using MPC-HC's GPL shader files in madVR.
yeah that's the tricky part ... because in the end your program DOES use GPL content which mean, it should be under GPL.
In the case of MPDN extension, as you said, they are under LGPL, MDPN then link to LGPL extension, that's perfectly fine. Now for MadVR and the MPC-HC Gpl, madvr should then be also under GPL ... or ask for a permission from MPC-HC to not be GPL.
madshi
11th May 2015, 12:35
It seems the LGPL license was slightly more restrictive than I thought
Seems we had the same incomplete idea of how LGPL worked. :) Well, a day we don't learn something new is a day wasted, I guess...
regardless I'd still prefer if you could make MadVR's use compatible with it. So, just to clear up any ambiguity. If you could make it possible to "relink" the shader files as outlined in LGPL in the next build and implement them using the "extended custom shader" support when it is ready, then I have no issues with MadVR using those algorithms (Debanding, Superes and SuperChromaRes).
Sure, of course I will do that. Hope to have a new build out today which should be fully LGPL compliant. And thanks again for your nice algos.
So what are you actually saying?
Sorry, I guess my wording has been a bit unclear. Let me try again:
tritical has run thousands (or ten or hundred thousands, I don't remember) of images through some neural network software, to create those weights. Basically this "server side" software has analyzed all those images, extracted edge information from them and somehow fused them into the weight database we're using. The NEDI kernel we're using practically could be considered the "client side" software which just uses the weight database to interpolate images. tritical has released the client side software and the weight database under GPL, but he has not released the server side software with which he created the weights at all. Because of that nobody can create a different/new/updated set of weights. All the NNEDI3 magic is hidden in those weights, they are the center piece of the algorithm.
So to sum up, the client side of the NNEDI3 algorithm is available as GPL, which IMHO includes the weights. The server side is not available at all.
But my understanding is that tritical is actually quite generous. I had asked him about using NNEDI3 in madVR before the OpenCL kernel even existed, and he was ok with that. I think he would most probably allow SEt and the MPDN extensions to use NNEDI3, too, in their current form as LGPL. So maybe you could just PM him to make sure. The key problem is that tritical hasn't been on doom9 for a long time, so it might be difficult to get a reply from him.
If we come to the Licenses used, and from my understanding. The version of SEt can't be LGPL, it's a violation of the GPL license of the original NNEDI3 that is under GPL.
To be honest, I was wondering about that, too. But since I had the "ok" from tritical for using NNEDI3 in madVR, it didn't matter much to me. SEt's kernel being LGPL practically meant that SEt was fine with me using it in madVR (as long as I'm compliant with LGPL, of course). And tritical was fine with it, too, so I was covered in any case.
Now for MadVR and the MPC-HC Gpl, madvr should then be also under GPL ... or ask for a permission from MPC-HC to not be GPL.
Well, I do not distribute MPC-HC, nor do I link in any part of MPC-HC. It's not madVR using MPC-HC. It's the other way round. madVR is also not a plugin to MPC-HC, it's simply an official DirectShow renderer which anyone can use who wants to use it. I don't see how that would have any legal effect on madVR. I mean Microsoft also doesn't have to publish their EVR sources as GPL, just because MPC-HC uses EVR, right?
Shiandow
11th May 2015, 12:35
All the code that you wrote, that is not based on any other code, you have full control on the license AND on the written permission. You can give madvr a permission to MadVR to use your code in his environment/program.
Isn't that what I just did? I made a somewhat limited exception to whatever parts of LPGL are currently violated. It was limited on purpose though, to avoid introducing any more ambiguity.
nevcairiel
11th May 2015, 12:47
Well, I do not distribute MPC-HC, nor do I link in any part of MPC-HC. It's not madVR using MPC-HC. It's the other way round. madVR is also not a plugin to MPC-HC, it's simply an official DirectShow renderer which anyone can use who wants to use it. I don't see how that would have any legal effect on madVR. I mean Microsoft also doesn't have to publish their EVR sources as GPL, just because MPC-HC uses EVR, right?
The entire concept of COM used in DirectShow obfuscates any licensing borders.
By using COM, individual components are never directly linked, and only communicate through a defined and common API.
Its probably impossible for anyone of us to answer if that requires compatible licenses, unless one here is an experienced copyright/license lawyer, and even then if someone would try this in court, it could IMHO go both ways.
Commercial products tend to avoid shipping GPL components like LAV Filters directly, but instead recommend simply installing them manually.
Belphemur
11th May 2015, 12:50
To be honest, I was wondering about that, too. But since I had the "ok" from tritical for using NNEDI3 in madVR, it didn't matter much to me. SEt's kernel being LGPL practically meant that SEt was fine with me using it in madVR (as long as I'm compliant with LGPL, of course). And tritical was fine with it, too, so I was covered in any case.
I think we can also assume tritical have also provided the same kind of permission to SEt. (Let's assume be because ... GPL ... is really one of the messier license where it's OpenSource by OpenSource for OpenSource (which is nice but tricky), that's why they came with LGPL)
Well, I do not distribute MPC-HC, nor do I link in any part of MPC-HC. It's not madVR using MPC-HC. It's the other way round. madVR is also not a plugin to MPC-HC, it's simply an official DirectShow renderer which anyone can use who wants to use it. I don't see how that would have any legal effect on madVR. I mean Microsoft also doesn't have to publish their EVR sources as GPL, just because MPC-HC uses EVR, right?
No of course not, it's a one-way relation. You use GPL, you are GPL. If you're under GPL you can use proprietary software/lib/etc ...
This part of the comment was about the claim of Zachs you use some of the Shader code of MPC-HC, if it's the case, the GPL license propagate to MadVr if you don't have the same kind of permission you got from tritical.
(some light of the GPLv3 : http://blog.milkingthegnu.org/2008/04/gpl-for-dummies.html)
In the case you said with EVR, since EVR is a system lib, no problem else ... it's tricky again ... GPL is really more an ideal than anything else ... and if I'm right, haven't been tested in court either.
Anyway, for that nevcairiel cleared up the question, and well the API is provided by the system.
Isn't that what I just did? I made a somewhat limited exception to whatever parts of LPGL are currently violated. It was limited on purpose though, to avoid introducing any more ambiguity.
Yeap, I just meant, the agreement you did before with madvr was already enough ;)
madshi
11th May 2015, 13:00
I'm not directly using any MPC-HC shader code in madVR. What Zachs meant is that users can setup MPC-HC to send shader code to madVR via an official custom shader interface.
FWIW, I've also asked the LumaSharpen and FineSharp devs (both AviSynth and HLSL), and they were all ok with me using the shaders in madVR. Really, I thought I had everything covered and thought that I did everything correctly. I just wasn't aware of those extended LGPL requirements. I'm working on fixing that right now.
Belphemur
11th May 2015, 13:09
I'm not directly using any MPC-HC shader code in madVR. What Zachs meant is that users can setup MPC-HC to send shader code to madVR via an official custom shader interface.
FWIW, I've also asked the LumaSharpen and FineSharp devs (both AviSynth and HLSL), and they were all ok with me using the shaders in madVR. Really, I thought I had everything covered and thought that I did everything correctly. I just wasn't aware of those extended LGPL requirements. I'm working on fixing that right now.
Sorry, I misunderstood that part.
To be honest, all those license are really complicated and usually an MIT or BSD license is enough to cover you as a developer and give right to other dev to use your work in any kind of settings (with correct credit). The best part of those permissive license, if you feel other are not respecting your work, you can then change the license to a less permissive one.
Anyway, you've done nothing wrong, maybe it would have been better that Zachs sent you an MP instead of posting it here, even if it triggered an interesting conversation on the different licenses used.
Zachs
11th May 2015, 13:12
Well, I do not distribute MPC-HC, nor do I link in any part of MPC-HC. It's not madVR using MPC-HC. It's the other way round. madVR is also not a plugin to MPC-HC, it's simply an official DirectShow renderer which anyone can use who wants to use it. I don't see how that would have any legal effect on madVR. I mean Microsoft also doesn't have to publish their EVR sources as GPL, just because MPC-HC uses EVR, right?
No, but that's the thorny issue with GPL - when user supplies madVR with GPL'ed shader files via GPL'ed MPC-HC, violation happens. I'm just not sure who is violating the license. The same applies for NNEDI3 for MPDN if it remains GPL. Since tritical is unreachable for years now, I guess leaving it as LGPL isn't too bad since it has the same spirit as GPL, and where MPDN's NNEDI3 implementation goes, the whole thing is LGPL'ed.
There are plenty of ways GPL violation could occur - and they do all the time without the user knowing it - e.g. Using Windows Media Player with LAV Filter is a violation.
Like I said, GPL wasn't meant to be used for libraries, let alone binary files that have weights in them or shader files that can be used in other apps. They can be copyrighted, but GPL is the wrong license for it.
I work for a global corporation with access to and have been trained frequently by lawyers specializing in patents, copyright and licensing laws. We avoid GPL code like the plague. Think of LGPL is the 'bug-fixed' version of GPL if you like.
Belphemur
11th May 2015, 13:17
No, but that's the thorny issue with GPL - when user supplies madVR with GPL'ed shader files via GPL'ed MPC-HC, violation happens. I'm just not sure who is violating the license. The same applies for NNEDI3 for MPDN if it remains GPL. Since tritical is unreachable for years now, I guess leaving it as LGPL isn't too bad since it has the same spirit as GPL, and where MPDN's NNEDI3 implementation goes, the whole thing is LGPL'ed.
There are plenty of ways GPL violation could occur - and they do all the time without the user knowing it - e.g. Using Windows Media Player with LAV Filter is a violation.
Like I said, GPL wasn't meant to be used for libraries, let alone binary files that have weights in them or shader files that can be used in other apps. They can be copyrighted, but GPL is the wrong license for it.
I work for a global corporation with access to and have been trained frequently by lawyers specializing in patents, copyright and licensing laws. We avoid GPL code like the plague. Think of LGPL is the 'bug-fixed' version of GPL if you like.
As nevcairiel pointed out, it's not a violation to use LAV with Windows media player, same that madvr is not in violation when used with MPC-HC.
They all implement a system API, the way the module communicate together is through the system, they are not linked together neither provided as a package. It's the system doing the link, in that case, no violation ensue ... because else, you could go sue Microsoft just because you installed a GPL software on it ... it wouldn't make any sense.
Zachs
11th May 2015, 13:18
Commercial products tend to avoid shipping GPL components like LAV Filters directly, but instead recommend simply installing them manually.
That's because company lawyers like what we have in our company would be considering it a 'derivative work' - they believe COM is no different from calling something directly as a DLL. Recommending a manual install is a very dangerous practice too.
madshi
11th May 2015, 13:19
Well, I guess we can close the issue here. The next madVR build should be fully LGPL compliant (if not, let me know, maybe I missed something again). @Zachs, if I may suggest: Send a PM to tritical, but keep things in MPDN as they are. Then he has the chance to complain, and you did all you could. If he doesn't complain, all is well. My 2cents, at least...
nevcairiel
11th May 2015, 13:20
That's because company lawyers like what we have in our company would be considering it a 'derivative work' - they believe COM is no different from calling something directly as a DLL. Recommending a manual install is a very dangerous practice too.
Well if you believe that, then MPDN violates LAVs GPL. Can i haz moneyz noaw? :D
Zachs
11th May 2015, 13:21
As nevcairiel pointed out, it's not a violation to use LAV with Windows media player, same that madvr is not in violation when used with MPC-HC.
They all implement a system API, the way the module communicate together is through the system, they are not linked together neither provided as a package. It's the system doing the link, in that case, no violation ensue ... because else, you could go sue Microsoft just because you installed a GPL software on it ... it wouldn't make any sense.
WMP with LAV filter is considered a violation - in fact that's the very example those lawyers used. This is the very reason nev said commercial software don't include LAV filters.
madVR in MPC-HC is a different matter - that's the opposite of WMP with LAV Filters. What I said before was user using MPC-HC shaders in madVR.
Belphemur
11th May 2015, 13:23
That's because company lawyers like what we have in our company would be considering it a 'derivative work' - they believe COM is no different from calling something directly as a DLL. Recommending a manual install is a very dangerous practice too.
But technically speaking, it's not even linked with it ... neither loading it, since it's done through the system.
That's always what bother me with legal and technical ... two differents reality.
Zachs
11th May 2015, 13:25
Well, I guess we can close the issue here. The next madVR build should be fully LGPL compliant (if not, let me know, maybe I missed something again). @Zachs, if I may suggest: Send a PM to tritical, but keep things in MPDN as they are. Then he has the chance to complain, and you did all you could. If he doesn't complain, all is well. My 2cents, at least...
Oh I did more than half a year ago, I'll try again now that MPDN extensions include NNEDI3.
Well if you believe that, then MPDN violates LAVs GPL. Can i haz moneyz noaw? :D
Sure but you'd have to sue me first :)
I was talking about the licensing terms in the strictest terms where big corporations are concerned. And the whole point was to say that GPL is the wrong license to use - perhaps consider LGPL for LAV? Commercial apps would have no problem including it.
nevcairiel
11th May 2015, 13:27
LAV was originally based on partial GPL code from MPC-HCs old built-in filters, if anything or how much of that remains is impossible to say - but it also makes it impossible to relicense it LGPL without a lot of research.
Zachs
11th May 2015, 13:27
But technically speaking, it's not even linked with it ... neither loading it, since it's done through the system.
That's always what bother me with legal and technical ... two differents reality.
Yeah it's dynamically loading it (yes it's loaded, it has to be - ask Nev). The mechanism that loads it is besides the point - technically it's still loaded. What companies tend to do is ask the user to install LAV filters on their own so it's the users violating the GPL license, not them (but advising the users would land them in legal troubles).
madshi
11th May 2015, 13:28
Oh well, it's sad tritical appears to be "gone". He was working on NNEDI4 at some point (although from what I saw the improvement compared to NNEDI3 was very small), and on a sharpener based on NNEDI technology.
Zachs
11th May 2015, 13:30
Oh well, it's sad tritical appears to be "gone". He was working on NNEDI4 at some point (although from what I saw the improvement compared to NNEDI3 was very small), and on a sharpener based on NNEDI technology.
Yeah. I was monitoring his "last activity" since before I started MPDN...
It still remains at "22nd December 2013 03:55".
Belphemur
11th May 2015, 13:31
LAV was originally based on partial GPL code from MPC-HCs old built-in filters, if anything or how much of that remains is impossible to say - but it also makes it impossible to relicense it LGPL without a lot of research.
For what I understood, if you can contact the authors of the code you used and get a permission to re-license that part under LGPL, you should be okay ...
In that case, you need to put both license specifying until which version the GPL apply and from which version the LGPL apply.
Speaking of license, I saw that ffmpeg also have a tricky licensing system : https://github.com/FFmpeg/FFmpeg/blob/master/LICENSE.md
Zachs
11th May 2015, 13:39
BTW, giving special permissions as permitted by GPL is also a sketchy clause (there's no such provision under LGPL by the way) - if Nev were to say MPDN could include LAV Filters as MIT, then if someone uses the LAV Filters from MPDN, but in the source is in every way similar to the GPL version, would they be in violation? See why companies avoid GPL now? :)
nevcairiel
11th May 2015, 13:41
For what I understood, if you can contact the authors of the code you used and get a permission to re-license that part under LGPL, you should be okay ...
I'm aware, which brings it back to the "research" point, first finding the code which is not mine, and then tracing back the original authorship (or re-writing it). Sounds like days of boring work. Anyone volunteer? :p
I have tried to get rid of some of the old code since it was mostly hacks which were better suited properly re-implemented inside ffmpeg, but some are still present.
Speaking of license, I saw that ffmpeg also have a tricky licensing system : https://github.com/FFmpeg/FFmpeg/blob/master/LICENSE.md
While FFmpeg includes code under varying licenses, you basically specify which license you want at build-time, and it'll only build code that is available under that license, resulting in properly licensed binaries.
LAV already uses a LGPL build of FFmpeg, fwiw.
Zachs
11th May 2015, 13:41
Ah now I remember, I never succeeded in sending tritical any PMs because it was full the first time I tried, and it is still full now!
madshi
11th May 2015, 13:54
Argh, that's bad. Is there a known email address? I don't remember...
Belphemur
11th May 2015, 13:58
Argh, that's bad. Is there a known email address? I don't remember...
Yup there is on his website (footer of it) : http://bengal.missouri.edu/~kes25c
I also found he published couple of conference paper in 2012 all linked (unsurprisingly) to image analysis :D
Zachs
11th May 2015, 13:58
Yeah, just sent him an email. Belphemur found his email address. Let's see if he replies.
madshi
11th May 2015, 19:05
FYI, the latest madVR build should now fix the LGPL issues. See "legal stuff\Shiandow\readme.txt" for details. If there's still something to do, please let me know.
Anima123
11th May 2015, 21:18
.NET Framework Repair Tool (https://www.microsoft.com/en-us/download/details.aspx?id=30135)
Which version should I re-install to be used with MPDN?
Zachs
11th May 2015, 22:10
Version 4.0.
Belphemur
12th May 2015, 08:10
Good news, in the last PlayerExtension you have an UpdateChecker (activated by default). It'll notify you when opening the player if there is a new version and redirect you on the website to download it.
You can easily disable it in the configuration of the player extension and also choose to forget this particular update.
ryrynz
12th May 2015, 08:53
Is that just with new versions of just the player or does it include extensions as well?
Belphemur
12th May 2015, 09:24
Is that just with new versions of just the player or does it include extensions as well?
Only the player, but everyday the extensions' zip get pulled from Github and is available along the latest version as you can see here : http://mpdn.zachsaw.com/Latest/
Zachs
13th May 2015, 00:17
Good news!
tritical has given MPDN the rights to use NNEDI3 with an LGPL license, so MPDN extensions can remain exactly the way it is.
Shiandow
13th May 2015, 00:19
The debanding algorithm has been improved again, with the new version you can achieve better debanding with lower values of the "threshold" parameter. It's recommended to revert to defaults, or lower the "threshold" parameter manually.
Also fixed this (http://forum.doom9.org/showthread.php?p=1721690#post1721690)issue.
mrcorbo
13th May 2015, 03:45
.NET Framework Repair Tool (https://www.microsoft.com/en-us/download/details.aspx?id=30135)
I finally got to try this (thanks for posting the direct link) and this may have fixed both my crash issues. Aside from the crash on right-click menu exit option selection during fullscreen playback I was also having an eventual crash during playback when crossfire was enabled (I have twin 4GB 270x's). I also just had some Windows Updates install, though, so I can't be sure which fixed the issues. I'll report back if the issues pop back up during more extended testing (pretty sure the "exit" crash at least is fixed), but for now things are looking good.
ryrynz
13th May 2015, 04:14
I finally got to try this (thanks for posting the direct link) and this may have fixed both my crash issues. things are looking good.
Awesome sauce.
Good news!
tritical has given MPDN the rights to use NNEDI3 with an LGPL license, so MPDN extensions can remain exactly the way it is.
Was he actually required to give the rights though? I thought it would've been better for him to clear up his licensing arrangements.
Zachs
13th May 2015, 07:08
Hi everyone,
I've added a new render script called "Scripted Render Chain" which allows you to write Avisynth-like scripts. It's based on JavaScript, so you can use any of JavaScript's built-in features (e.g. string processing).
The default script goes like this (it's does exactly everything Custom.MyRenderScript.cs does and it's a good starting point to write your own script).
// Example render script
// Scale chroma first (this bypasses MPDN's chroma scaler)
BicubicChroma( Preset = Presets.MitchellNetravali )
// Apply some filtering pixel shaders
ImageProcessor( ShaderFileNames = ["SweetFX\\Bloom.hlsl", "SweetFX\\LiftGammaGain.hlsl"] )
// Use NEDI once only.
// Note: To use NEDI as many times as required to get the image past target size,
// change the following *if* to *while*
if (input.NeedsUpscaling)
{
Nedi( AlwaysDoubleImage = true )
}
if (input.NeedsDownscaling)
{
// Use linear light for downscaling
ImageProcessor( ShaderFileNames = ["ConvertToLinearLight.hlsl"] )
Resizer( ResizerOption = ResizerOption.TargetSize100Percent )
ImageProcessor( ShaderFileNames = ["ConvertToGammaLight.hlsl"] )
}
if (input.SourceSize.Width < 1920)
{
// Sharpen only if video isn't full HD
// Or if you have FineSharp installed, replace the following line with it
ImageProcessor( ShaderFileNames = ["SweetFX\\LumaSharpen.hlsl"] )
}
This script is currently saved in %localappdata%\MediaPlayerDotNet\DefaultScript.rs (there's no need to know this - you can simply change the script in the config screen).
As you can see, it uses a very simple syntax to add filters to the chain. More importantly though, you can change the script and have MPDN use it on the fly without having to restart MPDN!
Note that if you edit the file externally, you'll need to manually resize the MPDN window for it to take effect. If you an error with your script, MPDN will display the error on the screen in place of the video.
All functions that the 'rs' script can access are available in the Clip and Host classes (see Mpdn.ScriptedRenderChain.ScriptHelpers.cs (https://github.com/zachsaw/MPDN_Extensions/blob/master/Extensions/RenderScripts/Mpdn.ScriptedRenderChain.ScriptHelpers.cs)). 'Clip' is available via the 'input' object while 'Host' is 'host'. There's also a "Debug.Output" function that allows you to dump debug messages to the DbgView app.
For example,
input.FileName // returns the full path and file name of the video file
input.FrameRateHz // returns the fps of your video
input.SourceSize.Width // returns video source width
host.ExePath // returns the folder name of which MPDN's executable file resides
The render scripts you can use in the 'rs' script currently are,
Lut3DColorCorrection
ImageProcessor
Preset
Resizer
BicubicChroma
Deband
Nedi
NNedi3
OclNNedi3 // OpenCL version of NNEDI3
SuperChromaRes
SuperRes
Have fun! :)
Zachs
13th May 2015, 07:10
Was he actually required to give the rights though? I thought it would've been better for him to clear up his licensing arrangements.
Yes, because it was GPL. He's given MPDN the approval to relicense it as LGPL.
pirlouy
13th May 2015, 15:40
I took time to do tests I wanted to do a long time.
For now, I use MPC-HC + LAV + madVR, a well known configuration which works. But I wanted to compare with MPDN.
So for now, I wanted to test how both perform in windowed D3D9 mode. The window is maximized, and process hacker allows me to see CPU, and GPU-Z sensors allows me to follow GPU states.
And I can see MPDN uses a lot more CPU+GPU.
I tried to use the same config as madVR, then bilinear everywhere, but it's the same, MPDN uses more CPU and GPU. I tried to disable fluid motion, dithering, I don't use any render script. I've tried with D3D10.1 et D3D11 but no changes.
Have you any idea on what can causes this ? Can it be linked to .Net ? For now, it makes no sense comparing glitches/dropped frames if CPU/GPU is way more used.
Zachs
13th May 2015, 22:09
Not that I've seen. The last time I tested it, it was faster than madvr on both CPU and GPU.
EDIT: You're right. It would seem madVR has indeed gained some performance with the recent versions - it has a lower base GPU load over all even with HW bilinear.
EDIT2: It turns out it's not entirely true - it depends on what material you're testing them with... were you testing it with 1080p materials btw?
EDIT3: LOL. Testing it with another different machine, madVR's GPU load is higher on most materials except 1080p which it is just 1% lower than MPDN. This is why I hate comparing performance between different renderers - they are so reliant on the drivers / system you have. CPU usage wise, both are within a difference of +/-1% with the different materials I've tested.
EDIT4: With more testing, I found with older GPUs, you can find sources with certain resolutions that would cause higher GPU usage with MPDN. I'm not sure what the cause of that is but it's not something I'm keen to put my time on seeing as those GPUs are really old (> 5 years old) and typically only run legacy drivers.
foxyshadis
14th May 2015, 09:09
Coming back to MPDN after a while, I have some questions which have probably been answered at some point, but... 100+ pages. Maybe the answers would be a good fit for the wiki.
Is there a comprehensive list of everything in PlayerControl? That's the only way to set custom keybindings right now, AFAIK.
Is there a way to display statistics on the screen? A lot of people seem to be doing this, but I can't find how.
When should I check or leave unchecked the boxes on the Presentation config panel? (New windowed mode & DWM VSync.) Are they better, worse, legacy compatibility?
Do you use a frame-adaptive ordered dither, like madvr?
pirlouy
14th May 2015, 11:00
@Zachs: If I look at CPU only (even if GPU is higher as I said). The processor I use is a Intel Core i3-2100.
With MPC-HC / LAV / madVR, I am at 30-35% with/without stats displayed
With MPDN, I am at 50-55% with stats displayed, 45-50% without stats displayed.
I've tried with all MPDN version (64, 32, anyCPU). I've also used the repair tool mentioned earlier, just in case (but he found nothing).
PS: I don't use DXVA at all.
Zachs
14th May 2015, 11:54
Coming back to MPDN after a while, I have some questions which have probably been answered at some point, but... 100+ pages. Maybe the answers would be a good fit for the wiki.
Is there a comprehensive list of everything in PlayerControl? That's the only way to set custom keybindings right now, AFAIK.
Is there a way to display statistics on the screen? A lot of people seem to be doing this, but I can't find how.
When should I check or leave unchecked the boxes on the Presentation config panel? (New windowed mode & DWM VSync.) Are they better, worse, legacy compatibility?
Do you use a frame-adaptive ordered dither, like madvr?
MPDN lacks documentation at the moment but there are quite a few devs who frequent the forum who started not knowing how to program in C# but managed to cook up a new extension in a couple of days, so I'm sure they're happy to help if you need something. That said, the best way to get that list would be via the IDE's intellisense.
Statistics on the screen? Ctrl+J should bring it up or you can do it via the menu: show player statistics.
If you don't find any problems with high presentation durations, you should just leave those in their default states. They're mainly for those systems (e.g. Optimus) that need specific settings.
MPDN's ordered dithering does not randomize across frames, it uses a different algorithm to madVR's ordered dithering. The very definition of ordered means its not random, so there's no such option for ordered dithering.
@Zachs: If I look at CPU only (even if GPU is higher as I said). The processor I use is a Intel Core i3-2100.
With MPC-HC / LAV / madVR, I am at 30-35% with/without stats displayed
With MPDN, I am at 50-55% with stats displayed, 45-50% without stats displayed.
I've tried with all MPDN version (64, 32, anyCPU). I've also used the repair tool mentioned earlier, just in case (but he found nothing).
PS: I don't use DXVA at all.
I've tried it on 5 different machines from Core2Duo through to 4th gen i7 and they all consistently get slightly lower CPU usage vs MPC-HC/madVR both 32/64 bit editions. You're not by any chance using ffdshow in your filter chain are you? It was established that it's a CPU hogger when used with .NET host a long time ago (my rough guess is it's silently trapping its own exceptions). It's a dead project, so there's nothing we could do.
pirlouy
14th May 2015, 12:06
I don't use ffdshow or any post-processing filter. You were on Windows 8.1 ?
I really don't know what could cause this then. :/
Zachs
14th May 2015, 12:55
Both windows 7 and 8.1.
Belphemur
14th May 2015, 14:20
Coming back to MPDN after a while, I have some questions which have probably been answered at some point, but... 100+ pages. Maybe the answers would be a good fit for the wiki.
Is there a comprehensive list of everything in PlayerControl? That's the only way to set custom keybindings right now, AFAIK.
Is there a way to display statistics on the screen? A lot of people seem to be doing this, but I can't find how.
When should I check or leave unchecked the boxes on the Presentation config panel? (New windowed mode & DWM VSync.) Are they better, worse, legacy compatibility?
Do you use a frame-adaptive ordered dither, like madvr?
As Zachs said, with IntelliSense on Visual Studio it's piece of cake to get all the different method the PlayerControl gives you. But I took the time to extract them :
public static class PlayerControl
{
public static void SetPlayerControl(IPlayerControl playerControl);
public static bool OnKeyDown(ref KeyEventArgs args);
public static bool OnMouseWheel(ref MouseEventArgs args);
public static bool OnMouseMove(ref MouseEventArgs args);
public static bool OnMouseClick(ref MouseEventArgs args);
public static bool OnMouseDoubleClick(ref MouseEventArgs args);
public static bool OnDragDrop(ref DragEventArgs args);
public static bool OnDragEnter(ref DragEventArgs args);
public static void OnPlaybackCompleted();
public static void OnFormClosed();
public static void OnPlayerStateChanged(PlayerState playerState, PlayerState oldState);
public static void OnVolumeChanged();
public static void OnAudioTrackChanged();
public static void OnSubtitleTrackChanged();
public static void OnFrameDecoded(FrameEventArgs e);
public static void OnFrameRendered(FrameEventArgs e);
public static void OnFramePresented(FrameEventArgs e);
public static void OnPaintText();
public static void OnExitedFullScreenMode();
public static void OnExitingFullScreenMode();
public static bool OnCommandLineFileOpen(CommandLineFileOpenEventArgs e);
public static void OnEnteredFullScreenMode();
public static void OnEnteringFullScreenMode();
public static void OnMediaLoading(MediaLoadingEventArgs e);
public static void OnPlayerLoaded();
public static void OpenMedia(string filename, bool play = true, bool showOsd = true);
public static void PlayMedia(bool showOsd = true);
public static void PauseMedia(bool showOsd = true);
public static void SeekMedia(long usec);
public static void StepMedia();
public static void StopMedia();
public static void CloseMedia();
public static void SelectSubtitleTrack(MediaTrack track, bool showOsd = true);
public static void SelectAudioTrack(MediaTrack track, bool showOsd = true);
public static void ShowStats(bool show);
public static void ResetStats();
public static void GoFullScreen();
public static void GoWindowed();
public static void HandleException(Exception exception);
public static void ShowOsdText(string text, int durationMs = 1000);
public static void HideOsdText();
public static IText CreateText(string font, int size, TextFontStyle style);
public static void ShowOptionsDialog();
public static void FitAspectRatio();
public static void FitPercentage(int percent);
public static void RefreshSettings();
public static void SetRenderScript(Guid renderScriptGuid);
public static Form Form { get; }
public static Control VideoPanel { get; }
public static Icon ApplicationIcon { get; }
public static PlayerState PlayerState { get; }
public static bool InFullScreenMode { get; }
public static long MediaPosition { get; }
public static long MediaDuration { get; }
public static IList<MediaTrack> SubtitleTracks { get; }
public static IList<MediaTrack> AudioTracks { get; }
public static IList<Chapter> Chapters { get; }
public static MediaTrack ActiveSubtitleTrack { get; }
public static MediaTrack ActiveAudioTrack { get; }
public static int Volume { get; set; }
public static bool Mute { get; set; }
public static string MediaFilePath { get; }
public static VideoInfo VideoInfo { get; }
public static AMMediaType VideoMediaType { get; }
public static string ConfigRootPath { get; }
public static int FullScreenSeekBarHeight { get; }
public static IRenderScript ActiveRenderScript { get; }
public static Guid ActiveRenderScriptGuid { get; }
public static IList<Assembly> ExtensionAssemblies { get; }
public static IList<IRenderScriptUi> RenderScripts { get; }
public static IList<IPlayerExtension> PlayerExtensions { get; }
public static Configuration PlayerSettings { get; }
public static event EventHandler<PlayerStateEventArgs> PlayerStateChanged;
public static event EventHandler<MediaLoadingEventArgs> MediaLoading;
public static event EventHandler PlayerLoaded;
public static event EventHandler PlaybackCompleted;
public static event EventHandler FormClosed;
public static event EventHandler EnteringFullScreenMode;
public static event EventHandler EnteredFullScreenMode;
public static event EventHandler ExitingFullScreenMode;
public static event EventHandler ExitedFullScreenMode;
public static event EventHandler PaintOverlay;
public static event EventHandler<PlayerControlEventArgs<KeyEventArgs>> KeyDown;
public static event EventHandler<PlayerControlEventArgs<MouseEventArgs>> MouseWheel;
public static event EventHandler<PlayerControlEventArgs<MouseEventArgs>> MouseMove;
public static event EventHandler<PlayerControlEventArgs<MouseEventArgs>> MouseClick;
public static event EventHandler<PlayerControlEventArgs<MouseEventArgs>> MouseDoubleClick;
public static event EventHandler<PlayerControlEventArgs<DragEventArgs>> DragDrop;
public static event EventHandler<PlayerControlEventArgs<DragEventArgs>> DragEnter;
public static event EventHandler<CommandLineFileOpenEventArgs> CommandLineFileOpen;
public static event EventHandler<FrameEventArgs> FrameDecoded;
public static event EventHandler<FrameEventArgs> FrameRendered;
public static event EventHandler<FrameEventArgs> FramePresented;
public static event EventHandler VolumeChanged;
public static event EventHandler SubtitleTrackChanged;
public static event EventHandler AudioTrackChanged;
}
I added a wiki page about it : https://github.com/zachsaw/MPDN_Extensions/wiki/PlayerControl
foxyshadis
14th May 2015, 23:15
Statistics on the screen? Ctrl+J should bring it up or you can do it via the menu: show player statistics.
OK, Ctrl-J works. I don't have that option anywhere in the menu though, after a clean install (with all basic extensions).
Last question. I made a renderscript of chromascaler->deband->resize (100% of target size)->image processor (shader noise), but the shader effect is still being applied to the original video size, not the full screen size. Am I misunderstanding the target size?
As Zachs said, with IntelliSense on Visual Studio it's piece of cake to get all the different method the PlayerControl gives you. But I took the time to extract them :
I added a wiki page about it : https://github.com/zachsaw/MPDN_Extensions/wiki/PlayerControl
Thanks! That helps a lot.
Zachs
15th May 2015, 02:26
OK, Ctrl-J works. I don't have that option anywhere in the menu though, after a clean install (with all basic extensions).
Last question. I made a renderscript of chromascaler->deband->resize (100% of target size)->image processor (shader noise), but the shader effect is still being applied to the original video size, not the full screen size. Am I misunderstanding the target size?
"Show Player Statistics" option is in General -> Options page.
Yeah it does look like Resize (100% of target size) isn't working any more.
@Shiandow, do you know what could've caused it?
EDIT: Yeah Shiandow's aware of it and he'll fix it tomorrow. It's bug caused by the recently changed Filter.cs.
public static void SetSize(this IFilter filter, TextureSize size)
{
var resizeable = (filter as IResizeableFilter) ?? new ResizeFilter(filter); // Bug: new ResizeFilter(filter) never gets assigned to anything
resizeable.SetSize(size);
}
Shiandow
15th May 2015, 14:54
Hi all,
This announcement is a bit late, but the renderscripts have been updated. Including a revised debanding algorithm, based on feedback on the MadVR thread. The parameters have now been replaced by two others, called "power" and "margin" respectively.
The first one "power" is the most useful and controls how aggressively the debanding script removes banding, when set to 0 it only removes banding if it's 100% sure that it's on a gradient, if you set it to something like 10% it will remove banding when it's at least 90% sure that it is on a gradient etc. (at the moment setting it to 1 doesn't remove the maximal amount of banding, but I might change that).
The second one "margin" allows the algorithm to change values beyond what is theoretically necessary. If set to 0 you should recover the original image if you convert the result back to 8 bits (this doesn't work too well because of a lack of precision, but that's a different problem). If set higher it will start removing information in order to remove more banding. This should only be necessary when the source has been "broken" by incorrect processing. One example, which I suspect to occur occasionally, is when a TV level source has been converted to PC levels using only 8 bit, this can cause excessive banding which can't be removed with a "conservative" algorithm.
Anime Viewer
15th May 2015, 15:36
Hi all,
This announcement is a bit late, but the renderscripts have been updated. Including a revised debanding algorithm, based on feedback on the MadVR thread. The parameters have now been replaced by two others, called "power" and "margin" respectively.
Nice job. With the default settings (power=.50,margin=0) I believe I see a noticeable improvement over the previous deband effects in MPDN.
Shiandow
15th May 2015, 20:44
Last question. I made a renderscript of chromascaler->deband->resize (100% of target size)->image processor (shader noise), but the shader effect is still being applied to the original video size, not the full screen size. Am I misunderstanding the target size?
This issue is now fixed.
Anime Viewer
16th May 2015, 01:16
When running with CTRL+J displaying the OSD I see a DWM presentation glitches category even though I have "Let DWM handle vertical sync in windowed mode*" unchecked. Is DWM used for some other part of video rendering in MPDN, is the DWM line present regardless of if it is active or not, or is there some other DWM render setting I'm not noticing?
Zachs
16th May 2015, 03:45
When running with CTRL+J displaying the OSD I see a DWM presentation glitches category even though I have "Let DWM handle vertical sync in windowed mode*" unchecked. Is DWM used for some other part of video rendering in MPDN, is the DWM line present regardless of if it is active or not, or is there some other DWM render setting I'm not noticing?
I guess the wording of the option is a bit confusing. When you have it unchecked, DWM still handles VSync, except Direct3D is also doing it. When it's checked, DWM is the only one doing VSync (and when DWM is disabled, you'll get tearing). Not sure how else I could word it that will make it less confusing though - any suggestions?
Oh yes and DWM is active regardless - esp on Win8 and above (no way to disable DWM).
Anime Viewer
16th May 2015, 05:57
I guess the wording of the option is a bit confusing. When you have it unchecked, DWM still handles VSync, except Direct3D is also doing it. When it's checked, DWM is the only one doing VSync (and when DWM is disabled, you'll get tearing). Not sure how else I could word it that will make it less confusing though - any suggestions?
Oh yes and DWM is active regardless - esp on Win8 and above (no way to disable DWM).
I had based the thought that DWM was not a good thing from your previous post that advised someone to only check it (to enable it) as a last resort. Given your explanation now of what it does I'm no longer concerned about disabling it (not that I could if I wanted to in Windows 8), but I'll continue running with it unchecked since it seems that is what you'd advise.
As far as the check box goes perhaps wording it: DWM exclusive VSync (or VSync using only DWM) would be less of a confusing term. For the OST perhaps instead of DWM presentation glitches it could read VSync presentation glitches.
Oh yes and DWM is active regardless - esp on Win8 and above (no way to disable DWM).
there are way to still disable DWM but...
Belphemur
16th May 2015, 13:37
there are way to still disable DWM but...
Well there is this : http://www.overclock.net/t/1441921/windows-8-1-no-dwm-aka-aero-aka-desktop-composition
But as said in the beginning :
You understand that the Start screen will break, and other parts of
windows will be inaccessible. You lose the login screen as a result, so
you need to either remove your password or set up windows to
automatically login (google it). If you need to lock your computer, a good
replacement is ClearLock. Set it up, and launch to lock. Add a shortcut to it in your startup folder to lock on startup.
Make sure windows is set to login to the desktop (google it, classicshell also
has an option for this)
C. Make sure you use something like classicshell to have a way to use
Windows. Wireless connections will also be unchangeable, use something like PE Network Manager as a replacement,
it's also a lot better anyway.
Braum
16th May 2015, 14:06
Hi !
I've just tried your player and I'm very pleased with it. I like the fact that it has a lot of advance user features.
I'm trying to find the right settings for my cpu and gpu and I have some questions.
Image quality/performance trade off : on which parameters it affects ?
From all the algorithm listed in the image below (1), which one is the most powerfull ? I know Lanczos is a good comprise between quality and the introduction of aliasing/artifacts (2).
Is there a shortcut to capture current frame ?
(1)
http://reho.st/self/291ced17d16901b6fdf2d2a27dcb9dbfe8c1fdec.png
(2)
The Lanczos filter has been compared with other interpolation methods for discrete signals, particularly other windowed versions of the sinc filter. Turkowski and Gabriel claimed that the Lanczos filter (with a = 2) the "best compromise in terms of reduction of aliasing, sharpness, and minimal ringing", compared with truncated sinc and the Bartlett, cosine-, and Hann-windowed sinc, for decimation and interpolation of 2-dimensional image data.[1] According to Jim Blinn, the Lanczos kernel (with a = 3) "keeps low frequencies and rejects high frequencies better than any (achievable) filter we've seen so far."
From what I've tested for the moment I love MPDN :thanks:
My setup : i5 3570K @ 4.5ghz | AMD 7870XT
Anime Viewer
16th May 2015, 14:45
Hi !
Image quality/performance trade off : on which parameters it affects ?
How can I activate multiple Render Script and how do I know it's working ?
From all the algorithm listed in the image below (1), which one is the most powerfull ? I know Lanczos is a good comprise between quality and the introduction of aliasing/artifacts (2).
Zachs will probably be able to answer your first question.
As for multiple render scripts you'd click on Render Script under Video Render, and then from within that you'd pick Script Chain. Within Script Chain you'd then pick all of the scripts you'd want active. For the most part you should keep them in the order of what they are listed from top to bottom. For example if you planned to use SuperChromaRes, Deband, and SuperRes you'd want to keep SuperChromaRes on the top of your chain, deband in the middle, and SuperRes on the bottom. If you have CTRL+J active to show the OSD before changing you should see a difference in Render and/or Present times after the change which would signify that they are working. You may also simply notice a change of visual quality in the video as soon as you click the apply button.
What works best for you for scaling may depend on what type of content you are watching. For line drawn (aka: animated content) Mitchell (aka: Bicubic 66) is often believed to be the best upscaler (see link) while for real life content (people) Jinc is often preferred by many for upscaling. For downscaling some people like Jinc or Lagrange, and some like Catrom (aka: Bicubic 100).
http://www.imagemagick.org/Usage/filter/#mitchell
If you're going to be using SuperRes and/or NEDI3/NNEDI3 you can throw many of the upscale/downscale choices out the window because they will override those choices. With the SuperRes options in your scripts you can throw pretty much anything (except perhaps Nearest Neighbor) as a scaler and not notice a difference in visual looks during video playback.
http://www.imagemagick.org/Usage/img_diagrams/cubic_survey.gif
Braum
16th May 2015, 15:11
Thank you a lot for theses explanations :thanks:
It makes the whole thing much more clear ! :D
Zachs
17th May 2015, 06:18
The image quality / performance tradeoff option should be left in its default setting which is prefer image quality. If you're running on a system with very tight power budget such as a tablet, you'd probably want to use max performance with everything set to bilinear. Max quality is kinda equivalent to x264's placebo settings while prefer performance shaves a bit of time off rendering duration only on some systems but loses quality.
So, I'd leave it in its default state.
Braum
17th May 2015, 10:10
Duly noted ! Thank you !
Magik Mark
18th May 2015, 21:49
Hey Zach!
Excellent work here! I just need some assistance on the ff:
I'm considering this as the replacement for my MPC BE with Madvr because of its faster rendering running as an external player for KODI.
MPC BE in full screen has an auto hide icons on the top right. You can easily close, minimize among others the window in one click. Can this be implemented in MPDN? My Programming skills really sucks
Thanks
Crashes are back (they never went away to begin with, using the latest version now).
This time, instead of just these 2 errors https://i.imgur.com/Odv9Wl8.png , I also got:
Fault bucket , type 0
Event Name: AppHangB1
Response: Not available
Cab Id: 0
Problem signature:
P1: mmc.exe
P2: 6.3.9600.17415
P3: 54504e26
P4: 0000
P5: 67246336
P6:
P7:
P8:
P9:
P10:
The program mmc.exe version 6.3.9600.17415 stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Action Center control panel.
Process ID: 1c74
Start Time: 01d091b13747935e
Termination Time: 4294967295
Application Path: C:\Windows\system32\mmc.exe
Report Id: 62513a9c-fda6-11e4-826f-60a44ccfa7c5
Faulting package full name:
Faulting package-relative application ID:
The program MediaPlayerDotNet.exe version 2.25.16.3084 stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Action Center control panel.
Process ID: 1d70
Start Time: 01d091b130780dff
Termination Time: 4294967295
Application Path: C:\Program Files\Media Player Dot Net\MediaPlayerDotNet.exe
Report Id: 68cde63f-fda6-11e4-826f-60a44ccfa7c5
Faulting package full name:
Faulting package-relative application ID:
Garteal
18th May 2015, 22:55
Hey Zach!
MPC BE in full screen has an auto hide icons on the top right. You can easily close, minimize among others the window in one click. Can this be implemented in MPDN?
Yep, quite easily. Could be added to the FullscreenTextPainer PlayerExtension. Might do it if I get some time tomorrow.
@BRM have you tried repairing your .NET install? Get it from the link below and give that a try.
.NET Framework Repair Tool (https://www.microsoft.com/en-us/download/details.aspx?id=30135)
Yep, quite easily. Could be added to the FullscreenTextPainer PlayerExtension. Might do it if I get some time tomorrow.
@BRM have you tried repairing your .NET install? Get it from the link below and give that a try.
It keeps crashing, and generally, the mmc.exe process is never in the event viewer log. However, I have just done what you said. I'll report back soon.
Zachs
19th May 2015, 00:21
Yep, quite easily. Could be added to the FullscreenTextPainer PlayerExtension. Might do it if I get some time tomorrow.
@BRM have you tried repairing your .NET install? Get it from the link below and give that a try.
Hey Garteal, any chance you could merge your playlist changes to the main repo?
Magik Mark
19th May 2015, 00:27
While playing video and opening reclock preference:
I'm getting "No video streams detected". Why is this? Does it have something to do with fluid motion? I think altering the video clock would help in achieving smoother video
Zachs
19th May 2015, 00:31
Reclock doesn't quite work with MPDN. I've put in a request to get SlySoft to fix their reclock filter but have not heard back at all since more than half a year ago... It also doesn't have a 64-bit version, so most people wouldn't recommend using it.
EDIT: Well it works with MPDN but as you've found out it doesn't know how to get the video stream because MPDN uses a separate graph for video and audio. But more importantly even if it does, Reclock's missing the ability to get the actual refresh rate from the renderer.
nevcairiel
19th May 2015, 00:33
Reclock doesn't quite work with MPDN. I've put in a request to get SlySoft to fix their reclock filter but have not heard back at all since more than half a year ago... It also doesn't have a 64-bit version, so most people wouldn't recommend using it.
ReClock has been dead for years now, don't hold your breath.
Anime Viewer
19th May 2015, 00:36
Hey Garteal, any chance you could merge your playlist changes to the main repo?
That would be good. That would also fix the problem where second files in the playlist would be fixed (talked about here: http://forum.doom9.org/showthread.php?p=1710705#post1710705) which has been bugged in the main extension patch for a while now.
The image quality / performance tradeoff option should be left in its default setting which is prefer image quality. If you're running on a system with very tight power budget such as a tablet, you'd probably want to use max performance with everything set to bilinear. Max quality is kinda equivalent to x264's placebo settings while prefer performance shaves a bit of time off rendering duration only on some systems but loses quality.
So, I'd leave it in its default state.
Good to know. I'd also been wondering about the Max Quality option and if it would provide any significant benefit over the default image quality option. Now that I know I will not bother with the max setting.
Zachs
19th May 2015, 00:36
ReClock has been dead for years now, don't hold your breath.
Yup I know.
It's a shame they don't want to release the source.
Magik Mark
19th May 2015, 00:36
Reclock doesn't quite work with MPDN. I've put in a request to get SlySoft to fix their reclock filter but have not heard back at all since more than half a year ago... It also doesn't have a 64-bit version, so most people wouldn't recommend using it.
What do you think is a good alternative? SVP? Do you have a step by step guide in running this along with MPDN?
Thanks
Zachs
19th May 2015, 00:39
If you can't get your monitor to run at your video rate, I'd say run it at its max frequency (even 60Hz is good enough) and enable Fluid Motion.
That will give you very similar fluidity to what Reclock does.
tobindac
19th May 2015, 02:04
This player gives "failed to render file" out of the box. That gives a very bad impression to new users. Make it standalone in some way if you want it to ever take off.
Zachs
19th May 2015, 02:08
This player gives "failed to render file" out of the box. That gives a very bad impression to new users. Make it standalone in some way if you want it to ever take off.
You mean when you don't have the pre-requisites installed?
Magik Mark
19th May 2015, 05:41
I'm having problem with bit streaming. No audio for movies. Ok if TV.
No Problem if bitstreaming is off for both formats.
Does it have something to do if its DD or DTS?
No problem at all under MPC BE. Both Bitstreaming & pcm ok
burfadel
19th May 2015, 06:10
I just tried the latest 3089 test build (MediaPlayerDotNet_x64_2_26_0_3089.zip), it doesn't work! To be more precise, it does work, but the extensions don't. If I just use the base MPDN 3089, it loads and works fine.
With the latest extension pack, I get the following:
TITLE: Error
------------------------------
An unexpected error 'Mpdn.CriticalException' has occurred.
------------------------------
ADDITIONAL INFORMATION:
One or more extensions failed to load
------------------------------
n:\MPDN\Extensions\Framework\Filter.Sources.cs(195,66): error CS0246: The type or namespace name 'ITexture3D' could not be found (are you missing a using directive or an assembly reference?)
n:\MPDN\Extensions\Framework\Filter.Sources.cs(197,26): error CS0246: The type or namespace name 'ITexture3D' could not be found (are you missing a using directive or an assembly reference?)
n:\MPDN\Extensions\Framework\Filter.Sources.cs(200,38): error CS0246: The type or namespace name 'ITexture3D' could not be found (are you missing a using directive or an assembly reference?)
n:\MPDN\Extensions\Framework\Filter.Sources.cs(206,25): error CS0246: The type or namespace name 'ITexture3D' could not be found (are you missing a using directive or an assembly reference?)
n:\MPDN\Extensions\RenderScripts\Mpdn.Lut3D.cs(71,21): error CS0246: The type or namespace name 'ITexture3D' could not be found (are you missing a using directive or an assembly reference?)
(CSScriptLibrary)
------------------------------
BUTTONS:
&Abort
------------------------------
This is with a completely clean folder. I even extracted them to a different location, as seen in the text above, and it still showed that message. The latest extensions work fine in the latest release 3085 build.
Damn, and I wanted to try out that new 'Improve Chroma Reconstruction' render option :).
Magik Mark
19th May 2015, 06:20
I'm having problem with bit streaming. No audio for movies. Ok if TV.
No Problem if bitstreaming is off for both formats.
Does it have something to do if its DD or DTS?
No problem at all under MPC BE. Both Bitstreaming & pcm ok
I think I found the culprit. When playing bitstreaming, make sure audio is set to "Default Direct Sound Device"
Is wasapi available?
Zachs
19th May 2015, 06:22
I just tried the latest 3089 test build (MediaPlayerDotNet_x64_2_26_0_3089.zip), it doesn't work! To be more precise, it does work, but the extensions don't. If I just use the base MPDN 3089, it loads and works fine.
With the latest extension pack, I get the following:
This is with a completely clean folder. I even extracted them to a different location, as seen in the text above, and it still showed that message.
Build 3089 is a test build for Shiandow. Of course it doesn't work with the extensions on github!
EDIT: v2.26 is now officially released. GitHub scripts have also been updated. Please note that the files in the test build folder is meant for devs only and *usually* won't work with the GitHub scripts.
Zachs
19th May 2015, 06:23
I think I found the culprit. When playing bitstreaming, make sure audio is set to "Default Direct Sound Device"
Is wasapi available?
You can use mpc-hc's wasapi audio renderer. It'll work just fine with MPDN.
Zachs
19th May 2015, 07:59
Crashes are back (they never went away to begin with, using the latest version now).
This time, instead of just these 2 errors https://i.imgur.com/Odv9Wl8.png , I also got:
Hmm, mmc.exe is the Microsoft Management Console executable. If that crashes too, there's something that's rather seriously wrong with your machine...
Zachs
19th May 2015, 08:04
Hey guys, assuming I have a container with one audio and 2 video streams, how do I switch the video stream?
v2.26 now supports video track switching.
burfadel
19th May 2015, 09:44
Build 3089 is a test build for Shiandow. Of course it doesn't work with the extensions on github!
EDIT: v2.26 is now officially released. GitHub scripts have also been updated. Please note that the files in the test build folder is meant for devs only and *usually* won't work with the GitHub scripts.
Ah, that makes sense then! :)
Magik Mark
19th May 2015, 10:46
You can use mpc-hc's wasapi audio renderer. It'll work just fine with MPDN.
How do I get this? Do I have to download mph hc just to get this?
ryrynz
19th May 2015, 11:14
How do I get this? Do I have to download mph hc just to get this?
It's MPC-BE's wasapi renderer you want (MPC audio renderer)
Download teh standalone filter package you want (x86 or x64) here (https://sourceforge.net/projects/mpcbe/files/MPC-BE/Nightly%20Builds%20%28from%20svn%20trunk%29/MPC-BE%20v1.4.5%20%28build%20364%29%20beta/)
Register it with regsvr32 and you'll be able to use it within MPDN.
ryrynz
19th May 2015, 11:18
Hey Garteal, any chance you could merge your playlist changes to the main repo?
We haven't quite finished up there yet.. his development cycles come in dribs and drabs :)
I'd say we'd be done the next time he gets in some dev time.
Can you give us some info the the chroma reconstruction option? It reconstructs some interesting details on my HD4000 with a blu-ray rip :)
Other sources have no issues, seems like a fairly minor tweak, the differences in most cases wouldn't be noticeable but I'll take anything that's
subjectively "improving" quality. I'd be interested in knowing what's actually going on here.
Zachs
19th May 2015, 13:12
That option is not enabled by default because some sources aren't compatible with it (chroma has "invalid" values). With compatible sources, it should give you more details on your chroma. It's quite hard to see though as the human eyes aren't particularly sensitive to chroma. It doesn't cost too much GPU to enable but on weaker GPUs you'll see a difference of a couple of percent points.
Magik Mark
19th May 2015, 13:22
It's MPC-BE's wasapi renderer you want (MPC audio renderer)
Download teh standalone filter package you want (x86 or x64) here (https://sourceforge.net/projects/mpcbe/files/MPC-BE/Nightly%20Builds%20%28from%20svn%20trunk%29/MPC-BE%20v1.4.5%20%28build%20364%29%20beta/)
Register it with regsvr32 and you'll be able to use it within MPDN.
Thank you very much. Forgive my ignorance, can you please give me instructions on how to register it? I'm getting error
ryrynz
19th May 2015, 13:35
Thank you very much. Forgive my ignorance, can you please give me instructions on how to register it? I'm getting error
Sent you a PM.
That option is not enabled by default because some sources aren't compatible with it (chroma has "invalid" values). With compatible sources, it should give you more details on your chroma. It's quite hard to see though as the human eyes aren't particularly sensitive to chroma. It doesn't cost too much GPU to enable but on weaker GPUs you'll see a difference of a couple of percent points.
Yeah I checked the cost and TBH I'd think I'd enable it if it "worked" on all sources.
Zachs
19th May 2015, 13:38
Perhaps post the instructions on regsvr32 here as well? I'm sure other users would find it handy.
RGB48 is not supported and lavfilter send 8 bit RGB24/32 which is a huge problem for 10 bit output testing.
Y416 works fine
Zachs
19th May 2015, 14:12
Yeah RGB48 isn't supported because I haven't found a source with that format yet. You can use any of the 16bit YUV formats though which should do the job just as well.
burfadel
19th May 2015, 14:14
The semi random greyscale noise shader I mentioned in an earlier post that didn't work now works :). I like to have the strength around 1.0 in the file, it adds a very subtle yet nice fine random noise that helps to hide artifacts whilst at the same time bringing out fine details :).
Thanks for looking into that!
Yeah RGB48 isn't supported because I haven't found a source with that format yet. You can use any of the 16bit YUV formats though which should do the job just as well.
here have a source: http://www.bealecorner.org/red/test-patterns/Gradient-16bit.png
the real problem is lavfilter is outputting such a source as 8 bit to your renderer not as as 16 bit YCbCr. so i have to block RGB24/32
Hmm, mmc.exe is the Microsoft Management Console executable. If that crashes too, there's something that's rather seriously wrong with your machine...
It has only crashed once, out of roughly 10 times, when MPDN crashed. It's a fresh install, so I doubt it.
Zachs
19th May 2015, 14:24
The semi random greyscale noise shader I mentioned in an earlier post that didn't work now works :). I like to have the strength around 1.0 in the file, it adds a very subtle yet nice fine random noise that helps to hide artifacts whilst at the same time bringing out fine details :).
Thanks for looking into that!
Does it look very different to MPDN's random dithering with higher noise strength?
Zachs
19th May 2015, 14:26
here have a source: http://www.bealecorner.org/red/test-patterns/Gradient-16bit.png
the real problem is lavfilter is outputting such a source as 8 bit to your renderer not as as 16 bit YCbCr. so i have to block RGB24/32
I meant it's not worth spending time on implementing it for merely testing purposes when there are no actual video sources with that format. Not to mention that LAV should really be putting the 16bit format ahead of any 8bit ones in terms of precedence by default too.
Zachs
19th May 2015, 14:30
It has only crashed once, out of roughly 10 times, when MPDN crashed. It's a fresh install, so I doubt it.
Still, it should never crash, not even once. Fresh install doesn't rule out problems related to your hardware like system memory errors, which MPDN would be particularly sensitive to with it being written in .net.
burfadel
19th May 2015, 14:30
I forgot to add to my last post, there seems to be a bug with the 'Script chain' script.
If you add any items to the script chain, it works. However, if you close off the program and restart it, not matter what is in the script chain (even if it is one item), it comes up 'Object reference not set to an instance of an object'.
Now, the shaders work when you set them up, but when you close off MPDN and load it back up again, they don't work. Everything plays fine etc, just the shaders aren't applied and you get that message when you try to configure the shader chain.
I did delete the MediaPlayerDotNet folder from appdata and reset everything back up, it didn't work. Also, this error was BEFORE I tried the shader as mentioned in my previous post. So, currently if I close off the player I have to go to the appdata folder, delete the RenderScripts.64 folder from the MediaPlayerDotNet folder, and then reset the script chain up again before playing the files!
Shiandow
19th May 2015, 14:53
Found the problem with Script Chain. Some of the recent changes caused it to destroy its settings before saving them... Should be fixed now.
tobindac
19th May 2015, 15:42
You mean when you don't have the pre-requisites installed?
Are you being sarcastic? Because that's exactly what I said. People expect it to work.
The download section is extremely non-intuitive that it has prerequisites.
If you don't believe me put a 3rd party to review that for you.
PS. The main problem is LAV. Most people nowadays do not have it installed (mpc-hc has a very up to date version built in). At the same time this program does not even report it missing.
burfadel
19th May 2015, 15:42
Found the problem with Script Chain. Some of the recent changes caused it to destroy its settings before saving them... Should be fixed now.
Thanks! Works perfectly now :).
Anime Viewer
19th May 2015, 16:23
EDIT: v2.26 is now officially released.
I was hoping the new "use debug dialog for error messages" option might generate something with regards to screen freezing/MPDN not responding/having to sign out/restart windows when trying to use full screen exclusive mode with Direct3D 11, or Direct3D 10.1 as the presentation API with Optimus systems, but I'm guessing that only works with plugins and scripts.
http://forum.doom9.org/showthread.php?p=1705322#post1705322
I'm not sure how madVR's use of DX11 and exclusive mode differs from MPDN's use of DX11 and exclusive mode, but for some reason madVR/MPC-HC doesn't have the same problem(s) when "Direct3D 11 for presentation" and "full screen exclusive mode" are both used in it. Maybe there is a way around the problem other than waiting for a driver to fix the problem (which will probably never come). Don't know if madshi would be willing to explain how madVR's uses DX11 (perhaps in a more limited way than MPDN), or if he encountered bugs/freezing with madVR+Dx11+FSE during his testing that he found a work around for...
On another note checking the "Improve Chroma Reconstruction" box doesn't appear to have taxed my system any further. The ms render times appear to have remained the same, or at most increased by maybe 1ms. I suspect the "may not be compatible with all sources" may be why I don't see a difference. What type of sources/videos/files does it tend to take effect on?
Shiandow
19th May 2015, 16:41
On another note checking the "Improve Chroma Reconstruction" box doesn't appear to have taxed my system any further. The ms render times appear to have remained the same, or at most increased by maybe 1ms. I suspect the "may not be compatible with all sources" may be why I don't see a difference. What type of sources/videos/files does it tend to take effect on?
It takes effect on all sources, but it can give weird results in some cases.
The problem it tries to fix is that limiting RGB to values between 0 and 1 can change the corresponding YUV values. The default method just picks the closest possible RGB value, but the "improved" method tries to keep the luma values correct. This seems like it should be better in most cases, but some sources seem to contain errors that can cause this to look worse.
I'm not yet sure if these errors are intentional or if they are simply not detected because the method most renderers use tends to hide them.
Magik Mark
19th May 2015, 21:16
I'm getting this error when trying to configure script chain:
"Object reference not set to an instance of an object"
Any thoughts?
Shiandow
19th May 2015, 22:27
Could you try updating the renderscripts and deleting the Script Chain config file? There was a bug in the previous renderscripts that deleted the settings before saving them, this made the settings invalid.
Zachs
19th May 2015, 23:49
Are you being sarcastic? Because that's exactly what I said. People expect it to work.
The download section is extremely non-intuitive that it has prerequisites.
If you don't believe me put a 3rd party to review that for you.
PS. The main problem is LAV. Most people nowadays do not have it installed (mpc-hc has a very up to date version built in). At the same time this program does not even report it missing.
No, but I'm sorry if it sounded like it was a sarcasm. I was just trying to be sure it's not a bug or something else that you needed to fix before it would run. You didn't mention anything about prerequisites in your post.
I'm aware of that issue but it's a project that we do on our free time and at the moment it's really missing an installer. At the end of the day there's only so much time we could spend on it. Belphemur was going to do an installer for MPDN but he's got other things he's working on as well.
Magik Mark
20th May 2015, 00:05
Could you try updating the renderscripts and deleting the Script Chain config file? There was a bug in the previous renderscripts that deleted the settings before saving them, this made the settings invalid.
How do I do that?
Anime Viewer
20th May 2015, 00:21
How do I do that?
Delete and recopy the extensions folder from where you have MPDN installed to make sure your renderscripts are up-to-date.
Change the driver letter and "yourname" in the example below to match where your profile.
C:\Users\YourName\AppData\Local\MediaPlayerDotNet\
Delete the Mpdn.ScriptChain file in that directory.
Magik Mark
20th May 2015, 00:43
Delete and recopy the extensions folder from where you have MPDN installed to make sure your renderscripts are up-to-date.
Change the driver letter and "yourname" in the example below to match where your profile.
C:\Users\YourName\AppData\Local\MediaPlayerDotNet\
Delete the Mpdn.ScriptChain file in that directory.
Thank you that did it!
Zachs
20th May 2015, 02:56
@animeviewer I'll try to create a debug version of some sort so you could find out what was causing the hang. Maybe I could build the feature in there such that it detects lockups even in release builds. I'll see what I can do.
tobindac
20th May 2015, 14:26
No, but I'm sorry if it sounded like it was a sarcasm. I was just trying to be sure it's not a bug or something else that you needed to fix before it would run. You didn't mention anything about prerequisites in your post.
I'm aware of that issue but it's a project that we do on our free time and at the moment it's really missing an installer. At the end of the day there's only so much time we could spend on it. Belphemur was going to do an installer for MPDN but he's got other things he's working on as well.
Oh sorry then if I were too "premptive". I'd probably just do a small check before rendering and report "LAV not found", that should give a hint to anyone even barely familiar with video players.
If it's hard to detect LAV's presence, fine. I do not know much about coding for video players.
ryrynz
20th May 2015, 14:48
I'd probably just do a small check before rendering and report "LAV not found", that should give a hint to anyone even barely familiar with video players.
If it's hard to detect LAV's presence, fine. I do not know much about coding for video players.
This has been brought up a couple of times, It has caught me out on one occasion but figured it out quickly enough, and there is always "read the OP"
Zachs
20th May 2015, 15:09
Oh sorry then if I were too "premptive". I'd probably just do a small check before rendering and report "LAV not found", that should give a hint to anyone even barely familiar with video players.
If it's hard to detect LAV's presence, fine. I do not know much about coding for video players.
Doesn't it show the error that goes like this?
Load source failed
Hint:
Make sure LAV filters are installed
Belphemur
20th May 2015, 16:13
As Zach said, I decide to take on creating an installer for MPDN that bundles LAV, XySubFilter, the github extensions and of course the player.
I made a first version that is in BETA, only tested on X64 (but should work on x86). : http://mpdn.zachsaw.com/Installer/MediaPlayerDotNet_Installer.exe
It contains the last version of MPDN (v2.26.0) and the version of today Player Extensions.
The installer detect automatically what is your architecture and if you chose to install XySubFilter, it will also register the right version for the player.
The Installer of LAV Filter is embedded into it, if you choose to install it, it will launch LAV Filter installer.
I still have to do more testing when upgrading from one version to the other, especially with the Extensions.
Any feedback is welcome.
pirlouy
20th May 2015, 19:57
I continued my comparison (http://forum.doom9.org/showthread.php?p=1721840#post1721840) with madVR (+MPC-HC).
I don't know if you like this kind of post, and if it upsets you, tell me, but I though it would be interesting to compare this player with a known alternative.
With my ATI 5770, I told you CPU was higher with MPDN.
With the same config, except using integrated Intel GPU (HD 2000) instead of ATI card (unplugged), MPDN still uses a bit more CPU, but is is less pronounced, and it uses less GPU.
That lets me think GPU cards have an incidence on differences of performance between madVR and MPDN. I remember my ATI 5770 is known to have bad performances in some area (Madshi had released a little tool to measure differences between cards). It looks like you don't use the same way to "speak" to system to have the final image.
I also tried on another system, and with a NVidia GT 430, MPDN had slightly better results (CPU & GPU).
For the startup, I don't know if you can do something or it's just DotNet stuff, but MPDN takes several seconds (depending on system but still second is the right unit) more to start the video than MPH-HC.
Another thing I've noticed is MPDN statistics OSD cost CPU whereas madVR OSD uses 0 resources.
And an anomaly to finish this boring post: dropped frames are not reported on FullScreen Exclusive (I use D3D9).
Hope you won't take it the wrong way and it was just a try to help you improve this player.
ryrynz
21st May 2015, 01:15
Another thing I've noticed is MPDN statistics OSD cost CPU whereas madVR OSD uses 0 resources.
Could be in part related to the fact that MPDN's OSD updates at least five times faster than madVR's.
Magik Mark
21st May 2015, 03:33
Hey Zach,
Do you mind sharing the ff:
1. The hierarchy of your render scripts. Which comes first, middle & last as well as their respective settings
2. Your chroma & Luma scaler & down scaler preferences
It would be awesome to see how experts like you are setted up
Thanks a lot
Anime Viewer
21st May 2015, 04:09
With my ATI 5770, I told you CPU was higher with MPDN.
With the same config, except using integrated Intel GPU (HD 2000) instead of ATI card (unplugged), MPDN still uses a bit more CPU, but is is less pronounced, and it uses less GPU.
That lets me think GPU cards have an incidence on differences of performance between madVR and MPDN.
I also tried on another system, and with a NVidia GT 430, MPDN had slightly better results (CPU & GPU).
Unless its using up CPU/GPU to the point of causing resource problems on your system (where you can't do other tasks or watch video on your system successfully) I don't see why that is a problem. If the GPU and CPU aren't being used that could mean that their workload may be getting dumped off to slower parts of the system for handling (like system memory - which can be slower than video memory, or the disk drive - which can be slower than memory - SSD can be excluded from this occasionally).
For the startup, I don't know if you can do something or it's just DotNet stuff, but MPDN takes several seconds (depending on system but still second is the right unit) more to start the video than MPH-HC.
Are you talking about when it says: "optimizing extensions", or are you talking about something else? You could always turn off extensions (and delete that directory to speed things up), but then you'd loose out on features.
Another thing I've noticed is MPDN statistics OSD cost CPU whereas madVR OSD uses 0 resources.
Do you plan on watching entire videos on a regular basis with with OSD on the entire time? I doubt it, so what does it matter if OSD uses a few resources when you aren't going to have that active normally?
And an anomaly to finish this boring post: dropped frames are not reported on FullScreen Exclusive (I use D3D9).
Are you saying your system is dropping frames (where you notice on screen problems)? If not what is the problem? If its not dropping frames that is a good thing.
Not all settings can be configured identical for both, so they can't be compared apples to apples.
I think you're getting too wrapped up in insignificant things. The most important things is: Which is giving you better image quality? Which has the features you want to use?
As they both stand I feel MPDN is currently providing the superior video picture on my system, and is why that is my default video program.
Zachs
21st May 2015, 08:01
Hey Zach,
Do you mind sharing the ff:
1. The hierarchy of your render scripts. Which comes first, middle & last as well as their respective settings
2. Your chroma & Luma scaler & down scaler preferences
It would be awesome to see how experts like you are setted up
Thanks a lot
I'm probably not the best to ask since I'm still running an older version of MPDN on my HTPC (hence an older version of scripts too) - been spending way too much time developing MPDN it's getting in the way of my enjoyment of my own creation!
I'll say this though, it's really up to you and the contents you view, as well as how much your GPU can take (or GPU fan noise you are willing to put up with).
I was hoping the new "use debug dialog for error messages" option might generate something with regards to screen freezing/MPDN not responding/having to sign out/restart windows when trying to use full screen exclusive mode with Direct3D 11, or Direct3D 10.1 as the presentation API with Optimus systems, but I'm guessing that only works with plugins and scripts.
I've just released 2.26.1, specifically targeting this problem (app hang). It *should* detect the situation where MPDN becomes unresponsive and causes a crash on purpose (after several seconds). You'll get a crash dump file in %localappdata%\MediaPlayerDotNet.exe.dump.
p.s. Thanks for helping out in the forum!
Zachs
21st May 2015, 08:22
Ah found a bug with the latest version. It'll crash when it exits. I'll fix it in the next release.
EDIT: Fixed. v2.26.2.
Magik Mark
21st May 2015, 09:24
Which hardware decoder works best? cuvid or dxva2?
Magik Mark
21st May 2015, 09:32
Is it possible to have 16bit in windows mode? I'm only getting 16bit in FSE
nevcairiel
21st May 2015, 09:33
Is it possible to have 16bit in windows mode? I'm only getting 16bit in FSE
No, anything above 8-bit requires FSE.
pirlouy
21st May 2015, 11:45
Unless its using up CPU/GPU to the point of causing resource problems on your system (where you can't do other tasks or watch video on your system successfully) I don't see why that is a problem. If the GPU and CPU aren't being used that could mean that their workload may be getting dumped off to slower parts of the system for handling (like system memory - which can be slower than video memory, or the disk drive - which can be slower than memory - SSD can be excluded from this occasionally).
If CPU and GPU are more used, there are less resources for more demanding operations. Simple.
If a program uses 15% CPU more and 10% GPU more with no differences in the end, it's a drawback. If you call it a feature, you'll have a hard time convince others.
Are you talking about when it says: "optimizing extensions", or are you talking about something else? You could always turn off extensions (and delete that directory to speed things up), but then you'd loose out on features.
It's easy. I double click on a file, I count the time it needs to have the video started.
On a computer, it's 5 seconds for MPC-HC, 7 seconds for MPDN.
Do you plan on watching entire videos on a regular basis with with OSD on the entire time? I doubt it, so what does it matter if OSD uses a few resources when you aren't going to have that active normally?
It's better for comparisons ? Maybe I though there were no more resources with madVR so maybe it's a bug in MPDN. Is this forbidden to report a strange behavior compared to another application ?
Are you saying your system is dropping frames (where you notice on screen problems)? If not what is the problem? If its not dropping frames that is a good thing.
Dude, you really took me for an idiot until the end. But I'll answer anyway because I'm a nice guy. Let's say I take Jinc 64 taps in chroma/Luma upscalind/downscaling. I have dropped frames, visible on screen, which are displayed in OSD when in windowed mode. As soon as I enter fullscreen, dropped frames are not displayed in OSD (I mean the number does not raise) whereas they are clearly visible.
Not all settings can be configured identical for both, so they can't be compared apples to apples.
Well it's obvious there are similarities between madVR and MPDN options. There are at least 20 options which does the same thing (or are supposed to). And since they do the same (display images), it is logical to try to compare both. Do you tell me you did not even compare them ? You just chose MPDN without comparison ?
I think you're getting too wrapped up in insignificant things. The most important things is: Which is giving you better image quality? Which has the features you want to use?
They might be insignificant things for you, not for me, and I'm quite sure I'm not alone. And since I can't tell the differences about quality (I'm not even able to see a difference between bilinear and lanczos or NNEDI), I compare what I can compare: performance graph.
As they both stand I feel MPDN is currently providing the superior video picture on my system, and is why that is my default video program.
I'm very happy for you. I'm happy too, but when I wrote my post, it was to give a review and help the development. But as I said, Zach is free to ignore it or to tell me to stop posting here.
Zachs
21st May 2015, 12:01
@pirlouy
I think the comparisons are only suitable where GPU costs are concerned. Even then, MPDN does things very differently to madVR. For example, the algorithms for dithering are completely different. MPDN also uses 2 separate graphs for audio and video - and pre-buffering etc. are all different to MPC/madVR. As you've found out, even GPU costs have to be taken with a grain of salt - different drivers will give you different results. CPU usage wise, the only difference you've pointed out was that MPDN uses more CPU when it had OSD turned on. On my 2nd gen i5, if it rises, it's only by a non-measurable amount. However you have to keep in mind that MPDN refreshes the OSD a LOT more frequently than madVR. The quality of font used also affects the CPU (yes, not GPU) usage. Again, can't compare the two - as Anime Viewer puts it, not an apple-to-apple comparison. MPDN also shows info that madVR doesn't (e.g. 2 or 5 seconds avg/max durations etc while madVR shows a long term average and is much less accurate when GPU clock changes).
I have not seen the dropped frames not increasing problem on my end. Hmm it makes no sense if it would do it in windowed mode and not FSE though. They rely on the same piece of code for dropping frames and counting them. What does your average frame rate show when the frames are visibly dropped? Did it drop at all?
ryrynz
21st May 2015, 13:13
@pirlouy
On my 2nd gen i5, if it rises, it's only by a non-measurable amount.
I was curious about this so I tested on my i5 3570. The moving average was 1% higher with the OSD enabled.
Zachs
21st May 2015, 13:18
I was curious about this so I tested on my i5 3570. The moving average was 1% higher with the OSD enabled.
Yeah on my 4Ghz i5, it was less than 1% so it was barely showing up as anything at all.
Magik Mark
21st May 2015, 13:27
Slight pause is happening from time to time. Its like you are running out of buffer. Any thoughts?
ryrynz
21st May 2015, 13:36
Slight pause is happening from time to time. Its like you are running out of buffer. Any thoughts?
My thoughts would be monitor CPU and GPU whilst observing the OSD to determine what it could be, then reset everything to defaults and see if it still does it.
Too many variables to know for sure..
Belphemur
21st May 2015, 13:49
Slight pause is happening from time to time. Its like you are running out of buffer. Any thoughts?
I had the same when I was asking too much to my GPU using NNEDI3.
In the end, I discover if the average render time is higher than 42-43 ms, MPDN start "eating" the buffer faster than filling it. It leads to a drop of frame.
Try to tweak the different Renderer you are using.
Anime Viewer
21st May 2015, 13:56
And an anomaly to finish this boring post: dropped frames are not reported on FullScreen Exclusive (I use D3D9).
As Zachs has written in other posts different drivers can run better in different D3D modes. With one driver version D3D9 may work better, and with the next driver release D3D10.1 or D3D11 might run better. Have you tried with with the other D3D presentation modes in MPDN to see if they make a difference? Just because you choose to use D3D9 in madVR it doesn't mean that D3D9 is the best choice for you in MPDN.
Shiandow
21st May 2015, 14:51
WARNING, do not update to the latest renderscripts. There might be a bug with Script Chain again. I'll remove this warning when I'm sure it's safe again.
Okay, renderscripts should be safe again.
pirlouy
21st May 2015, 18:28
http://i.imgur.com/XrOJFFr.jpg
Indeed it depends on files and shaders used. If I used harder shaders, dropped frames counter will increase. But in this example, counter does not raise whereas it should.
Belphemur
21st May 2015, 19:35
http://i.imgur.com/XrOJFFr.jpg
Indeed it depends on files and shaders used. If I used harder shaders, dropped frames counter will increase. But in this example, counter does not raise whereas it should.
Those number seems fine to me. From my understanding (but I can be wrong), dropped frame or not, the rendering time won't change.
Because first the image get pass through the renderer and then feeded to the player that decide if the delay between audio and video is too big to keep the frame, in that case it drops it.
The time to render a frame won't be impacted by the dropped frame.
Btw you should test also by keeping the player in window mode with the resolution of your video compared to fullscreen.
Magik Mark
22nd May 2015, 00:31
Is there a website that would compare images from different chroma & luma scaling options? This is handy when making our choices. Maybe other rendering scripts as well
Zachs
22nd May 2015, 01:15
http://i.imgur.com/XrOJFFr.jpg
Indeed it depends on files and shaders used. If I used harder shaders, dropped frames counter will increase. But in this example, counter does not raise whereas it should.
It's behaving correctly - it shouldn't be dropping in the FSE mode because your average render time is less than 41.67ms (video frame interval), and render queue is thus filled up fully. If you see dropped frames visibly, it's a problem outside of what is detectable by MPDN.
Magik Mark
22nd May 2015, 02:31
Zach
Can you help us classify which are heavy, medium & light shaders / renderers? This could help us choosing better configurations. Thanks
Zachs
22nd May 2015, 03:04
This is a very hard question to answer, mainly because it really depends on the GPU / driver / source content / shader settings / renderer settings etc.
Generally though, the following should be true (from least costly to most expensive), using default settings.
MPDN hardware scalers
MPDN pixel shader scalers
NEDI
NNEDI3
The SuperRes filter augment the scalers and adds more costs to it depending on its settings.
You'll have to try it for yourself - the player statistics OSD is the tool to let you decide which settings to pick for a particular source content.
Different source contents (fps, resolution, etc.) will require different scalers and will put different loads on the GPU.
Belphemur
22nd May 2015, 06:13
This is a very hard question to answer, mainly because it really depends on the GPU / driver / source content / shader settings / renderer settings etc.
Generally though, the following should be true (from least costly to most expensive), using default settings.
MPDN hardware scalers
MPDN pixel shader scalers
NEDI
NNEDI3
The SuperRes filter augment the scalers and adds more costs to it depending on its settings.
You'll have to try it for yourself - the player statistics OSD is the tool to let you decide which settings to pick for a particular source content.
Different source contents (fps, resolution, etc.) will require different scalers and will put different loads on the GPU.
Could you make the render time change color when going higher than 41.67ms ?
It would help people to understand when the frame start dropping and that new render settings are needed :)
Zachs
22nd May 2015, 06:43
It's not always higher than 41.67ms. In fact, you could have a source clip that delivers variable frame rates and MPDN will still be able to cope (yes it supports variable fps). Not to mention that you can change this output rate via render script too.
Belphemur
22nd May 2015, 07:45
It's not always higher than 41.67ms. In fact, you could have a source clip that delivers variable frame rates and MPDN will still be able to cope (yes it supports variable fps). Not to mention that you can change this output rate via render script too.
What is the formula used to drop a frame ? It could help to create a "optimization" guide for MPDN :)
Zachs
22nd May 2015, 07:55
There's a few things that could cause a dropped frame, but the most common one would be caused by the frame timestamp being earlier than current reference clock. Your render queue tends to run low when that happens.
Btw some GPUs/drivers don't like running at over 90% load. When that happens, you'll find frame deliveries start to get choppy even when the driver tells MPDN everything is fine.
The trick is to back off enough to give the GPU a bit of headroom to do what's important - presenting the frames smoothly.
On my nvidia cards I've got no problem running them at 40ms for 23.976fps materials. Fans would scream but it's smooth as.
Zachs
22nd May 2015, 15:36
@AnimeViewer, do you still get the lockup problem when you go into of FSE mode?
Anime Viewer
23rd May 2015, 00:58
@AnimeViewer, do you still get the lockup problem when you go into of FSE mode?
I installed the the most recent version (v2.26.3) on top of my previous version (using the new installer), and still had the problem. I wiped out (uninstalled) MPDN from control panel, and then went into my MPDN profile settings (in C:\Users\Myname\AppData\Local and deleted the MediaPlayerDotNet directory (to reset everything). It worked in that default state (D3D 9Ex), but when I try either of the other (D3D 10.1 or D3D 11) its back to freezing the window/screen (except sometimes I can hear audio still playing).
On another note XYSubFilter seems to be a problem in the new version. When subtitles are on the screen the rest of the screen (aside from the subtitles) turns black. When characters stop talking (thus no subtitles) the video appear back on the screen, but the minute the subtitles appear again the screen turns black again until the subtitles disappear off the screen.
Magik Mark
23rd May 2015, 02:09
Zach
What happened? All I get is black screen & audio
Zachs
23rd May 2015, 02:45
Did you guys use the installer? I suspect it may be due to a bad XySubFilter version. I'll investigate later when I get done time. In the meantime, try downloading another version of the filter and install that instead.
@animeviewer did you manage to get the dump file when it locked up? It should crash on purpose when it detects a lockup after about 5 seconds. You'll then get a dump file. Check my post a few pages back.
Magik Mark
23rd May 2015, 03:15
Zach
It wasn't the xysubfilter. Its something else. Reverted back to its predecessor. Everything is ok now
Zachs
23rd May 2015, 03:16
Well then it's certainly something I'm not experiencing on my end. Is the OSD showing?
Anyway I'll investigate.
Magik Mark
23rd May 2015, 03:20
Yes OSD is fine
Zachs
23rd May 2015, 03:26
So just to confirm, 2.26.2 was fine?
Can you also zip up your MPDN config folder so I could use the same settings to try and replicate the problem?
Magik Mark
23rd May 2015, 03:32
So just to confirm, 2.26.2 was fine?
Can you also zip up your MPDN config folder so I could use the same settings to try and replicate the problem?
Yes! Working perfectly for now
Zachs
23rd May 2015, 03:35
You might wanna upload the file on a file upload website, that way I don't have to wait for the attachment to be approved.
2.26.2 -> works great
2.26.3 -> turn on any render script even blank one=no video only audio and xysubfilter blinking picture as explained by Anime Viewer
By blank one I mean you can select image processor with no shaders and the moment you press apply blank picture.
Great player BTW :-)
Zachs
23rd May 2015, 03:57
Thanks for the report. Appreciate it.
In the meantime, I'd recommend just to use 2.26.2 for now until I sort out the issues with the latest version.
Anime Viewer
23rd May 2015, 04:24
@animeviewer did you manage to get the dump file when it locked up? It should crash on purpose when it detects a lockup after about 5 seconds. You'll then get a dump file. Check my post a few pages back.
It doesn't appear to create any dump file (I'm not sure that it detects a crash). Since it locks the screen (keyboard still works for capslock, numlock , ctrl+alt+delete, alt-tabing (even though it will not switch to anything else. Unless you choose ctrl+alt+del and choose log-off. At that time you can alt-tab between windows, but can't interact or navigate on any of them. The MPDN app shows in the taskbar, but right-clicking on it and choosing close all windows will not do anything (it doesn't react). The only way to shut out of it is to tell it to switch users (or restart). As far as I can tell it didn't create any file in the user config folder, nor the install location of MPDN.
Zachs
23rd May 2015, 05:55
Was the mouse cursor showing a wait cursor or was it a normal pointer cursor? The next time it happens, could you wait for 30 seconds and see if it manages to detect that it's locked up?
ryrynz
23rd May 2015, 11:07
So my TV accepts 12 bit input at <24hz but Nvidia's drivers don't remember the previous setting at that refresh rate.
Any chance of having MPDN be able to set the bit depth output of the graphics card via the display changer?
burfadel
23rd May 2015, 11:10
2.26.2 -> works great
2.26.3 -> turn on any render script even blank one=no video only audio and xysubfilter blinking picture as explained by Anime Viewer
By blank one I mean you can select image processor with no shaders and the moment you press apply blank picture.
Great player BTW :-)
Exact same issue here!
Anime Viewer
23rd May 2015, 13:08
Was the mouse cursor showing a wait cursor or was it a normal pointer cursor? The next time it happens, could you wait for 30 seconds and see if it manages to detect that it's locked up?
No, the mouse cursor does not show during the MPDN freeze. I've waited longer than 30 seconds (a few minutes with nothing changing).
Zachs
23rd May 2015, 15:19
Exact same issue here!
Fixed in v2.26.4.
Zachs
23rd May 2015, 15:21
No, the mouse cursor does not show during the MPDN freeze. I've waited longer than 30 seconds (a few minutes with nothing changing).
OK try this when you have the chance. When it locks up, double click the full screen windows a few time. Then wait for 30 seconds. If it still doesn't auto-terminate, it probably means something terminal has occurred...
Anime Viewer
23rd May 2015, 18:49
OK try this when you have the chance. When it locks up, double click the full screen windows a few time. Then wait for 30 seconds. If it still doesn't auto-terminate, it probably means something terminal has occurred...
Edit:
It froze again, and I double clicked (when there is a nonexistent mouse cursor during the initial freeze), and nothing ever happened). After I did switch user to were it is still running, and I double clicked on it on the taskbar (again with no change, and it not switching to it) I again waited 30+ seconds but nothing ever happened. Task Manager in that state reports it as not responding, but it never times out (and just like how I can't interact with MPDN I can't interact act with any other programs except to switching to them with alt-tab, but I can't do anything other than display their windows - for example I can't scroll or type anything on this forum), and can't close out of them during that non-responsive MPDN state.
Edit:
Odd. It doesn't appear to occur with one file I have tested (with the following properties).
Unique ID : 0
Complete name : (file name omitted)
Format : Matroska
File size : 157209197
Duration : 1452199
Overall bit rate : 866048
Encoded date : 2/22/2010 9:41:29 PM
Writing application : no_variable_data
Writing library : no_variable_data
Video
ID : 1
Format : AVC
Format profile : Main@L3.1
Format settings : CABAC / 6 Ref Frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1452202
Bit rate : 0
Width : 848
Height : 480
Display aspect ratio : 1.006
Frame rate mode : CFR
Frame rate : 23.976
Chroma subsampling : 4:2:0
Bit depth : 8
Scan type : Progressive
Bits/(Pixel*Frame) : 0
Stream size :
Writing library : x264 - core 120 r2120 0c7dab9
Encoding settings : cabac=1 / ref=6 / deblock=1:1:1 / analyse=0x1:0x111 / me=umh / subme=8 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=768 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=1536 / vbv_bufsize=3840 / nal_hrd=none / ip_ratio=1.40 / aq=1:0.60
Language :
Audio
ID : 2
Format : AAC
Codec ID : A_AAC
Duration : 1452199
Bit rate mode :
Bit rate : 0
Channel(s) : 2
Sampling rate : 44100
Bit depth : 0
Compression mode : Lossy
Stream size : 0
Language :
Subtitle
ID : 3
Format : ASS
Muxing Mode :
Codec ID : S_TEXT/ASS
Language :
But appears to occur with every other file I test. (For example):
Unique ID : 199100304361845660068191694678274133701
Complete name : (file name ommited)
Format : Matroska
File size : 474810722
Duration : 1440000
Overall bit rate : 2637837
Encoded date : 5/17/2015 11:53:54 AM
Writing application : mkvmerge v7.7.0 ('Six Voices') 32bit built on Feb 28 2015 23:23:00
Writing library : libebml v1.3.1 + libmatroska v1.4.2
Video
ID : 18041449390369659311
Format : AVC
Format profile : Main@L4.1
Format settings : CABAC / 6 Ref Frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1439982
Bit rate : 0
Width : 1280
Height : 720
Display aspect ratio : 1
Frame rate mode : CFR
Frame rate : 23.976
Chroma subsampling : 4:2:0
Bit depth : 8
Scan type : Progressive
Bits/(Pixel*Frame) : 0
Stream size :
Writing library : x264 - core 142 r2479 dd79a61
Encoding settings : cabac=1 / ref=6 / deblock=1:1:1 / analyse=0x1:0x111 / me=hex / subme=7 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=5 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=2432 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=50000 / vbv_bufsize=62500 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:0.60
Language : ja
Audio
ID : 15032933852594981766
Format : AAC
Codec ID : A_AAC
Duration : 1440000
Bit rate mode :
Bit rate : 0
Channel(s) : 2
Sampling rate : 48000
Bit depth : 0
Compression mode : Lossy
Stream size : 0
Language : ja
Subtitle
Edit:
On the frozen video screen if I have CTRL+J active it shows the Render queue at 0/12 at the point it switched and froze. Running with "Use new windowed mode rendering path when possible" unchecked the problem doesn't appear to occur in the second video - that normally freezes. **edit: scratch that...it still occurred with new mode unchecked, but for some reason that one time it didn't.
Edit:
Anyone else noticing Fluid Motion fluctuating on and off almost every second when watching 23.976Hz files on 59/60Hz screens? (Its actually causing Judder (and tons of dropped and delayed frames - probably as a result of the constant switching on and off) on my screen as opposed to the same video running smoothly with it turned off).
Magik Mark
24th May 2015, 10:12
Hey Zach
Do you know where I can download denoise shader for your player? Maye other shaders as well too? Thanks a lot
Anime Viewer
24th May 2015, 13:56
Hey Zach
Do you know where I can download denoise shader for your player? Maye other shaders as well too? Thanks a lot
MPDN users shaders with the extension HLSL. If you already have them on your system from another video player (Ex: MPHC/MadVR) then you just need to copy if from one location to another. (EX: E:\Program Files\KCP\MPC-HC\Shaders to E:\Program Files\MediaPlayerDotNet\Extensions\RenderScripts\ImageProcessingShaders). From there you'd go into Options, Render Scripts, select Image Processor (if that is where you copied it to), click the +, and add it inside the shader chain there.
Be aware that it may not have been tested in combination with other scripts/shaders you may use in MPDN, so it may not give you the effect you are looking for. From what I recall MPDN had a Denosie script a while back (that may be named something else now), so you may not have to do all this to begin with...
Edit: Anyone have a theroy on what is causing the distortion to the image shown below? Both are running at their native resolution, so scaling is not at play. Both have the same dithering (ordered) selected, and both are using Shiandow's debanding at the same strength, so those shouldn't be the issue.
Image on the left side is with madVR. Image on the right side is with MPDN. (http://s12.postimg.org/q7av6vm6j/what_is_the_cause.jpg)
http://s12.postimg.org/q7av6vm6j/what_is_the_cause.jpg
Magik Mark
24th May 2015, 22:13
Can somebody test this flickering issue in d3d 11 16bit:
When I switch to d3d window full screen, screen flickers. Looks like refresh rate changes without consent
d3d windowed (not full screen) - ok
d3d FSE - ok
Nvidia v352.86, GTX 550ti, Pioneer Kuro
Zachs
25th May 2015, 00:40
just like how I can't interact with MPDN I can't interact act with any other programs except to switching to them with alt-tab, but I can't do anything other than display their windows - for example I can't scroll or type anything on this forum), and can't close out of them during that non-responsive MPDN state.
This sounds more like a system wide failure than just MPDN failing. No wonder the detection mechanism failed to pick up anything - it's probably locked up like the rest of the system too.
Just run me through how you cause the problem to occur again - particularly, do you use double-click or alt+enter to enter FSE mode? Does it happen every time and immediately when you go FSE?
Anyone else noticing Fluid Motion fluctuating on and off almost every second when watching 23.976Hz files on 59/60Hz screens? (Its actually causing Judder (and tons of dropped and delayed frames - probably as a result of the constant switching on and off) on my screen as opposed to the same video running smoothly with it turned off).
The only thing that could cause fluid motion to turn off is when your render queue goes below 2 - it needs one frame rendered in advance for fluid motion to function.
Edit: Anyone have a theroy on what is causing the distortion to the image shown below? Both are running at their native resolution, so scaling is not at play. Both have the same dithering (ordered) selected, and both are using Shiandow's debanding at the same strength, so those shouldn't be the issue.
Image on the left side is with madVR. Image on the right side is with MPDN. (http://s12.postimg.org/q7av6vm6j/what_is_the_cause.jpg)
http://s12.postimg.org/q7av6vm6j/what_is_the_cause.jpg
Does this happen when you have no render scripts running?
Can somebody test this flickering issue in d3d 11 16bit:
When I switch to d3d window full screen, screen flickers. Looks like refresh rate changes without consent
d3d windowed (not full screen) - ok
d3d FSE - ok
Nvidia v352.86, GTX 550ti, Pioneer Kuro
Windowed full screen mode is just like any other windowed mode except its window size is the same as your display resolution. In fact, MPDN doesn't treat it any differently. I've also just tested it out on 3 different machines with different GPUs and none have this problem.
Edit: Anyone have a theroy on what is causing the distortion to the image shown below? Both are running at their native resolution, so scaling is not at play. Both have the same dithering (ordered) selected, and both are using Shiandow's debanding at the same strength, so those shouldn't be the issue.
Image on the left side is with madVR. Image on the right side is with MPDN. (http://s12.postimg.org/q7av6vm6j/what_is_the_cause.jpg)
http://s12.postimg.org/q7av6vm6j/what_is_the_cause.jpg
looks like the right screen has the wrong levels and is clipping all dark details. it's not the same screens so hard to judge.
open the same Scene in madVR press alt + control + shift + i until you see TV double expanded. if this give you the same artefacts i guessed right.
Shiandow
25th May 2015, 01:48
Edit: Anyone have a theroy on what is causing the distortion to the image shown below? Both are running at their native resolution, so scaling is not at play. Both have the same dithering (ordered) selected, and both are using Shiandow's debanding at the same strength, so those shouldn't be the issue.
Image on the left side is with madVR. Image on the right side is with MPDN. (http://s12.postimg.org/q7av6vm6j/what_is_the_cause.jpg)
http://s12.postimg.org/q7av6vm6j/what_is_the_cause.jpg
Looks like the kind of artefacts the chroma limiter can cause, try disabling "Improve chroma reconstruction".
Anime Viewer
25th May 2015, 02:32
Looks like the kind of artefacts the chroma limiter can cause, try disabling "Improve chroma reconstruction".
Right you were, it was the Improve Chroma Reconstruction that was at fault. :thanks:
it's not the same screens so hard to judge.
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.
This sounds more like a system wide failure than just MPDN failing. No wonder the detection mechanism failed to pick up anything - it's probably locked up like the rest of the system too.
Just run me through how you cause the problem to occur again - particularly, do you use double-click or alt+enter to enter FSE mode? Does it happen every time and immediately when you go FSE?
The only thing that could cause fluid motion to turn off is when your render queue goes below 2 - it needs one frame rendered in advance for fluid motion to function.
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 can't seem to recreate the fluid motion on/off issue. If it reoccurs again I'll pay attention to what the queues do.
ryrynz
25th May 2015, 07:37
Looks like the kind of artefacts the chroma limiter can cause, try disabling "Improve chroma reconstruction".
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.
Zachs
25th May 2015, 08:05
Yeah there's a reason why it's not enabled by default and comes with a warning that says it's not compatible with all sources. :)
madshi
25th May 2015, 08:14
Right you were, it was the Improve Chroma Reconstruction that was at fault. :thanks:
Can we have a small sample of this scene, please? It's always useful to have samples which make problems like this.
ryrynz
25th May 2015, 09:50
Can we have a small sample of this scene, please? It's always useful to have samples which make problems like this.
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.
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.
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?
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?
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.
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.
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.
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.
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.
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
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.
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?
Zachs
28th May 2015, 00:51
@AnimeViewer
BTW, the dump file is located in %localappdata%\MediaPlayerDotNet.exe.dump
Can you check if you have such a file please?
Zachs
28th May 2015, 00:53
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?
Run it without render scripts. Bright fully saturated red is the easiest to see the changes.
EDIT: This is assuming the proper colorimetric has been used. If the encoder lied about it then that's a separate issue.
Anime Viewer
28th May 2015, 00:56
@AnimeViewer
BTW, the dump file is located in %localappdata%\MediaPlayerDotNet.exe.dump
Can you check if you have such a file please?
Ah ha! I found it there. Here is the dump which I opened and copied from Notepad:
*** Thread 1 ***
Stack Trace:
Mpdn.VideoFrameServices.DxgiPresenter.DxgiPresentEx(IntPtr, Int32)
Mpdn.VideoFrameServices.DxgiPresenter.DxgiPresentEx(IntPtr, Int32)
DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr, Int32)
Mpdn.D3D9VideoRenderer.FrameComposer.Dx11.FrameComposer.Present(Int64 ByRef)
Mpdn.D3D9VideoRenderer.VideoRenderer.PresentInternal(Int64 ByRef)
Mpdn.D3D9VideoRenderer.VideoRenderer.Present(Boolean, Boolean, SharpDX.Result ByRef, Int64 ByRef)
Mpdn.VideoPlayer.VideoPlayer.Present(Boolean, SharpDX.Result ByRef, Int64 ByRef)
Mpdn.VideoPlayer.VideoPlayer.WaitAndPresent(Int64, Int64, Boolean, Boolean, Int64 ByRef)
Mpdn.VideoPlayer.VideoPlayer.Present(Int64, Int64, Boolean, Int64 ByRef)
Mpdn.VideoPlayer.VideoPlayer.Present()
Mpdn.VideoPlayer.VideoPlayer.PresentSample(Mpdn.VideoPlayer.MediaSample)
Mpdn.VideoPlayer.VideoPlayer+<>c__DisplayClass2.<set_EnableFullScreen>b__0(Boolean)
Mpdn.VideoPlayer.VideoPlayer.SyncRendererInvoke(System.Action`1<Boolean>)
Mpdn.VideoPlayer.VideoPlayer.set_EnableFullScreen(Boolean)
MediaPlayerDotNet.MainForm.
ťť()
MediaPlayerDotNet.MainForm.
ť()
MediaPlayerDotNet.MainForm.
(System.Object, System.Windows.Forms.MouseEventArgs)
System.Windows.Forms.Control.WmMouseUp(System.Windows.Forms.Message ByRef, System.Windows.Forms.MouseButtons, Int32)
System.Windows.Forms.Control.WndProc(System.Windows.Forms.Message ByRef)
System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr)
DomainBoundILStubClass.IL_STUB_ReversePInvoke(Int64, Int32, Int64, Int64)
System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG ByRef)
System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG ByRef)
DomainBoundILStubClass.IL_STUB_PInvoke(MSG ByRef)
System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)
System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)
System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)
.
.
Ť(System.Object)
.
.
(System.Object)
<PrivateImplementationDetails>{B078818A-34A0-41B9-9995-5CD01146F517}.Main(System.String[])
-------------------------------------------------------------------------------------------
*** Thread 2 ***
Stack Trace:
-------------------------------------------------------------------------------------------
*** Thread 4 ***
Stack Trace:
System.Threading.WaitHandle.WaitOneNative(System.Runtime.InteropServices.SafeHandle, UInt32, Boolean, Boolean)
System.Threading.WaitHandle.InternalWaitOne(System.Runtime.InteropServices.SafeHandle, Int64, Boolean, Boolean)
Mpdn.Threading.TaskThread.DoWork()
System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
System.Threading.ThreadHelper.ThreadStart()
-------------------------------------------------------------------------------------------
*** Thread 10 ***
Stack Trace:
System.Windows.Forms.UnsafeNativeMethods.WaitMessage()
System.Windows.Forms.UnsafeNativeMethods.WaitMessage()
System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)
System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)
System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)
System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
System.Threading.ThreadHelper.ThreadStart()
-------------------------------------------------------------------------------------------
*** Thread 13 ***
Stack Trace:
System.Threading.WaitHandle.WaitMultiple(System.Threading.WaitHandle[], Int32, Boolean, Boolean)
System.Threading.WaitHandle.WaitAny(System.Threading.WaitHandle[], Int32, Boolean)
Mpdn.VideoPlayer.DirectShowVideo.HandleEvents(Microsoft.Win32.SafeHandles.SafeWaitHandle, Microsoft.Win32.SafeHandles.SafeWaitHandle)
Mpdn.VideoPlayer.DirectShowVideo.HandleEvents(System.Object)
Mpdn.Threading.WorkerThread+<>c__DisplayClass6.<.ctor>b__4(System.Object)
System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
System.Threading.ThreadHelper.ThreadStart(System.Object)
-------------------------------------------------------------------------------------------
*** Thread 14 ***
Stack Trace:
System.Threading.WaitHandle.WaitMultiple(System.Threading.WaitHandle[], Int32, Boolean, Boolean)
System.Threading.WaitHandle.WaitAny(System.Threading.WaitHandle[], Int32, Boolean)
Mpdn.VideoPlayer.VideoPlayer.PresentLoop()
Mpdn.Threading.WorkerThread+<>c__DisplayClass2.<.ctor>b__0()
System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
System.Threading.ThreadHelper.ThreadStart()
-------------------------------------------------------------------------------------------
*** Thread 15 ***
Stack Trace:
System.Threading.Monitor.Enter(System.Object)
Mpdn.VideoPlayer.VideoPlayer.RenderLoop()
Mpdn.Threading.WorkerThread+<>c__DisplayClass2.<.ctor>b__0()
System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
System.Threading.ThreadHelper.ThreadStart()
-------------------------------------------------------------------------------------------
*** Thread 18 ***
Stack Trace:
System.Threading.Monitor.Enter(System.Object)
Mpdn.VideoPlayer.VideoPlayer.UpdateVideoFrame(Mpdn.VideoPlayer.MediaSample)
Mpdn.VideoPlayer.DirectShowVideo.Mpdn.VideoPlayer.ICallbackFilterCB.SampleCb(Int64, DirectShowLib.IMediaSample)
DomainBoundILStubClass.IL_STUB_COMtoCLR(Int64, IntPtr)
-------------------------------------------------------------------------------------------
ryrynz
28th May 2015, 01:01
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.
I've just done a number of comparisons on fairly red scenes and the changes are made on edges mostly. I've found the changes on either brownish or whiteish edges/areas, but yeah the changes are very subtle.. most of the time you actually won't notice them.
Zachs
28th May 2015, 01:06
Ah ha! I found it there. Here is the dump which I opened and copied from Notepad:
Right. Just as I feared.
I'll continue this in PM with you since it looks like it's specific to your Optimus system only.
ryrynz
28th May 2015, 01:29
but yeah the changes are very subtle.. most of the time you actually won't notice them.
This is the best example of the changes chroma reconstruction makes I've seen so far. The changes are certainly more noticeable with sharper resizers (lanczos, NNEDI3) These were taken using Lanzcos 16 tap AR.
The whites really do lighten up here, probably one of the best examples I could have hoped to find as all other changes have been relatively minor.
http://screenshotcomparison.com/comparison/128955
so it tries to counter the tons of artifacts from lanczos 8/16?
Zachs
28th May 2015, 01:45
No. It uses the information that would've otherwise been disposed off so it gives better quality.
No. It uses the information that would've otherwise been disposed off so it gives better quality.
why is lanczos 16 is needed than to show something off there must be better examples.
Zachs
28th May 2015, 01:57
Lanczos 16 causes more values to go out of range after scaling so the effect is more profound.
Zachs
28th May 2015, 02:07
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.
Righto! I found a bug in MPDN's automatic colorimetric detection logic! Specifically if the 720p clip doesn't have actual a height of 720 pixels, it assumes it's not HD!
This has been fixed in the next release.
Many thanks to ryrynz for discovering this.
does it work with RGB sources or 4.4:4 source?
here an extreme example:
http://screenshotcomparison.com/comparison/128957
i crippled a RGB source to 4:2:0 to make it work.
it turns some pixel totally black that shouldn't be black but i guess it gives an idea what it does.
Zachs
28th May 2015, 02:23
Depending on how you're scaling your chroma. If you scale it to target size directly with something like lanczos 16 then it may have some effect. I suspect you won't be able to see any difference but I haven't tested this myself.
Zachs
28th May 2015, 02:25
here an extreme example:
http://screenshotcomparison.com/comparison/128957
i crippled a RGB source to 4:2:0 to make it work.
it turns some pixel totally black that shouldn't be black but i guess it gives an idea what it does.
Is your RGB source closer to CR on or off?
EDIT: If you look closely at the disabled icons on the sidebar, you'll find CR on to do exactly what was intended to. There's no colour bleed at all and it shows a clear alternating pattern that I would image what the original looked like.
Is your RGB source closer to CR on or off?
yes and no.
the luma is closer the chroma is way off with CR on
EDIT: let me say it with other more correct words.
it removes chroma bleeding and under saturates chroma. most parts where chroma details shouldn't by they are not there anymore so the "luma" looks way more correct.
Zachs
28th May 2015, 02:37
Well it's done its job then!
But can you post the RGB and crippled version of that clip somewhere so we could take a look at it to see if we could improve it?
ryrynz
28th May 2015, 02:38
Hey Huhn can you link the 4:2:0 and the RGB source? I think that might be useful for tweaking chroma.
I guess ideally I'd really like to get my hands on a proper chroma test pattern to compare in that way to find accurate to the source chroma upscaler settings.
here is the RGB version.
http://www.file-upload.net/download-10648434/schweif_000-001.mkv.html
i forced lavfilter to NV12 output to get a 4:2:0 video of this so i don't have an encode of it.
but not sure if a normal video should be judge on a pixel art video like this.
Zachs
28th May 2015, 02:45
The same principal applies to normal video - chroma bleed is never desirable.
but who good is the studio downscaler compared to lavfilters?
Zachs
28th May 2015, 02:56
The problem there is the crippled chroma is just that - no 'good studio downscaler' exists that could 'retain' that information because it just isn't there - it had to be chucked out. If there's such a thing, then all we need for image upscaling would be nearest neighbour and hope that all downscalers are 'good studio downscalers'.
The problem there is the crippled chroma is just that - no 'good studio downscaler' exists that could 'retain' that information because it just isn't there - it had to be chucked out. If there's such a thing, then all we need for image upscaling would be nearest neighbour and hope that all downscalers are 'good studio downscalers'.
i don't say your idea is wrong in general or bad at all. no it does a very good job on this source with some major artifacts for now.
just look at the eyes they are black again like they should be.
i just say it shouldn't be judge on a source that is nearly for sure downscaled with bilinear and a pixel art game.
it very interesting to see that black pixels are really good reconstructed but white pixels not "at all".
Zachs
28th May 2015, 03:15
it very interesting to see that black pixels are really good reconstructed but white pixels not "at all".
Not sure I understand what you're saying. Care to explain further?
Shiandow
28th May 2015, 03:16
yes and no.
the luma is closer the chroma is way off with CR on
EDIT: let me say it with other more correct words.
it removes chroma bleeding and under saturates chroma. most parts where chroma details shouldn't by they are not there anymore so the "luma" looks way more correct.
In theory SuperChromaRes should add the removed chroma back in again, at least partially.
ryrynz
28th May 2015, 03:23
Hey huhn when looking at the video you posted I'm not seeing that same image quality you posted as the CR off image..
With your image if you look at the inside of the wizards sleeves, it's brown rather than black, also the third square under the mountains the blue sky has bleeding.
How did you get that to happen? My results are quite different.
http://i.imgur.com/z4mTT1Rm.png (http://i.imgur.com/z4mTT1R.png) (bicubic 100 AR used for luma and chroma)
Not sure I understand what you're saying. Care to explain further?
this is what i mean.
1 RGB
2 reconstructed
3 normal
http://abload.de/img/rgbg4j01.png
the eye white is still totally gone but the black part is a lot better with your algo.
i'm way over my english limited here.
In theory SuperChromaRes should add the removed chroma back in again, at least partially.
i didn't compared them. i just wanted to show the effect and the source did a good job on this.
if your superres can do this in the same or better way feel free to show that. source is linked
Hey huhn when looking at the video you posted I'm not seeing that same image quality you posted as the CR off image..
Look at the inside of the wizards sleeves, it's brown rather than black, also the third square under the mountains the blue sky has bleeding.
How did you get that to happen?
http://imgur.com/z4mTT1R
i had a 3D LUT load that has something to do with the black level.
but this should be the last part of the chain so it should affect the algo.
don't forget the source you have is RGB you have to force lavfilter to use nv12 as output by disabling all other formates this looks clearly like RGB input.
your gamma is way higher than on my screenshot even without 3D LUT.
i used spline 6 not sure anymore.
Zachs
28th May 2015, 03:43
Oh 3DLUT does affect your screen capture - how could it not?
Zachs
28th May 2015, 03:45
if your superres can do this in the same or better way feel free to show that. source is linked
Shiandow knows what he's talking about as always. He created the algo!
Oh 3DLUT does affect your screen capture - how could it not?
it doesn't alter the algorithm not the picture it self.
of cause it remaps the colors.
it's like using bt 601 on a bt 701 source at the end your algorithm doesn't care.
Zachs
28th May 2015, 03:47
it doesn't alter the algorithm not the picture it self.
of cause it remaps the colors.
it's like using bt 601 on a bt 701 source at the end your algorithm doesn't care.
I meant that'll probably account for the brown on your screen capture vs ryrynz's black.
ryrynz
28th May 2015, 03:48
I meant that'll probably account for the brown on your screen capture vs ryrynz's black.
Yup, my thoughts exactly.
Anime Viewer
28th May 2015, 03:56
Righto! I found a bug in MPDN's automatic colorimetric detection logic! Specifically if the 720p clip doesn't have actual a height of 720 pixels, it assumes it's not HD!
This has been fixed in the next release.
Many thanks to ryrynz for discovering this.
Interesting...I'll look forward to testing it out in the next release. I wasn't crazy about having the Video Input Colormetric forced to a setting, and would prefer to leave it at automatic (as long as it can detect the video properly). The video mis-detections weren't limited to 720p clips in my testing. I was seeing it in 480 videos as well. Two of those was reported as video 848x480 with it reporting a target rectangle of 853x480 in its default window, and of course 1920x1080 for target when I expanded it to full screen. (The video I posted screen shot(s) of was of those dimensions).
Did you test other video resolutions beside 720p for that same type of bug?
ok i see what you mean but this is the result i get with EVR CP.
http://abload.de/img/evrcp4aoa0.png
totally different from ryrynz
ryrynz
28th May 2015, 03:58
Here's a comparison (http://screenshotcomparison.com/comparison/128966) of CR off vs CR on with that output via NV12.
The significant changes are in the blue pixelated area in the third square under the hills (loses a lot of blue bleeding) and artefcats that are now visable around the clouds in the sky with the hills.
ryrynz
28th May 2015, 04:01
ok i see what you mean but this is the result i get with EVR CP.
http://abload.de/img/evrcp4aoa0.png
totally different from ryrynz
Your screenshot is a different size, but looks almost identical to my shot with CR off above.
Zachs
28th May 2015, 04:01
Interesting...I'll look forward to testing it out in the next release. I wasn't crazy about having the Video Input Colormetric forced to a setting, and would prefer to leave it at automatic (as long as it can detect the video properly). The video mis-detections weren't limited to 720p clips in my testing. I was seeing it in 480 videos as well. Two of those was reported as video 848x480 with it reporting a target rectangle of 853x480 in its default window, and of course 1920x1080 when I expanded it to full screen. (The video I posted screen shot(s) of was of those dimensions).
Did you test other video resolutions beside 720p for that same type of bug?
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.
madshi
28th May 2015, 09:13
Just wondering: Is there a specific reason why "Improve Chroma Reconstruction" is available as a separate option in addition to also being part of SuperChromaRes?
FWIW, I had experimented with a similar algo some time ago but removed it again because it produced artifacts with some sources. @Shiandow, did you find a way to get rid of those artifacts in your SuperChromaRes shader?
Zachs
28th May 2015, 09:24
So long as your yuv matrix is correct, I have yet to find a clip that shows any artefacts. I've tested over 50 clips so far. Trouble is a lot of them don't say they're using PC range when encoded as such!
nevcairiel
28th May 2015, 09:26
So long as your yuv matrix is correct, I have yet to find a clip that shows any artefacts. I've tested over 50 clips so far. Trouble is a lot of them don't say they're using PC range when encoded as such!
Just because a clip uses out-of-range chroma values doesn't mean its actually supposed to be PC range. Sometimes its just the way it is, same reason BTB and WTW are a thing.
Actual PC range content is very rare, practically only exist in video game recordings and things similar to that.
Zachs
28th May 2015, 10:59
How would you be able to tell one from the other? Wouldn't a BTB / WTW source look exactly like it's using PC ranges? In which case, we are back to square one, which is how do we tell one apart from the other?
madshi
28th May 2015, 11:16
BTB/WTW values can occur even if the source is limited range. E.g. ringing (due to scaling or sharpening) can cause that. I've also seen one authoring guy writing on some forum saying that he had to use some BTB values on some DVD encoding to make the color look "right". Then there are also some broadcasts where there's no BTB content, but some WTW data... :(
Shiandow
28th May 2015, 11:42
Just wondering: Is there a specific reason why "Improve Chroma Reconstruction" is available as a separate option in addition to also being part of SuperChromaRes?
FWIW, I had experimented with a similar algo some time ago but removed it again because it produced artifacts with some sources. @Shiandow, did you find a way to get rid of those artifacts in your SuperChromaRes shader?
Well I did find a way to remove some of them, but unfortunately not all of them. Some sources seem to want values that are not just a little impossible, but entirely impossible. There might be ways to lessen the artefacts, but I'm not sure if there's a way that doesn't look weird with at least some sources.
Zachs
28th May 2015, 11:55
BTB/WTW values can occur even if the source is limited range. E.g. ringing (due to scaling or sharpening) can cause that. I've also seen one authoring guy writing on some forum saying that he had to use some BTB values on some DVD encoding to make the color look "right". Then there are also some broadcasts where there's no BTB content, but some WTW data... :(
Ouch. These non standard encodes using btb/wtw are quite troublesome as they contain no additional info on their metadata as to whether they're actually using them. That's no different to chroma offset.
Anyway it's an option that's disabled by default with a warning that says not all sources are compatible. If they follow the standards strictly then there would be no problem enabling the option.
Those sources that use btb/wtw really have to be considered broken. I mean, how would they expect standard of the shelf set top boxes to handle the contents correctly when sophisticated software are missing info to decode them?
Here's a comparison (http://screenshotcomparison.com/comparison/128966) of CR off vs CR on with that output via NV12.
The significant changes are in the blue pixelated area in the third square under the hills (loses a lot of blue bleeding) and artefcats that are now visable around the clouds in the sky with the hills.
input is 16 bit 4:4:4 not 8 bit 4:2:0.
that's why the effect is so little
nevcairiel
28th May 2015, 12:04
Those sources that use btb/wtw really have to be considered broken. I mean, how would they expect standard of the shelf set top boxes to handle the contents correctly when sophisticated software are missing info to decode them?
They decode just fine. Its your "sophisticated" extra algorithms that barf up on them. A simple decode and RGB conversion will just clip the extra values and they look and feel just fine.
BTB and WTW is more common than you might think, and I don't think simply calling it broken is a solution.
There is a reason why any YUV->RGB conversion formula includes a clipping step.. :)
PS:
xvYCC is a Blu-ray standard that encodes extended color ranges in the "out of range" chroma values.
They decode just fine. Its your "sophisticated" extra algorithms that barf up on them. A simple decode and RGB conversion will just clip the extra values and they look and feel just fine.
i usually make the player clear that this file is PC range.
of cause i'm talking about a source with full PC range not some WTW parts no one will ever miss.
Zachs
28th May 2015, 12:08
Yeah I guess that makes sense.
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? If we don't, and simply assume they are TV ranges then they're always going to be blown out with their whites and the opposite with their blacks. In the office, we have some IP cameras that record using those btb/wtw ranges but report they are encoding in TV range. These are expensive hardware from renown companies which I won't name, but they don't appear to care that they aren't recording in the range they're told. Needless to say the recordings need manual matrix override.
I'll stand by what I said earlier - so long as the matrix is set correctly, improve chroma reconstruction should work just fine. If you have some materials that would prove otherwise, I'd love to give it a go.
Shiandow
28th May 2015, 13:38
They decode just fine. Its your "sophisticated" extra algorithms that barf up on them. A simple decode and RGB conversion will just clip the extra values and they look and feel just fine.
BTB and WTW is more common than you might think, and I don't think simply calling it broken is a solution.
There is a reason why any YUV->RGB conversion formula includes a clipping step.. :)
All "Improve Chroma Reconstruction" is is just a different way of clipping those values. It tries to make sure that the luma remains correct. Of course some sources insist on making parts of the image simultaneously black and bright red, which doesn't work well.
Anime Viewer
28th May 2015, 13:46
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
28th May 2015, 13:49
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
28th May 2015, 14:03
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
28th May 2015, 14:03
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
28th May 2015, 14:07
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.
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
28th May 2015, 14:12
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
28th May 2015, 14:14
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
28th May 2015, 14:20
And "Ctrl+Shift+M" to toggle BT 709, 601, 2020.
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
28th May 2015, 14:24
Works fine for me... each time you press the hotkeys you get a different range right?
Zachs
28th May 2015, 14:27
That's odd. Is yours working Shiandow?
Anime Viewer
28th May 2015, 14:37
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
28th May 2015, 14:39
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?
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
28th May 2015, 15:19
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.
i use x64 2.27.0.3100 with extensions 1.0.3 and it clearly doesn't work.
Zachs
29th May 2015, 01:24
@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
29th May 2015, 02:37
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
29th May 2015, 02:48
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
29th May 2015, 03:12
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
29th May 2015, 06:08
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
29th May 2015, 06:35
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
29th May 2015, 07:45
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 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
29th May 2015, 14:08
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.
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
29th May 2015, 16:04
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
30th May 2015, 08:06
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
30th May 2015, 10:41
With the latest version? Might've been something to do with the Optimus bug I fixed.
Zachs
30th May 2015, 11:33
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
30th May 2015, 13:36
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?
Blackfyre
31st May 2015, 12:14
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.
have you done a test with openCL?
most people prefer 13.12 there.
nevcairiel
31st May 2015, 13:39
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
31st May 2015, 14:32
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
1st June 2015, 05:49
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
1st June 2015, 06:06
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
1st June 2015, 13:33
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
2nd June 2015, 01:54
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
2nd June 2015, 03:03
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
3rd June 2015, 06:11
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
3rd June 2015, 12:36
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
3rd June 2015, 13:08
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
3rd June 2015, 13:10
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!
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
3rd June 2015, 13:19
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.
burfadel
3rd June 2015, 14:13
EDIT: Fixed in v2.29.1.
Thanks, works well now!
Zachs
4th June 2015, 06:48
Hi guys,
Just a quick heads up - there's a new MPDN Extensions release (v1.2.0).
Changes:
- Removed conditional usage option for ImageProcessor (use the Conditional script instead)
- Added script editor for ImageProcessor
- Conditional script revamped (note: you may need to delete your config folder if you encounter an error)
- Conditional no longer loads from Script Group's preset - it now allows you to select from a list of render scripts
foxyshadis
4th June 2015, 12:32
I get this error with the new extension pack:
===================================
c:\av\MPDN\Extensions\RenderScripts\Mpdn.ScriptedRenderChain.MpdnScriptEngine.cs(33,21): error CS0104: 'ScriptEngine' is an ambiguous reference between 'Microsoft.ClearScript.ScriptEngine' and 'Mpdn.Extensions.Framework.ScriptEngine'
c:\av\MPDN\Extensions\RenderScripts\Mpdn.ScriptedRenderChain.MpdnScriptEngine.cs(122,46): error CS0246: The type or namespace name 'Clip' could not be found (are you missing a using directive or an assembly reference?)
(CSScriptLibrary)
------------------------------
Program Location:
at csscript.CSExecutor.ProcessCompilingResult(CompilerResults results, CompilerParameters compilerParams, ScriptParser parser, String scriptFileName, String assemblyFileName, String[] additionalDependencies)
at csscript.CSExecutor.Compile(String scriptFileName)
at CSScriptLibrary.CSScript.LoadWithConfig(String scriptFile, String assemblyFile, Boolean debugBuild, Settings scriptSettings, String compilerOptions, String[] refAssemblies)
at CSScriptLibrary.CSScript.Load(String scriptFile, String assemblyFile, Boolean debugBuild, String[] refAssemblies)
at MediaPlayerDotNet.CsScript.†††
†††–(Object , Object , Boolean , Object )
at MediaPlayerDotNet.CsScript.†††
††††‡ť(Object , Object , Boolean )
at MediaPlayerDotNet.CsScript.†††
††††‡(Object , Object , Object , Object , Object )
at MediaPlayerDotNet.CsScript.LoadScripts(String scriptDir)
at MediaPlayerDotNet.MainForm.†††
†††‡‰™()
Sorry about the garbage, must be the lack of symbols.
Zachs
4th June 2015, 12:41
You didn't remove the old extension files, did you? :)
foxyshadis
4th June 2015, 12:47
Ah, should have noticed the datestamp. Looks like things have changed a LOT in the last few days, much more broken out. At least my little extensions still work!
Zachs
4th June 2015, 12:48
Oh what extension is that if you don't mind me asking?
ryrynz
4th June 2015, 14:13
Ah, should have noticed the datestamp. Looks like things have changed a LOT in the last few days, much more broken out. At least my little extensions still work!
I sometimes wish there was an installer that took care of everything for me lazy style.. I think I might just write a batch file to hose the MPDN config and install directory as well as extract out the ZIP.
Seems like more often than not I have to do one or the other or both.
Hey Zach any chance of an option for storing the application config in the registry?
Zachs
4th June 2015, 14:25
I sometimes wish there was an installer that took care of everything for me lazy style.. I think I might just write a batch file to hose the MPDN config and install directory as well as extract out the ZIP.
Seems like more often than not I have to do one or the other or both.
Hey Zach any chance of an option for storing the application config in the registry?
Nope. Registry should never be used to store app settings. That's what the app data folder is for.
stax76
4th June 2015, 15:44
Nope. Registry should never be used to store app settings. That's what the app data folder is for.
I agree but where I don't agree is startup time is the single most important feature for a player. Currently it feels like 2 seconds, I believe 150 ms is even for a .NET player possible. Obviously it's not doable loading twenty assemblies before playback starts or deserializing or parsing large files.
Shiandow
4th June 2015, 15:50
I agree but where I don't agree is startup time is the single most important feature for a player. Currently it feels like 2 seconds, I believe 150 ms is even for a .NET player possible. Obviously it's not doable loading twenty assemblies before playback starts or deserializing or parsing large files.
Does loading time improve if you delete the settings folder?
stax76
4th June 2015, 16:15
Does loading time improve if you delete the settings folder?
I tried it a few days ago with a fresh setup.
Belphemur
4th June 2015, 19:58
I sometimes wish there was an installer that took care of everything for me lazy style.. I think I might just write a batch file to hose the MPDN config and install directory as well as extract out the ZIP.
Seems like more often than not I have to do one or the other or both.
Hey Zach any chance of an option for storing the application config in the registry?
Could you describe what you would want in the installer of MPDN ?
For now the installer is taking care of removing the content of the Extensions to avoid any problem. And when uninstalling you can ask it to remove all the configuration.
Magik Mark
5th June 2015, 02:12
Zachs
Is there a way to make switching to FSE faster? It takes me around 3 seconds. Comparing it with MPC BE with madvr it only takes 1 second to switch back and forth between windows mode & FSE
Thanks
ryrynz
5th June 2015, 03:07
Zachs
Is there a way to make switching to FSE faster?
Thanks
What d3d version you using and what card / driver? I don't have any issues with performance here personally.
Magik Mark
5th June 2015, 03:26
What d3d version you using and what card / driver? I don't have any issues with performance here personally.
D3D 11 GTX 550Ti Driver 353.06
Zachs
5th June 2015, 03:58
Takes less than half a second for my 560gtx. 1 second is painfully slow.
Magik Mark
5th June 2015, 04:13
Takes less than half a second for my 560gtx. 1 second is painfully slow.
Is there something I could Tweak? I was just wondering why its a lot faster in mpcbe with madvr
ryrynz
5th June 2015, 05:46
Is there something I could Tweak? I was just wondering why its a lot faster in mpcbe with madvr
Perform a clean install of that driver and test d3d 10 and 9 and report if it's the same speed as 11.
Zachs
5th June 2015, 13:06
I agree but where I don't agree is startup time is the single most important feature for a player. Currently it feels like 2 seconds, I believe 150 ms is even for a .NET player possible. Obviously it's not doable loading twenty assemblies before playback starts or deserializing or parsing large files.
Not sure how saving and loading from the registry is going to make things any faster though?
ryrynz
5th June 2015, 13:45
I agree but where I don't agree is startup time is the single most important feature for a player. Currently it feels like 2 seconds, I believe 150 ms is even for a .NET player possible. Obviously it's not doable loading twenty assemblies before playback starts or deserializing or parsing large files.
Only reason I said it was so if I nuked the install directory the settings would still be remembered, but I'll just rely on the installer from now on.
It certainly wouldn't make any difference with regards to loading times. Yeah about two seconds on my machine too (currently using a HDD on this one) It's not too bad really.
Could you describe what you would want in the installer of MPDN ?
It's fine. I was using the zip, I didn't realize the installer deleted the extensions first.
stax76
5th June 2015, 14:30
I just take a look at StaxRip on what feels slow, take a look what could be optimized and use a class called stopwatch to find bottlenecks from time to time, binary deserialization takes most time in my case, I have room for optimization but really don't have a need since the startup is still very fast. What takes most time in your case can easily be measured. I've extended many applications with mostly personal scripts and add-ons, Firefox, MediaMonkey, DVBViewer, Windows Explorer, VisualStudio. Some of this apps are on the slow side but it's mostly acceptable considering the amount of powerful features. For a media player however the fastest possible startup time is crucial for me, for others it's probably not so important. I use MPC and VLC sometimes but most of the time when I don't have special needs like subtitles I use a personal player built with VB.NET with special behavior hard coded, the code for a old version is still available here (https://sourceforge.net/p/staxmedia/code/HEAD/tree/trunk/StaxPlayer/). It's using winforms and a WPF window for OSD but that was crashing on Win10 so I'm currently implementing OSD with EVR. It's somehow unfortunate that there isn't a player yet I like, I looked at all in detail, unfortunately I have to say I'm not impressed by most, they can all still be improved and I could contribute but I'm mostly fine with my personal player and occasionally MPC and VLC. Sorry about the rant, just that it's not for me doesn't mean that it's bad. :)
Keiyakusha
5th June 2015, 15:40
huh, startup time? I never noticed before you mentioned. And now that I did and measured for myself, I still fail to see how it matters. You probably don't know what is slow, MPDN is like 3 times faster than Photoshop, haha ^_^ But seriously, I can understand why for example slow FSE switching can be annoying (I'm not saying it is slow, I don't use it myself) but startup time is just a unnecessary nitpick.
acceptable considering the amount of powerful features
Isn't MPDN falls into this category too? I hope by "powerful" you don't mean stuff like additional internal filters, 1001 old renderer to select for no reason, encoding capabilities and other bloat, some other players may have.
stax76
5th June 2015, 16:02
Startup time is not a concern for everybody, too me it's very important. With powerful I mean applications you need minimum 10 years to build.
Keiyakusha
5th June 2015, 16:17
I understand your point, however I want to contest the following statement too. I hope its not too much offtopic.
With powerful I mean applications you need minimum 10 years to build.
No application or even OS needs this much time to build. For some of them it takes this much time, or even more but only because they are changing all the time. With this respect, some of the software will never be completed.
For some windows players it took around 12 years to get them where they are now. Are they more powerful than MPDN? Highly debatable I should say. Shouldn't we be saying quite the opposite thing, that it is OK for MPDN to have slower startup because it got this powerful with this short amount of time?
foxyshadis
6th June 2015, 12:30
Quick question: With the new Conditionals, can I use the other Renderer properties as well, like InputFormat? Turning off debanding for P010 and Y410 would be useful, I rarely if ever need it for 10-bit vids.
Zachs
6th June 2015, 13:22
Quick question: With the new Conditionals, can I use the other Renderer properties as well, like InputFormat? Turning off debanding for P010 and Y410 would be useful, I rarely if ever need it for 10-bit vids.
InputFormat isn't accessible yet but it's very easy to add to the Clip class. It's a one liner. I'll add that in there when I get the chance but if you can figure out where and how to add it then fell free to propose a git merge.
EDIT: Rather than exporting InputFormat, I'd prefer it to be a simple int property called 'SourceBitDepth'.
Zachs
6th June 2015, 15:33
v2.29.2 without extensions now startup (fully usable) in less than 1s.
Takes an additional 1s if you have extensions installed. It should be a non-issue now even for the pedantic users.
I prefer human readable text based XML serialization and will never go for binary serialization where app settings are concerned. I'd rather sacrifice a bit of startup time.
MPC-HC starts up much faster than MPDN but opening a media file when madVR loads the first time is hell of a lot slower. When MPDN starts up, its renderer is already fully loaded and initialized.
madshi
6th June 2015, 15:56
MPC-HC starts up much faster than MPDN but opening a media file when madVR loads the first time is hell of a lot slower.
Depends on the selected algorithms, though. E.g. when using OpenCL stuff, madVR doesn't start rendering until OpenCL is initialized, the kernels are compiled etc. That's on my to do list to improve. If you don't use any OpenCL or DirectCompute stuff, MPC-HC/madVR should start rendering without much delay. But that can probably still be improved a bit, too. There's always something that can be further optimized... :)
madVR/mpc-hc can present a frame in less than a couple 100 ms.
it is nearly instant when the file is on a sdd the bottle neck is clearly the HDD these days.
i tested mpdn 2.29.2.3117 without extensions it is a clearly slower than madVR/mpc-hc. but the difference is meaningless to me.
stax76
6th June 2015, 16:58
v2.29.2 without extensions now startup (fully usable) in less than 1s.
Takes an additional 1s if you have extensions installed. It should be a non-issue now even for the pedantic users.
I prefer human readable text based XML serialization and will never go for binary serialization where app settings are concerned. I'd rather sacrifice a bit of startup time.
MPC-HC starts up much faster than MPDN but opening a media file when madVR loads the first time is hell of a lot slower. When MPDN starts up, its renderer is already fully loaded and initialized.
Did you measure how long the completely deserialization takes? StaxRip was VBScript -> VB6 -> .NET 1.0 so I'm using binary serialization since .NET 1.0, the reason was if I remember right ease of use and flexibility, since .NET 1.0 binary serialization was significant improved giving even more flexibility, XML serialization was surely improved too, I don't know how both compare today, binary serialization allows you to serialize any object graph no matter how complex it is with little effort, you can serialize practically everything, all you need to do is adding SerializableAttribute to classes and take care of versioning for which various customizations are available.
What you can do to speed up serialization is serialize only values that are different from the default value and you can split things up to several files and use lazy loading.
I'm impressed how fast SharpDevelop 4.4 starts considering it's a huge WPF application with addin support, it's start practically instantly, I'm using it to translate C# to VB.NET which works incredibly well.
You can also soon use the brand new x64 JIT compiler RyuJIT:
Microsoft’s next generation just-in-time compiler for .NET, RyuJIT, is now the default compiler for 64-bit applications on .NET 4.6., if you have installed VS2015 Preview or newer, RyuJIT will be enabled.
I don't know when the final ships, probably with Win10 so pretty soon.
Zachs
6th June 2015, 23:28
The bulk of the time isn't in serialisation. That said, why are we still having this conversation? Is it still too slow for you when it starts in less than 1s without the extensions?
Zachs
6th June 2015, 23:36
Depends on the selected algorithms, though. E.g. when using OpenCL stuff, madVR doesn't start rendering until OpenCL is initialized, the kernels are compiled etc. That's on my to do list to improve. If you don't use any OpenCL or DirectCompute stuff, MPC-HC/madVR should start rendering without much delay. But that can probably still be improved a bit, too. There's always something that can be further optimized... :)
When I last tested it, first time I open a media file it feels like madvr DLL only gets loaded then. It took around 2-3 seconds before playback starts and that's with just hardware bilinear. Subsequent playback was a lot faster though.
Anyway it's a little out of topic for this thread.
ryrynz
7th June 2015, 14:03
Could you describe what you would want in the installer of MPDN ?
For the uninstaller to remember the directory I installed to, uninstall from that directory and for it to reference it in it's dialogue box. The Installer would also offer to reinstall to that directory by default.
Anime Viewer
8th June 2015, 00:45
Lately I seem to be encountering quite a bit of shuddering/jerky playback (with Fluid Motion on) on certain types of videos. Especially on horizontally panning scenes. Anyone one else have similar experiences on videos with the properties listed below?
From MPDN Media Info:
Video
ID : 1
Format : AVC
Format profile : Main@L3.1
Format settings : CABAC / 6 Ref Frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1417251
Bit rate : 0
Width : 848
Height : 480
Display aspect ratio : 1.006
Frame rate mode : CFR
Frame rate : 23.976
Chroma subsampling : 4:2:0
Bit depth : 8
Scan type : Progressive
Bits/(Pixel*Frame) : 0
Stream size :
Writing library : x264 - core 120 r2120 0c7dab9
Encoding settings : cabac=1 / ref=6 / deblock=1:1:1 / analyse=0x1:0x111 / me=umh
/ subme=8 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 /
trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 /
threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 /
constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 /
weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 /
intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=768 / ratetol=1.0 /
qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 /
vbv_maxrate=1536 / vbv_bufsize=3840 / nal_hrd=none / ip_ratio=1.40 / aq=1:0.60
Language :
Audio
ID : 2
Format : AAC
Codec ID : A_AAC
Duration : 1417252
Bit rate mode :
Bit rate : 0
Channel(s) : 2
Sampling rate : 44100
Bit depth : 0
Compression mode : Lossy
Stream size : 0
Language :
Subtitle
ID : 3
Format : ASS
Muxing Mode :
Codec ID : S_TEXT/ASS
Language :
Edit: It seems Fluid Motion was actually causing the problem (or was related in some way to it) (and was constantly flashing on and off in OSD). Disabling it resolved the issue (it appears).
CTRL+J shows: (When Fluid motion is turned off)
Dispay 59.824999Hz
Video frame rate
23.976Hz (says source filter)
23.972Hz (avg last 2s) (seems to fluxuate between 23.9 and 23.7)
23.97625Hz (ref clock)
Render Queue 12/12
Render speeds ~ 19.04ms
CTRL+J shows: (When Fluid Motion is on and fluctuating)
Display 59.82501 Hz
Video frame rate
23.976Hz (source filter)
16.012Hz (avg last 2s) (also goes down to 14)
23.97618Hz (ref clock)
Render Queue 0/12
tons of dropped and delayed frames
Render speeds ~ 61.73ms
ryrynz
8th June 2015, 05:57
Lately I seem to be encountering quite a bit of shuddering/jerky playback (with Fluid Motion on) on certain types of videos. Especially on horizontally panning scenes. Anyone one else have similar experiences
I've encountered this too, I wasn't sure what it was related to. I did some testing last night but didn't encounter it though. I have been getting the odd delayed and dropped frame but it seems somewhat random, just when I think I got it what's causing it a retest proves me wrong.
Zachs
8th June 2015, 06:30
Hint: Render duration 61.73ms. Your source is 23.976fps.
Anime Viewer
8th June 2015, 07:09
Hint: Render duration 61.73ms. Your source is 23.976fps.
I know the render duration being so high is why the dropped frames occur, but it would seem that is the effect of something else (my current best guess is the Fluid Motion flashing on and off constantly instead of remaining in one state or the other). Fluid Motion isn't so taxing that it should more than triple render times compared to when it is switched off. I get the impression that Fluid Motion isn't correctly detecting what state it should be in, and so it is continually triggered on and off.
ryrynz,
Have you noticed it with particular types of files (for example the 23.976 source files)? If you go to the MPDN Media Info area does it list CFR for the frame rate mode of the video(s) you see issue with?
I'm not sure how to interpret the report of the frame rates for the (last 2s) part. That being under the source and screen Hz is obviously an issue, but is it causing the other issue(s) or is it a result of the other issue(s). Could a low frame rate trigger Fluid Motion to switch on, and then when the frame rate increases Fluid Motion feels its no longer needed (and thus switches off), then when its detected as dropping again it switches on again, and thus a continual loop of switching on and off?
Chicken or the Egg which came first?
Zachs
8th June 2015, 12:47
The only time it will get switched off in your case would be render queue dropping under 2. For some reason it's causing such high render time when it's on.
FWIW I ran fluid motion on an old laptop with AMD mobility x2300 and the difference was around 2ms between on and off. That GPU doesn't even have a certified Windows 8.1 drivers. Does it only happen with one particular file?
Anime Viewer
8th June 2015, 13:29
The only time it will get switched off in your case would be render queue dropping under 2. For some reason it's causing such high render time when it's on.
FWIW I ran fluid motion on an old laptop with AMD mobility x2300 and the difference was around 2ms between on and off. That GPU doesn't even have a certified Windows 8.1 drivers. Does it only happen with one particular file?
No I've had it happen with more than one particular file. Like ryrynz mentioned it doesn't happen every time one of the files that has the problem is launched. Today when I launched that same file (as yesterday) it didn't have the problem occur. Other currently unknown variables are involved. When it happened yesterday it had just switched from playing one file in fullscreen mode to one of the problematic files that was on the playlist. I think the problematic file was third on the playlist. The second file on the playlist is always skipped after the first is played, so I thought that (or it switching from one file in fullscreen mode to another in fullscreen mode) might be related to the problem, but trying to repeat the same situation has failed to trigger the issue (in other words it wasn't switching fluid motion on and off continually). I'll continue experimenting, and report back if I can find a common variable when it is triggering.
Edit: I got it to occur again this time with other files. It started occuring after I went in and changed a setting in Fluid Motion. Specifically I went in and unchecked Only when video frame is less than half of display rate. The properties of the other two files I'm seeing it occur on are:
Video
ID : 1
Format : AVC
Format profile : Main@L3.1
Format settings : CABAC / 6 Ref Frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1435185
Bit rate : 0
Width : 848
Height : 480
Display aspect ratio : 1.006
Frame rate mode : CFR
Frame rate : 23.976
Chroma subsampling : 4:2:0
Bit depth : 8
Scan type : Progressive
Bits/(Pixel*Frame) : 0
Stream size :
Writing library : x264 - core 120 r2120 0c7dab9
Encoding settings : cabac=1 / ref=6 / deblock=1:1:1 / analyse=0x1:0x111 / me=umh
/ subme=8 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 /
trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 /
threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 /
constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 /
weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 /
intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=768 / ratetol=1.0 /
qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 /
vbv_maxrate=1536 / vbv_bufsize=3840 / nal_hrd=none / ip_ratio=1.40 / aq=1:0.60
Language :
Audio
ID : 2
Format : AAC
Codec ID : A_AAC
Duration : 1435179
Bit rate mode :
Bit rate : 0
Channel(s) : 2
Sampling rate : 44100
Bit depth : 0
Compression mode : Lossy
Stream size : 0
Language :
Subtitle
ID : 3
Format : ASS
Muxing Mode :
Codec ID : S_TEXT/ASS
Language :
and
Video
ID : 1
Format : AVC
Format profile : Main@L3.1
Format settings : CABAC / 6 Ref Frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1452244
Bit rate : 0
Width : 848
Height : 480
Display aspect ratio : 1.006
Frame rate mode : CFR
Frame rate : 23.976
Chroma subsampling : 4:2:0
Bit depth : 8
Scan type : Progressive
Bits/(Pixel*Frame) : 0
Stream size :
Writing library : x264 - core 120 r2120 0c7dab9
Encoding settings : cabac=1 / ref=6 / deblock=1:1:1 / analyse=0x1:0x111 / me=umh /
subme=8 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 /
trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 /
threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 /
constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 /
weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 /
intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=768 / ratetol=1.0 /
qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 /
vbv_maxrate=1536 / vbv_bufsize=3840 / nal_hrd=none / ip_ratio=1.40 / aq=1:0.60
Language :
Audio
ID : 2
Format : AAC
Codec ID : A_AAC
Duration : 1452244
Bit rate mode :
Bit rate : 0
Channel(s) : 2
Sampling rate : 44100
Bit depth : 0
Compression mode : Lossy
Stream size : 0
Language :
Subtitle
ID : 3
Format : ASS
Muxing Mode :
Codec ID : S_TEXT/ASS
Language :
Both of those files seem to have similar properties.
It is not occurring when running in the video's native window size. Only during fullscreen (I'm testing to see if it is FSE or FSE D3D 11 related).
Edit #2:
I didn't encounter it in D3D 11 Fullscreen Windowed mode, but then I also didn't encounter it after switching back to D3D 11 FSE mode either...
When the issue has occurred I'd also been running in "Multiple displays: Extend these displays mode", but I'm not sure if that has any barring. Next time it occurs I'll try switching to single display mode to see if that may be a factor.
Edit #3: When it reoccurred again I switched to single display, and D3D 11 Windowed Fullscreen, and Fluid Motion continued to switch on and off.
ryrynz
8th June 2015, 13:44
No I've had it happen with more than one particular file.
Could be wrong but I think it has something to do with switching between fullscreen and windowed modes.
Garteal
8th June 2015, 16:10
Anime Viewer: Are you using the latest playlist? That should've been fixed a long time ago unless something broke again.
Also what's your Render Script queue?
Anime Viewer
9th June 2015, 02:52
Anime Viewer: Are you using the latest playlist? That should've been fixed a long time ago unless something broke again.
Also what's your Render Script queue?
I'm using the playlist that is bundled with the latest installer. In other words: http://mpdn.zachsaw.com/Latest/Installers/MediaPlayerDotNet_x64_2_29_2_3117_Installer.exe
I'll run an uninstall, and then delete anything that the uninstaller is leaving behind to make sure I get a fresh playlist installed.
I'll also go into C:\Users\MyName\AppData\Local\MediaPlayerDotNet and delete the PlaerExtensions.64 folder to make sure that is reset properly. If I still have problems with it skipping the second file in the playlist after installing after that I'll let you know.
By render script queue are you refering to the Render Queue value I have set in Options -> video Render -> Queues -> Render Queue it is 12 slots (default?). (If you have a different recommended setting let me know). As for the render scripts I currently have set they are: Script Chain containing ChromaScaler -> Deband -> SuperRes
Edit: Yep, its still skipping the playlist items. I launch a video, go to view, go to playlist, and then drag and drop the videos I want to play after the current video finishes. In this case the first thing I added to the playlist (the second video if you count the one I originally opened, or the first if you're going off what is listed at the top of the playlist) is skipped. The third video (or the second one listed in the playlist) is played when the first video ends.
ryrynz
9th June 2015, 08:31
Yep, its still skipping the playlist items.
Garteal's latest dev release (https://github.com/Garteal/MPDN_Extensions/tree/dev) has this fixed (I can't reproduce using it)
This new release will make it into MPDN very soon.
Zachs
10th June 2015, 05:06
No I've had it happen with more than one particular file. Like ryrynz mentioned it doesn't happen every time one of the files that has the problem is launched. Today when I launched that same file (as yesterday) it didn't have the problem occur. Other currently unknown variables are involved. When it happened yesterday it had just switched from playing one file in fullscreen mode to one of the problematic files that was on the playlist. I think the problematic file was third on the playlist. The second file on the playlist is always skipped after the first is played, so I thought that (or it switching from one file in fullscreen mode to another in fullscreen mode) might be related to the problem, but trying to repeat the same situation has failed to trigger the issue (in other words it wasn't switching fluid motion on and off continually). I'll continue experimenting, and report back if I can find a common variable when it is triggering.
Edit: I got it to occur again this time with other files. It started occuring after I went in and changed a setting in Fluid Motion. Specifically I went in and unchecked Only when video frame is less than half of display rate. The properties of the other two files I'm seeing it occur on are:
Video
ID : 1
Format : AVC
Format profile : Main@L3.1
Format settings : CABAC / 6 Ref Frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1435185
Bit rate : 0
Width : 848
Height : 480
Display aspect ratio : 1.006
Frame rate mode : CFR
Frame rate : 23.976
Chroma subsampling : 4:2:0
Bit depth : 8
Scan type : Progressive
Bits/(Pixel*Frame) : 0
Stream size :
Writing library : x264 - core 120 r2120 0c7dab9
Encoding settings : cabac=1 / ref=6 / deblock=1:1:1 / analyse=0x1:0x111 / me=umh
/ subme=8 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 /
trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 /
threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 /
constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 /
weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 /
intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=768 / ratetol=1.0 /
qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 /
vbv_maxrate=1536 / vbv_bufsize=3840 / nal_hrd=none / ip_ratio=1.40 / aq=1:0.60
Language :
Audio
ID : 2
Format : AAC
Codec ID : A_AAC
Duration : 1435179
Bit rate mode :
Bit rate : 0
Channel(s) : 2
Sampling rate : 44100
Bit depth : 0
Compression mode : Lossy
Stream size : 0
Language :
Subtitle
ID : 3
Format : ASS
Muxing Mode :
Codec ID : S_TEXT/ASS
Language :
and
Video
ID : 1
Format : AVC
Format profile : Main@L3.1
Format settings : CABAC / 6 Ref Frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1452244
Bit rate : 0
Width : 848
Height : 480
Display aspect ratio : 1.006
Frame rate mode : CFR
Frame rate : 23.976
Chroma subsampling : 4:2:0
Bit depth : 8
Scan type : Progressive
Bits/(Pixel*Frame) : 0
Stream size :
Writing library : x264 - core 120 r2120 0c7dab9
Encoding settings : cabac=1 / ref=6 / deblock=1:1:1 / analyse=0x1:0x111 / me=umh /
subme=8 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 /
trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 /
threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 /
constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 /
weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 /
intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=768 / ratetol=1.0 /
qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 /
vbv_maxrate=1536 / vbv_bufsize=3840 / nal_hrd=none / ip_ratio=1.40 / aq=1:0.60
Language :
Audio
ID : 2
Format : AAC
Codec ID : A_AAC
Duration : 1452244
Bit rate mode :
Bit rate : 0
Channel(s) : 2
Sampling rate : 44100
Bit depth : 0
Compression mode : Lossy
Stream size : 0
Language :
Subtitle
ID : 3
Format : ASS
Muxing Mode :
Codec ID : S_TEXT/ASS
Language :
Both of those files seem to have similar properties.
It is not occurring when running in the video's native window size. Only during fullscreen (I'm testing to see if it is FSE or FSE D3D 11 related).
Edit #2:
I didn't encounter it in D3D 11 Fullscreen Windowed mode, but then I also didn't encounter it after switching back to D3D 11 FSE mode either...
When the issue has occurred I'd also been running in "Multiple displays: Extend these displays mode", but I'm not sure if that has any barring. Next time it occurs I'll try switching to single display mode to see if that may be a factor.
Edit #3: When it reoccurred again I switched to single display, and D3D 11 Windowed Fullscreen, and Fluid Motion continued to switch on and off.
So you can't find a consistent way to make it happen?
What happens if you try it without render scripts?
Anime Viewer
10th June 2015, 05:46
So you can't find a consistent way to make it happen?
What happens if you try it without render scripts?
I have been running 6-7 files in the playlist over and over again with render scripts set to none, and have yet to have the issue occur. I'll keep testing, and report if anything changes. If ryrynz's theory is correct and the issue is in some way related to it switching between Fullscreen and Windowed modes, but its not occurring with scripts off its probably not the debanding script. That would leave the ChromaScaler and SuperRes scalers. I would guess I'm a rarity running the two combined. I have a feeling other people that have encountered the issue probably weren't running ChromaScaler, and were more likely to be using SuperChromaRes with SuperRes. That would likely mean SuperRes is the common denominator. Something else is would likely be tied to the issue otherwise more people running SuperRes would have encountered the issue.
ryrynz,
What if any scripts did you have running when you noticed the issue on your system?
ryrynz
10th June 2015, 06:22
What if any scripts did you have running when you noticed the issue on your system?
Wasn't running any.
Zachs
10th June 2015, 07:05
Quick question: With the new Conditionals, can I use the other Renderer properties as well, like InputFormat? Turning off debanding for P010 and Y410 would be useful, I rarely if ever need it for 10-bit vids.
Done.
if SourceBitDepth == 8 ... // turn on debanding
Zachs
12th June 2015, 14:45
Hi guys,
Starting from v2.30, MPDN's installer no longer installs MPDN extensions as there's now a separate installer. This makes more sense as they have different release cycles.
For end-users, you only need to download the MPDN installer (pick either 32-bit or 64-bit edition, or both if you like) and the MPDN extensions installer. Install MPDN first before you install MPDN extensions. If you have both 32-bit and 64-bit editions installed, the MPDN Extensions installer will install to both editions (you can change this in the installer).
Cheers.
Anime Viewer
13th June 2015, 04:39
Download Notes:
Download the software certificate and install it (extract all files and run InstallCA.bat - you need to do this just once) on your system to let Windows trust software from zachsaw.com (i.e. MPDN). This also prevents you from getting desensitised from the unknown publisher prompt each time you run MPDN and stops other apps from masquerading as software from zachsaw.com. It also stops people with malicious intents from altering MPDN and making it available online as an alternate download. Make sure you only download the certificate from www.zachsaw.com/downloads/ZachSawDotComCertInstaller.zip.
Doesn't look like it exempts the extension installer (https://github.com/zachsaw/MPDN_Extensions/releases/download/v1.4.1/MPDN-Extensions_v1.4.1_Installer.exe) from the warnings.
Zachs
13th June 2015, 06:59
Oh the extensions Installer isn't a software by zachsaw.com. I'll have to get an open source cert.
Anime Viewer
15th June 2015, 04:27
Anyone else with two monitors running in extended mode notice an issue where expanding to full screen with FSE mode enabled only enters Exclusive mode on one of the screens?
I had CTRL+J running to display the OSD and noticed the secondary monitor was running in Direct3D 11 exclusive mode, but if I expanded to full screen on the primary monitor it reported only running in Direct3D 11 Windowed. I switched back to single mode for the primary monitor and expanded to full screen, and it ran correctly in exclusive mode. Then I re-enabled the extended mode, and that time when I expanded to full screen it said it was in exclusive mode on the primary, but then when I extended back to full screen on the secondary it then reported Direct 3D 11 Windowed on that screen.
I'm not overall concerned since videos play well regardless of whether it is running in Exclusive or Windowed mode, but just thought its odd and wondered if anyone else noticed it.
Zachs
15th June 2015, 05:41
MPDN only supports one monitor for FSE at any given time. You select this via the "Presentation - Graphics Adapter" option.
trandoanhung1991
17th June 2015, 06:13
Can MPDN saves data more often? I'm marathoning a series and MPDN crashes sometimes and then the last played list doesn't get updated and I get lost in the sea of episodes :D
Zachs
17th June 2015, 06:50
Can you let me know what sort of crash it is?
foxyshadis
18th June 2015, 07:30
I've had MPDN hang and have to be force-killed, with the same problem. (Driver problem, not MPDN's fault.) It seems like it only saves data when you close a video cleanly.
Zachs
18th June 2015, 07:37
Yeah I'll change it so it saves settings as soon as you hit OK/accept. I'll also be adding a PlayerControl.CommitSettings method for extensions to ask MPDN to save settings to disk.
foxyshadis
18th June 2015, 11:20
I've got to say that my first time using the installers, I really, really do not appreciate that all of my custom extensions and shaders were summarily deleted along with the bundled ones. I haven't been able to recover any of them, so I'm going to have to start over.
Zachs
18th June 2015, 12:09
Hmm... The Installer deletes the instdir folder before installing. This gets rid of all the custom shaders and all in there. The same goes for upgrades.
I feel your pain but I don't think we anticipated any power users using the installer at all. It was more for end users who only wanted the basic functionality of MPDN.
It's hard to make an installer that works for everyone and we need to start somewhere. That said, I agree it definitely needs to be improved. As a start, it would be good to stop the installer from doing rmdir $instdir and leave the existing extensions intact. However, I'm not sure what the extensions installer should do. If it doesn't delete the extensions, you could end up with both the source and binary versions which would cause the extensions to fail completely.
I'm not sure if nsis supports uninstalling just the files its installer installed but if it did, we could preserve user files quite easily when upgrading or uninstalling.
Belphemur
18th June 2015, 20:00
Hmm... The Installer deletes the instdir folder before installing. This gets rid of all the custom shaders and all in there. The same goes for upgrades.
I feel your pain but I don't think we anticipated any power users using the installer at all. It was more for end users who only wanted the basic functionality of MPDN.
It's hard to make an installer that works for everyone and we need to start somewhere. That said, I agree it definitely needs to be improved. As a start, it would be good to stop the installer from doing rmdir $instdir and leave the existing extensions intact. However, I'm not sure what the extensions installer should do. If it doesn't delete the extensions, you could end up with both the source and binary versions which would cause the extensions to fail completely.
I'm not sure if nsis supports uninstalling just the files its installer installed but if it did, we could preserve user files quite easily when upgrading or uninstalling.
If I have time I'll do what is needed using this : http://nsis.sourceforge.net/Uninstall_only_installed_files
I'll need to refactor some part of the installing script to make an uninstaller that ONLY remove what is added by the installer (right way to do it ...)
For the Extensions, just delete the .dll file should for now be enough.
Zachs
19th June 2015, 00:27
I've made some changes to the installer. Let me push it to github first.
Zachs
19th June 2015, 02:12
I've given it more thought and I'm still unsure the extensions installer should work.
This is as far as I got.
MPDN
Uninstaller: Delete everything except Extensions folder unless it's empty (with an option to remove extensions folder)
Upgrade: Same as uninstalling (but without the option to remove extensions folder)
Extensions
Permutations to consider:
1. User has modified existing shader files.
2. User has added their own extensions .cs/.dll files.
3. User has added their own shader files.
4. User is using .cs files in their extensions folder instead of Mpdn.Extensions.dll.
#2 #3 can easily be catered for by not deleting any files in the extensions folder unless user asks us to do a clean install.
#4 can be easily avoided by making the installer bail out if the user uses the source code version (if Extensions\Framework folder exists).
#1 is a problem. Ideally, modified shader files (e.g. user changing defines in sweetFX shaders) should be retained. But if we did, there's no way to update the shader files when we need to. Any suggestions?
mrcorbo
19th June 2015, 04:47
I've given it more thought and I'm still unsure the extensions installer should work.
This is as far as I got.
MPDN
Uninstaller: Delete everything except Extensions folder unless it's empty (with an option to remove extensions folder)
Upgrade: Same as uninstalling (but without the option to remove extensions folder)
Extensions
Permutations to consider:
1. User has modified existing shader files.
2. User has added their own extensions .cs/.dll files.
3. User has added their own shader files.
4. User is using .cs files in their extensions folder instead of Mpdn.Extensions.dll.
#2 #3 can easily be catered for by not deleting any files in the extensions folder unless user asks us to do a clean install.
#4 can be easily avoided by making the installer bail out if the user uses the source code version (if Extensions\Framework folder exists).
#1 is a problem. Ideally, modified shader files (e.g. user changing defines in sweetFX shaders) should be retained. But if we did, there's no way to update the shader files when we need to. Any suggestions?
Don't delete the existing files to upgrade. Move them into a subfolder and notify the user and, if this subfolder already exists, warn the user if files are going to be overwritten. It may be useful to have a single roll-back version available anyway.
Zachs
19th June 2015, 07:30
Don't delete the existing files to upgrade. Move them into a subfolder and notify the user and, if this subfolder already exists, warn the user if files are going to be overwritten. It may be useful to have a single roll-back version available anyway.
OK I've made the extensions installer backup to "Extensions.Backups" folder every time. The setback is, user will have to remove these backups manually.
ryrynz
19th June 2015, 08:06
OK I've made the extensions installer backup to "Extensions.Backups" folder every time. The setback is, user will have to remove these backups manually.
Unless maybe they untick a box option during the install process (ticked by default) for the user to backup the extensions? A setting which maybe could remembered the next time the installer is run?
|Not a fan of having things backed up if I don't need them backed up, but whatever suits.
Belphemur
19th June 2015, 08:39
I've given it more thought and I'm still unsure the extensions installer should work.
This is as far as I got.
MPDN
Uninstaller: Delete everything except Extensions folder unless it's empty (with an option to remove extensions folder)
Upgrade: Same as uninstalling (but without the option to remove extensions folder)
Extensions
Permutations to consider:
1. User has modified existing shader files.
2. User has added their own extensions .cs/.dll files.
3. User has added their own shader files.
4. User is using .cs files in their extensions folder instead of Mpdn.Extensions.dll.
#2 #3 can easily be catered for by not deleting any files in the extensions folder unless user asks us to do a clean install.
#4 can be easily avoided by making the installer bail out if the user uses the source code version (if Extensions\Framework folder exists).
#1 is a problem. Ideally, modified shader files (e.g. user changing defines in sweetFX shaders) should be retained. But if we did, there's no way to update the shader files when we need to. Any suggestions?
Would it be possible to have a second folder for the user to put their own script etc. It would override anything done by the dll.
Or another way : the dll is installed alongside MPDN (not in the Extension folder). MPDN load it and then load (override) the content by what is in the Extensions folder.
It's a big change, but this way, power user can easily add/modify what they want (and not use the installer if they don't want) and you avoid any possible conflict for normal user.
I do think that power user are not modifying original script, more likely using them as a base for their own. My solution would then let them keep their modified version without the fear of losing them.
Zachs
19th June 2015, 09:35
Not possible I'm afraid.
Zachs
19th June 2015, 12:29
Unless maybe they untick a box option during the install process (ticked by default) for the user to backup the extensions? A setting which maybe could remembered the next time the installer is run?
|Not a fan of having things backed up if I don't need them backed up, but whatever suits.
TBH I don't like them being backed up every time either. I think I may only preserve shaders under the ImageProcessingShaders folder unless you choose to do a clean install. I don't think we need to worry about users' own extensions as the github release notes clearly say installers are for end-users / non power users only.
Shiandow
19th June 2015, 13:19
Would it be an idea to just use the archive flag? Any modification will set this flag to true, so if you set it to false on install then you should just keep those with the flag set to true, unless told otherwise.
You then run into problems when someone has modified the .cs files, but wants to install the dlls, but I think it's acceptable to fail in that case.
Zachs
19th June 2015, 13:23
Hmm that's a good idea. I'll try to preserve just the image processor shaders first for now. We can implement that next.
Zachs
19th June 2015, 13:41
Hi guys,
I've added a new player extension called "Rate Tuner" (requires MPDN v2.31). I'll write up on what it does in detail on wiki in due time but for now see if you could figure out what it does!
Cheers.
huhn
19th June 2015, 18:35
a very complicated to use reclock?
what resampler is used?
i had kind of the same idea for 2 years but automatic by running a something like a test file to measure the clock deviations and keep measuring after that. the result is than speed corrected by changing the sample rate after supersampling it and the result should be outputted as the max sample rate/bit deep the soundcard can handle. i never started it of cause.
for example every 47950 (supersampled for less errors) khz are resampled to 192/24 bit
Magik Mark
19th June 2015, 21:12
Zach
I'm getting page not found when dowmloading the extensions for both installer and source
Garteal
19th June 2015, 22:03
Zachs made a mistake in the url with em.
Try these:
MPDN Extensions Installer (https://github.com/zachsaw/MPDN_Extensions/releases/download/1.5.1/MPDN-Extensions_v1.5.1_Installer.exe)
MPDN Extensions Binaries (https://github.com/zachsaw/MPDN_Extensions/releases/download/1.5.1/Mpdn.Extensions.zip)
MPDN Extensions Source (https://codeload.github.com/zachsaw/MPDN_Extensions/zip/1.5.1)
Zachs
20th June 2015, 06:17
a very complicated to use reclock?
what resampler is used?
i had kind of the same idea for 2 years but automatic by running a something like a test file to measure the clock deviations and keep measuring after that. the result is than speed corrected by changing the sample rate after supersampling it and the result should be outputted as the max sample rate/bit deep the soundcard can handle. i never started it of cause.
for example every 47950 (supersampled for less errors) khz are resampled to 192/24 bit
It doesn't resample, at least not yet.
But yes it's something like reclock but a lot more accurate. It's not as automatic as reclock without having a custom audio renderer but it's no different to what you described - you can run a test file (say 23.976Hz) with a corresponding display refresh rate. Most people can't get their display to be exactly the same as their source - this extension allows them to achieve that.
For example, I get 23.978Hz on my display and with a ref clock deviation of -ve value, I end up with something like 23.975Hz effective as the source. I use this extension to bring it back up to 23.978Hz. This allows me to completely get rid of any repeated frames (or dropped frames if your display is slower than ref clock corrected source frame rate) - hence completely stutter free no matter how long the video plays. The pitch shift is bugger all so there's no need for resampling.
PAL DVDs can also be run at 23.976Hz using this extension so the pitch automatically gets corrected (not that I play DVDs much these days but according to most sites PAL DVDs are simply 23.976Hz materials played back at 25Hz without having their audio resampled, hence pitch shifted).
That said, I'm not sure how it works when audio is bitstreamed. Eventually, I do hope I can extend MPDN to support audio scripts / extensions.
huhn
20th June 2015, 11:44
how can you change the speed of audio without resampling it? i simply don't understand how that's working.
and your video file refresh rate measuring doesn't work well at all but i have to investigate this more.
Zachs
20th June 2015, 12:12
The refresh rate is the actual one collected over the last 2 seconds, not the one reported by the media file which is absolutely meaningless.
I'll need to write up some guide on how to use it but essentially if you let your clip run for around 4 minutes without pausing or seeking, you end up with very accurate values.
huhn
20th June 2015, 12:13
i mean the number your rate tuner calculates as video frame rate
Zachs
20th June 2015, 12:15
Oh if you feel it is inaccurate, you can easily give it a value of your own. That's why I haven't made the thing fully automatic as there is bound to be cases where it doesn't work very well.
huhn
20th June 2015, 12:21
that what i have to do. had to add 23.97602397623976 to get the real speed value.
and it would really help if i can just set this for every >display< resolution/refreshrate not for every input file.
480p23, 720p23 and 1080p all need the same speed value.
and that's why i talked about a test file the test file refresh rate is 100 % known and should be "perfect" 23/24/25/29/30/50/59/60 hz.
a VFR source can be ignored.
EDIT:
this shouldn't work when i think about it...
i mean the problem is not the video refresh rate and display refresh rate doesn't match. the problem is that the audio clock doesn't match the video clock the rest doesn't matter...
Zachs
20th June 2015, 12:48
This changes the audio clock in case you haven't noticed. That's why I told you there's no resampling.
Zachs
20th June 2015, 12:50
Btw set video specifier to "p23" and it'll do exactly what you said. Then in your calculator, use the perfect value of 23.976.
huhn
20th June 2015, 13:05
This changes the audio clock in case you haven't noticed. That's why I told you there's no resampling.
and changing the audio clock is save to do? changing the video clock is not 100% save.
i mean it can change the audio clock by a lot like 50 % so the soundcard get not 192000 sample a sec it gets 288000 sample a sec. or how does changing the audio clock works?
Btw set video specifier to "p23" and it'll do exactly what you said. Then in your calculator, use the perfect value of 23.976.
i see. didn't get that out of your "show usage tips". at least it makes now sense why it worked.
Zachs
20th June 2015, 13:10
Yes the audio card simply plays treats it like a stream with higher number of samples per second. There's a maximum of how much it'll take but for the use case of rate tuner, it's more than enough. It'll probably not work with bitstreaming audio though but I've tested with LPCM via HDMI and it works fine.
huhn
20th June 2015, 13:14
are you sure the windows mixer is not resampling it to something "usable".
if not the soudncard is running not within it's specs.
Zachs
20th June 2015, 13:21
Well that might be the case but unless you can notice a difference in sound quality I wouldn't be too worried about it. For cards that can support higher sample rates, I'm pretty sure it doesn't. At least according to what I could find on the internet...
EDIT: Oh BTW, I use MPC Audio Renderer with WASAPI exclusive mode output so I don't think windows mixer has any say in this at all.
huhn
20th June 2015, 13:49
Well that might be the case but unless you can notice a difference in sound quality I wouldn't be too worried about it. For cards that can support higher sample rates, I'm pretty sure it doesn't. At least according to what I could find on the internet...
i don't have a good feeling about this you should at least warn them. i don't think the soundcard spec are for fun.
EDIT: Oh BTW, I use MPC Audio Renderer with WASAPI exclusive mode output so I don't think windows mixer has any say in this at all.
that has it own mixer (from windows i mean it is windows audio session...).
Zachs
20th June 2015, 14:00
Yes as with every other feature in MPDN, it goes without saying you should always do your own testing.
Heck you could even write your own audio renderer and it may break it completely, or it may be like reclock where it resamples it with rather high quality interpolators.
Too many different ways you can use MPDN and too many different hardware / driver out there too.
No. WASAPI exclusive mode does not have a mixer from Windows. I'm not sure what MPC Audio Renderer is using as its resampler but I would suspect it's probably libresample.
huhn
20th June 2015, 14:24
wasapi has an share mode which needs an mixer why should they remove the whole mixer in exclusive mode. the only thing that change is that it may not be used if possible if the bit deep is to high it still has to change that same of speaker layout so i guess same for sample rate.
it's not about working software is more about breaking hardware.
by overclocking you can brake hardware. can over/under clocking the audio clock brake hardware? if it is resample by what ever program it is still running in specs and there is nothing to panic about but if not it may brake something.
Zachs
20th June 2015, 14:31
Care to cite your source? From MSDN literature, even shared mode doesn't have that. You need to resampling yourself. Are you saying this is wrong?
Yes all I'm saying is direct sound may simply ask the sound card to sample at a higher rate but that rate has to be within specs of course. Changing the sample rare is essentially changing the 'clock'. I certainly didn't mean over / under clocking the sound card.
Edit: I need to mention that different audio renderer will do it differently, and I was talking about direct sound before the conversation went to wasapi. In the direct sound renderer, as far as I can find out is that if a sample rate is supported by the sound card, it'll use it. Otherwise it'll get transparently resampled. Either way, the rate tuner doesn't do resampling.
Edit 2: reading your reply again I think you're confusing what I'm saying. You kept saying mixer. The issue here is whether it resamples, not whether the mixer is in use. Obviously when in shared mode it is. But why would it need the mixer in Exclusive mode? And no, the mixer being present doesn't mean you don't need to resample. They are completely orthogonal.
huhn
20th June 2015, 15:14
Care to cite your source? From MSDN literature, even shared mode doesn't have that. You need to resampling yourself. Are you saying this is wrong?
Yes all I'm saying is direct sound may simply ask the sound card to sample at a higher rate but that rate has to be within specs of course. Changing the sample rare is essentially changing the 'clock'. I certainly didn't mean over / under clocking the sound card.
isn't the mixer software based since windows vista?
so the soundcard doesn't need to resample at all so the soundcard doesn't get out of spec values. i don't see how this can't be the same with WASAPI. you can set the output that is used in share mode so every program is forced to output that format so it may has to down mix and resample before sending it to wasapi or wasapi is using a mixer which is more likely.
but can wasapi exclusive just send out of spec sample rates to the soundcard driver/card that sounds dangerous.
Edit: I need to mention that different audio renderer will do it differently, and I was talking about direct sound before the conversation went to wasapi. In the direct sound renderer, as far as I can find out is that if a sample rate is supported by the sound card, it'll use it. Otherwise it'll get transparently resampled. Either way, the rate tuner doesn't do resampling.
so with direct sound the soundcard gets only data that is part of it's spec so nothing to bother about.
so the only change you can make is adding a resampler yourself so you have more control over the quality.
huhn
20th June 2015, 15:16
Edit 2: reading your reply again I think you're confusing what I'm saying. You kept saying mixer. The issue here is whether it resamples, not whether the mixer is in use. Obviously when in shared mode it is. But why would it need the mixer in Exclusive mode? And no, the mixer being present doesn't mean you don't need to resample. They are completely orthogonal.
ok let's say any post processing of any kind that is need for what ever reason.
Zachs
21st June 2015, 05:03
I'm not sure I understand what you're trying to say...
madshi
21st June 2015, 06:56
I'm not sure what effect changing the audio clock has. It could be as innocent as just changing the setting of the clock chip slightly, with no further processing becoming active. But then, at some point the audio data will have to run through a DAC, and the DAC's clock will usually be set by the receiver. The big question is if this DAC's clock will be chained to the source's audio clock or not. Probably not. But that's already a problem even without changing the audio rate. The DAC will have to handle mismatching clocks to some extent. It's possible that changing the audio clock could result in more "adjustments" being done by the DAC in the receiver. This is all extremely hard to know/judge for us normal humans. Could be a great solution, or not, depending on how all the devices in the chain handle it. In theory, one receiver could produce exactly the same audio quality. Another receiver might produce higher jitter or something. Really hard to say. Testing this with bitstreaming might be a good idea. If it works with bitstreaming (which I don't think is impossible) without any audio quality issues then chances are good it will also work well with PCM. For bitstreaming testing I would recommend to use AC3 because that has the longest frame duration, so bitstreaming issues would be most noticeable. Another test would be to put this to the extreme and test rather high rate change values (like a factor of 1.5x or even 2.0x). At some point either the audio pitch has to noticeably change (indicating that either resampling is done or the audio clock is really adjusted by the receiver), or noticeable audio artifacts must show up.
Zachs
21st June 2015, 07:08
Yes like I said earlier, everything comes down to how your hardware and/or driver and/or audio renderer handle it. It's no different from MPDN's high bitdepth output, as most madvr users have only just recently found out.
Wasapi allows the audio endpoint to request specific rates from the audio card. But like the graphics card and display resolution, not every hardware works the same. Some may need resampling, some may not. But just as the 10bit output, you really need to test it yourself. To get consistent behaviour across all hardware, the only solution would be to always resample it in software, which I had planned to do for some time now.
Zachs
21st June 2015, 07:16
p.s. I personally use this in my setup because I just can't get my nvidia card to get close enough to the refresh rate I want. So far I haven't noticed any difference at all with the audio. So subjectively speaking it works great for me. When I get some time, I'll have a look into the MPC audio renderer code to see exactly what it does. There's no way to find out what the direct sound renderer actually does though...
From visual protective standpoint, this is definitely way better than fluid motion as it basically gives you stutter free viewing experience and your display can run at its natively supported frequency with all the advanced FRC features it offers. If you don't notice any difference in audio, I'd say this is definitely the recommended way to play video.
foxyshadis
21st June 2015, 10:49
I've got to say, the insanely fast changes to the installer was surprising and gratifying. This is the most responsive development project I've ever come across, not only for this, but everything about it. Thanks, Zachs and Belphemur and Shiandow!
huhn
21st June 2015, 10:51
i just wanted to test for audio differences.
but i run into my general audio issues again this time way worse than usually.
the first thing that changed is that the fullness is not the problem it is now staying at stable 90%.
but now i see the ref clock changing when i hear an audio issue and some times a frame is delayed at the same time. the refclk deviations is skyrocketing after that. i even saw numbers like 0.35 % after 60 sec playback.
that's without rate tuner. but i got this issue with it too.
of cause i don't have that issue with madVR.
kerimcem
21st June 2015, 14:11
mpdn+lav video intel quciksync hardware gpu deinterlacing mpeg2 vob files = image gets stuck..:(
mpc+madvr+lav video intel quciksync hardware gpu deinterlacing mpeg2 vob files =no problem......
Belphemur
21st June 2015, 19:29
mpdn+lav video intel quciksync hardware gpu deinterlacing mpeg2 vob files = image gets stuck..:(
mpc+madvr+lav video intel quciksync hardware gpu deinterlacing mpeg2 vob files =no problem......
Could you provide the media file you used ?
Shiandow
23rd June 2015, 23:55
@all. There's been a lot of development these last few days not just by me but by the other developers as well. In fact, I think the next update might be one of the biggest yet! Anyway, here are some of the changes I've made that you can expect in the next version of the MPDN extensions:
ScriptGroup now has a new dialog similar to the ScriptChain dialog. This avoids the need for two separate dialogs. These changes to the Script Group are unfortunately not compatible with the older config files, those might need to be reset.
SuperRes has been improved (or changed, anyway). Most of the parameters have become obsolete, the only remaining parameters are "passes", "strength" and "softness". The new algorithm is more consistent when combined with different prescalers, so there's no longer a need to save the parameters separately for each prescaler (the old behaviour can be mimicked by making a script group with multiple copies of SuperRes). And since there's an increasing number of possible prescalers the list of prescalers can now be modified freely. The new algorithm is capable of creating incredibly sharp images without increasing ringing and aliasing. That said it's not capable of removing ringing and aliasing either so using a good prescaler is essential (but more on that later).
SuperChromaRes has been improved similarly, with an additional "bilateral prescaler" option. Enabling this option makes SuperChromaRes use it's own chroma upscaling method which uses the luma to guide the chroma upscaling.
Hylian's excellent Super-xBR algorithm has also been ported to MPDN. It's already shown great promise in the MadVR thread but used as a prescaler for SuperRes makes it possible to get images that are sharper than I've ever seen with remarkably low aliasing and ringing. And Super-xBR doesn't seem to have reached it's peak yet so I'm excited to see how much more it can be improved!
The new SuperRes, SuperChromaRes and Super-xBR scripts are still experimental so feedback would be highly appreciated!
Zachs
24th June 2015, 03:51
i just wanted to test for audio differences.
but i run into my general audio issues again this time way worse than usually.
the first thing that changed is that the fullness is not the problem it is now staying at stable 90%.
but now i see the ref clock changing when i hear an audio issue and some times a frame is delayed at the same time. the refclk deviations is skyrocketing after that. i even saw numbers like 0.35 % after 60 sec playback.
that's without rate tuner. but i got this issue with it too.
of cause i don't have that issue with madVR.
Without the rate tuner, MPDN is a slave to the ref clock which is usually derived from the audio card by the audio renderer. As such, video smoothness is affected when you get an audio problem. TBH I'm not sure what could be the problem seeing as I can't replicate your problem even on my very low end Atom tablet, or my very old and dusty Core2Duo laptop with ATI Mobility Radeon X2300. My HTPC runs a Creative X-Fi and that has never encountered any problems too.
mpdn+lav video intel quciksync hardware gpu deinterlacing mpeg2 vob files = image gets stuck..:(
mpc+madvr+lav video intel quciksync hardware gpu deinterlacing mpeg2 vob files =no problem......
I personally watch a lot of MPEG2 interlaced materials with MPDN and haven't had any problem. With madVR are you sure you're using LAV's quicksync decode+deint hardware and not madVR's DXVA decode?
ryrynz
24th June 2015, 06:42
I notice some render script examples get installed with the latest release, is that intentional? Could be tider if there was an option to install 'em.
Zachs
24th June 2015, 06:44
That wasn't intentional. I'll have a look!
EDIT: Extensions v1.6.1 should have the examples removed.
Magik Mark
24th June 2015, 09:10
Zachs,
How do i put 1080p & 720p videos both 24fps in the video type found in the rate tuner? Thanks
Zachs
24th June 2015, 09:20
24.000fps or 23.976?
If it's the latter it's "23p"
Magik Mark
24th June 2015, 09:45
24.000fps or 23.976?
If it's the latter it's "23p"
Is this the right format:
w1920 h1080 p23? Gives me an error
Zachs
24th June 2015, 11:37
There's no need to specify height or width if you want to match all p23 materials. If you want to match 1080p 23.976, use w1920p23. w1280p23 for 720p 23.976hz materials.
Magik Mark
24th June 2015, 12:05
There's no need to specify height or width if you want to match all p23 materials. If you want to match 1080p 23.976, use w1920p23. w1280p23 for 720p 23.976hz materials.
Thank you that did it for tv shows. I'm getting a lot of frame drops when watching movies. This is really odd. The frame rate & resolution are the same as that of tv shows. Its really moving a little bit fast for both audio & video. Like the chipmunks
Zachs
24th June 2015, 12:08
Check your render times. Are they the same between the two?
Magik Mark
24th June 2015, 12:17
Check your render times. Are they the same between the two?
There is a difference of 2ms. When I switch FSE tv shows are behaving the same as the movies. AUdio & video are moving fast. All I did is copy the speed% found in the calculator
Zachs
24th June 2015, 12:40
You can't simply copy the values. If you want it to match 23.976hz of your display refresh rate, you need to first switch to that mode. Otherwise you're asking it to play at whatever your refresh rate was when you opened the calculator.
I will write a guide on how to use it when I get some time.
ryrynz
24th June 2015, 13:08
Its really moving a little bit fast, like the chipmunks
You can't simply copy the values.
:stupid: :D
Zachs
24th June 2015, 13:54
A short guide using 23.976FPS materials, assuming you have a monitor / TV capable of 24 input.
First, set your display refresh rate to 24Hz.
Run your 23.976FPS video for 5 minutes (make sure you don't seek / pause -- just let it run continuously).
Once you have let it run for 5 minutes, open the calculator with the video still running.
At this point, the calculator will give you very accurate values which will make your 23.976FPS input run at exactly your display refresh rate.
If you have a display capable of 25Hz, you can use the same steps as above to run your 23.976FPS input as 25FPS so you don't get any dropped / repeated frames. Most TVs don't support 25Hz but can do 50Hz. In which case, all you have to do is manually divide your Display Rate value by 2 in the calculator. This will give you 25FPS on a 50Hz refresh rate.
What this means is, you can disable fluid motion and still have perfectly fluid video playback. For the 24Hz refresh rate case, you can now enable your TV's FRC feature. With absolutely no repeated / dropped frames, your TV's FRC feature won't interpolate the wrong frames - IOW the FRC feature will work in its most ideal manner.
ryrynz
24th June 2015, 14:01
Would it be perfectly? or could it stand to do an automatic correction every say 5/10 minutes or something, as going by the OSD the there is a bit of fluctuation going on.
bacondither
24th June 2015, 14:06
I have found a strange bug.
When testing my adaptive sharpen shader in a script chain with deband and the video was displayed at original size the image flickers heavy with a pattern of fast dark and normal frames.
I have located the core of the problem to outputting a float3 as a float4 with padding for the w component which results in flickering.
//"flicker.hlsl"
sampler s0 : register(s0);
float4 main(float2 tex : TEXCOORD0) : COLOR
{
float3 c0 = tex2D(s0, tex).rgb;
return c0.rgbb;
}
Example script chains with flickering:
deband --> flicker.hlsl
deband --> resizer --> flicker.hlsl
flicker.hlsl --> deband
chroma scaler --> flicker.hlsl
Flickering only occurs when the image is at the original size, if the image is scaled the flickering goes away.
"flicker.hlsl" by itself in the chain gives no problems at all.
Tested with MPDN v2.31.0 and extensions v1.6.1, all the settings in MPDN is the default.
AMD GPU running driver version 14.4.
Anime Viewer
24th June 2015, 14:06
You can't simply copy the values. If you want it to match 23.976hz of your display refresh rate, you need to first switch to that mode. Otherwise you're asking it to play at whatever your refresh rate was when you opened the calculator.
I will write a guide on how to use it when I get some time.
That might explain why when I originally tested Rate Tuner it was giving me reports of ~249%-250% even when I clicked the calculator and input 23.976 and 24 in the display rate section of the calculator.
This raises a problem I've noticed. I have two displays: one that is the default notebook screen which supports 59hz and 60hz only, the other is a TV that supports 23hz,24hz, 59hz, and 60hz. I used to be able to go into Windows screen resolution, pick the TV under display, click the Advanced Settings link, List All Modes, select the mode I want to run in (ex: 1920x1080, True Color (32bit), 23Hertz, click ok and it would switch the tv screen to that setting which I could confirm with the CTRL+J listing for display as the video would run. However now while it looks like it took the setting in Windows display modes (if I go back in the one I chose is still highlighted/selected MPDN CTRL+J inside the video reports the display as 59hz regardless. The videos I've tested are 23.976hz source files. I've tested with and without Display Changer Activate automatic display refresh rate changer checked, and still MPDN OSD is reporting the display as 59hz.
Any thoughts as to why the OSD is reporting 59hz when playing videos on the TV regardless or what hz I've selected for the screen to run in? (I have both "Use highest" and "Activate only" both unchecked when testing in Display Changer). Is it possible the screen is changing, but the OSD isn't reporting it right?
Shiandow
24th June 2015, 14:26
I have found a strange bug.
When testing my adaptive sharpen shader in a script chain with deband and the video was displayed at original size the image flickers heavy with a pattern of fast dark and normal frames.
I have located the core of the problem to outputting a float3 with padding for the z component which results in flickering.
[...]
Example script chains with flickering:
deband --> flicker.hlsl
deband --> resizer --> flicker.hlsl
flicker.hlsl --> deband
chroma scaler --> flicker.hlsl
Flickering only occurs when the image is at the original size, if the image is scaled the flickering goes away.
"flicker.hlsl" by itself in the chain gives no problems at all.
Tested with MPDN v2.31.0 and extensions v1.6.1, all the settings in MPDN is the default.
AMD GPU running driver version 14.4.
That's probably caused by the alpha channel. MPDN doesn't like it when it is not 1. Some processing fixes the alpha channel again so it only causes problems sometimes.
bacondither
24th June 2015, 14:36
That's probably caused by the alpha channel. MPDN doesn't like it when it is not 1. Some processing fixes the alpha channel again so it only causes problems sometimes.
Thanks! Setting the w channel to 1 seems to work.
huhn
24th June 2015, 14:51
Without the rate tuner, MPDN is a slave to the ref clock which is usually derived from the audio card by the audio renderer. As such, video smoothness is affected when you get an audio problem. TBH I'm not sure what could be the problem seeing as I can't replicate your problem even on my very low end Atom tablet, or my very old and dusty Core2Duo laptop with ATI Mobility Radeon X2300. My HTPC runs a Creative X-Fi and that has never encountered any problems too.
i only have this problem with MPDN. EVR, foobar2000, computer games and web browser they all work totally fine.
and the next thing is if MPDN is the slave to the audio clock why is audio distorted and not a frame repeated/dropped? in best case i get a frame delay with audio distortion in most cases just audio distortion even through MPDN shows a frame repeat of a couple of secs with clock deviations of 0.35 %.
and of cause is no real work for my HTPC to use MPDN.
Magik Mark
25th June 2015, 00:02
A short guide using 23.976FPS materials, assuming you have a monitor / TV capable of 24 input.
First, set your display refresh rate to 24Hz.
Run your 23.976FPS video for 5 minutes (make sure you don't seek / pause -- just let it run continuously).
Once you have let it run for 5 minutes, open the calculator with the video still running.
At this point, the calculator will give you very accurate values which will make your 23.976FPS input run at exactly your display refresh rate.
If you have a display capable of 25Hz, you can use the same steps as above to run your 23.976FPS input as 25FPS so you don't get any dropped / repeated frames. Most TVs don't support 25Hz but can do 50Hz. In which case, all you have to do is manually divide your Display Rate value by 2 in the calculator. This will give you 25FPS on a 50Hz refresh rate.
What this means is, you can disable fluid motion and still have perfectly fluid video playback. For the 24Hz refresh rate case, you can now enable your TV's FRC feature. With absolutely no repeated / dropped frames, your TV's FRC feature won't interpolate the wrong frames - IOW the FRC feature will work in its most ideal manner.
I have 60hz Monitor. Does it mean I have to divide the refresh rate in the calculator by 2.5 in order to play 23.976hz or 24 hz video smoothly?
huhn
25th June 2015, 00:17
I have 60hz Monitor. Does it mean I have to divide the refresh rate in the calculator by 2.5 in order to play 23.976hz or 24 hz video smoothly?
you should use fluid motion to play it smooth not this new feature.
Zachs
25th June 2015, 01:14
Would it be perfectly? or could it stand to do an automatic correction every say 5/10 minutes or something, as going by the OSD the there is a bit of fluctuation going on.
Perfectly. By fluctuation you mean the actual average FPS presented? If so, that's just because of how the average is calculated. With the method I wrote, I've managed to watch a 2.30hr movie without a single repeated/dropped frame with my TV @23.978Hz.
Any thoughts as to why the OSD is reporting 59hz when playing videos on the TV regardless or what hz I've selected for the screen to run in? (I have both "Use highest" and "Activate only" both unchecked when testing in Display Changer). Is it possible the screen is changing, but the OSD isn't reporting it right?
Which monitor did you pick for your "Presentation" graphics adapter? When you move MPDN's window to your TV, does the OSD say "Current Display"? If it says "Other Display", you've set it up to use your laptop screen.
Thanks! Setting the w channel to 1 seems to work.
As long as the final result sets the w channel to 1, MPDN will be happy. Any other values will result in undefined behaviour. You can still use w channel to pass data from an earlier pass in the middle of the processing chain, as long as the w channel gets set back to 1 before returning the result texture to MPDN.
i only have this problem with MPDN. EVR, foobar2000, computer games and web browser they all work totally fine.
and the next thing is if MPDN is the slave to the audio clock why is audio distorted and not a frame repeated/dropped? in best case i get a frame delay with audio distortion in most cases just audio distortion even through MPDN shows a frame repeat of a couple of secs with clock deviations of 0.35 %.
and of cause is no real work for my HTPC to use MPDN.
Have you tried playing just the audio stream to see if MPDN still causes your audio issue? Can you also try playing audio in the background and then make MPDN distort the audio to see if the audio playing in the background is distorted as well?
The point I was trying to make was I won't be able to debug it without you spending some time on it since I (or anyone else for that matter) can't replicate your issue on any of my systems. And I gather from your replies you weren't interested at all in doing so.
I have 60hz Monitor. Does it mean I have to divide the refresh rate in the calculator by 2.5 in order to play 23.976hz or 24 hz video smoothly?
You should not divide it by anything other than an integer number. In your case, if you really want to use the rate tuner, you could look into overclocking your monitor and then get it as close as 24Hz*3 as possible. You then divide the refresh rate by 3. One of my monitors also only does 60Hz but I managed to overclock it to 68.5Hz. This means I end up with 22.833Hz when playing 23.976FPS materials. Your video will play around 5% slower but you won't notice the difference (PAL conversion works the opposite by doing a ~4% speedup). You should also use MPC-BE Audio Renderer (included with MPDN's latest installer) with WASAPI exclusive mode output when using the rate tuner. WASAPI audio renderers can set the sample rate of your audio endpoint directly.
Magik Mark
25th June 2015, 05:08
Zachs is there a way to reverse engineer reclock then port it to MPDN?
Zachs
25th June 2015, 05:37
User guide for Rate Tuner - https://github.com/zachsaw/MPDN_Extensions/wiki/Rate-Tuner
Zachs
25th June 2015, 05:39
Zachs is there a way to reverse engineer reclock then port it to MPDN?
There's no need to - reclock doesn't do magic, contrary to what most people believe (you do know reclock won't make 24 fps play buttery smooth at 60hz right?). Read the rate tuner user guide I just posted above.
Anime Viewer
25th June 2015, 06:05
Which monitor did you pick for your "Presentation" graphics adapter? When you move MPDN's window to your TV, does the OSD say "Current Display"? If it says "Other Display", you've set it up to use your laptop screen.
You're correct it was listing "Other Display" when playing the video on the TV screen. I used to have the TV as the presentation screen, but changed that after I noticed that I would see the screen flash black (switching modes) sometimes when I was switching between browser tabs (and other tabs on Windows taskbar - it was probably kicking MPDN out of exclusive mode) when running in exclusive mode with the tv as the presentation screen. At the time I switched the notebook to be the presentation screen which would allow exclusive mode on the notebook (so I wouldn't give it up entirely) and let the TV run in full screen windowed mode. I've now changed it back to use the TV as the presentation screen, and just let them both run in full screen windowed mode. The side effect of this is that now it seem when running a 23hz video on the notebook screen it says the display is running at 23hz too (even though the notebook screen is only supposed to support 59hz and 60hz rates).
On a related note there is probably a way to do away with forcing one screen to be the presentation mode and the other to not. I find in MPC with MadVR I can have video playing in Exclusive fullscreen mode on one screen, drag it over to the other screen and maximize it, and that screen will also display as running in exclusive mode. Also MPC/madVR is locking the secondary screen to running at the presentation screens refresh rate. If madVR can do it then MPDN should have the ability to run in such a state too.
Magik Mark
25th June 2015, 06:22
User guide for Rate Tuner - https://github.com/zachsaw/MPDN_Extensions/wiki/Rate-Tuner
Thanks a lot! Works great with SVP
I there a way to port SVP settings to MPDN natively? This would be great for the 64bit version. Currently SVP is only 32bit
Zachs
25th June 2015, 06:51
You're correct it was listing "Other Display" when playing the video on the TV screen. I used to have the TV as the presentation screen, but changed that after I noticed that I would see the screen flash black (switching modes) sometimes when I was switching between browser tabs (and other tabs on Windows taskbar - it was probably kicking MPDN out of exclusive mode) when running in exclusive mode with the tv as the presentation screen. At the time I switched the notebook to be the presentation screen which would allow exclusive mode on the notebook (so I wouldn't give it up entirely) and let the TV run in full screen windowed mode. I've now changed it back to use the TV as the presentation screen, and just let them both run in full screen windowed mode. The side effect of this is that now it seem when running a 23hz video on the notebook screen it says the display is running at 23hz too (even though the notebook screen is only supposed to support 59hz and 60hz rates).
On a related note there is probably a way to do away with forcing one screen to be the presentation mode and the other to not. I find in MPC with MadVR I can have video playing in Exclusive fullscreen mode on one screen, drag it over to the other screen and maximize it, and that screen will also display as running in exclusive mode. Also MPC/madVR is locking the secondary screen to running at the presentation screens refresh rate. If madVR can do it then MPDN should have the ability to run in such a state too.
Yes this has been on my todo list for a long time but it remains low priority as you could only run one screen in exclusive mode at any given time anyway.
EDIT: BTW, it says the "Other display" is running at 23Hz when you have MPDN on your notebook screen.
EDIT2: You can make MPDN use display 1 or 2 via command line "adapter" option. You can simply create 2 shortcuts - one to launch MPDN for your TV, another when you want to view on your notebook screen.
ryrynz
25th June 2015, 07:54
Zach could you allow the rate tuner to only activate either when certain refresh rates are active or tie it in to the display changer?
Zachs
25th June 2015, 08:12
I'll have a think about that. It doesn't matter if it's activated even when your refresh rate hasn't been set correctly though does it?
huhn
25th June 2015, 08:41
Have you tried playing just the audio stream to see if MPDN still causes your audio issue? Can you also try playing audio in the background and then make MPDN distort the audio to see if the audio playing in the background is distorted as well?
EDIT:i tried to reproduce this while MPC-HC was running muted and at 5% and i still get the issue but i didn't get a delayed frame in 10 min testing i tested if a running and muted MPDN instance has audio effects on MPC-HC and a muted instance of MPDN most likely had an effect. heard an huge audio issue and a lot of frames where dropped at one point in madVR could be an issue of two program using GPU but unlikely in this case. double check MPC-HC only afterwards and no issue what so ever.
my clock deviation at 23p is 0.00333 to 0.00340 usually after ~3 mins this doesn't sound like a to bad audio clock in general.
EDIT:
direct audio:
15 mins audio only didn't present me any issue.
mpc-hc audio renderer in MPDN:
audio video playback:
extrem audio distortions combined with delayed repeated and dropped frames from time to time way worse than with directaudio but the ref clock stays at a stable 23.976 something clock unlike direct audio.
second try ref clock was at 23.97602-23.97610 after 40 sec no audio problems but delayed frames.
12 min audio only didn't present me any issues.
2 audio programs at the same time is pretty much pointless with exclusive mode wasapi or?
The point I was trying to make was I won't be able to debug it without you spending some time on it since I (or anyone else for that matter) can't replicate your issue on any of my systems. And I gather from your replies you weren't interested at all in doing so.
i pointed the old issue at the fullness but this can't be the issue anymore. the old issue need some concentrated hearing. i don't even kno if this is the same issue or i'm "lucky" that it triggers this hard. and sometimes it doesn't trigger at all and the ref clk deviations stays normal.
huhn
25th June 2015, 08:56
bug:
open a flac file most likly all audio only files:
===================================
An unexpected error 'System.NullReferenceException' has occurred.
------------------------------
Error Type = System.NullReferenceException
Error Message = Object reference not set to an instance of an object.
Error Source = Mpdn.Extensions
Error Site = Void PlayerStateChanged(System.Object, Mpdn.PlayerStateEventArgs)
Error occurred = at Mpdn.Extensions.PlayerExtensions.DisplayChanger.PlayerStateChanged(Object sender, PlayerStateEventArgs e)
at System.EventHandler`1.Invoke(Object sender, TEventArgs e)
at Mpdn.PlayerControl.OnPlayerStateChanged(PlayerState playerState, PlayerState oldState)
at MediaPlayerDotNet.MainForm.<>c__DisplayClass3d.<SetPlayerState>b__3c()
at Mpdn.Utilities.ControlHelpers.HandleAsync()
OS Version = Microsoft Windows NT 6.3.9600.0
...stuff...
===================================
Object reference not set to an instance of an object. (Mpdn.Extensions)
------------------------------
Program Location:
at Mpdn.Extensions.PlayerExtensions.DisplayChanger.PlayerStateChanged(Object sender, PlayerStateEventArgs e)
at System.EventHandler`1.Invoke(Object sender, TEventArgs e)
at Mpdn.PlayerControl.OnPlayerStateChanged(PlayerState playerState, PlayerState oldState)
at MediaPlayerDotNet.MainForm.<>c__DisplayClass3d.<SetPlayerState>b__3c()
at Mpdn.Utilities.ControlHelpers.HandleAsync()
Zachs
26th June 2015, 01:05
EDIT:i tried to reproduce this while MPC-HC was running muted and at 5% and i still get the issue but i didn't get a delayed frame in 10 min testing i tested if a running and muted MPDN instance has audio effects on MPC-HC and a muted instance of MPDN most likely had an effect. heard an huge audio issue and a lot of frames where dropped at one point in madVR could be an issue of two program using GPU but unlikely in this case. double check MPC-HC only afterwards and no issue what so ever.
my clock deviation at 23p is 0.00333 to 0.00340 usually after ~3 mins this doesn't sound like a to bad audio clock in general.
EDIT:
direct audio:
15 mins audio only didn't present me any issue.
mpc-hc audio renderer in MPDN:
audio video playback:
extrem audio distortions combined with delayed repeated and dropped frames from time to time way worse than with directaudio but the ref clock stays at a stable 23.976 something clock unlike direct audio.
second try ref clock was at 23.97602-23.97610 after 40 sec no audio problems but delayed frames.
12 min audio only didn't present me any issues.
2 audio programs at the same time is pretty much pointless with exclusive mode wasapi or?
i pointed the old issue at the fullness but this can't be the issue anymore. the old issue need some concentrated hearing. i don't even kno if this is the same issue or i'm "lucky" that it triggers this hard. and sometimes it doesn't trigger at all and the ref clk deviations stays normal.
bug:
open a flac file most likly all audio only files:
Garteal fixed it! :thanks:
Just so I understand your test results complete, can you confirm if I got the following correct?
Directsound
MPDN audio only = no distortion
MPDN audio+video = distortion
MPDN audio+video (muted) with MPC-HC audio+video = distortion
MPDN audio+video (muted) with MPC-HC audio only = distortion?
MPDN audio only with MPC-HC audio only = no distortion?
As for WASAPI exclusive mode, you mentioned you never got it to work with MPC-HC either, is that correct?
Can you try running DPC latency checker to see if you get any obvious problems when distortion occurs? Compare that with DPC latency when there's no distortion, do you see any difference?
Magik Mark
26th June 2015, 01:34
Zachs, Is it possible to use DXVA on IMAGE upscaling & downloading? I think this would help low to medium end users
huhn
26th June 2015, 01:44
Garteal fixed it! :thanks:
Just so I understand your test results complete, can you confirm if I got the following correct?
Directsound
MPDN audio only = no distortion
MPDN audio+video = distortion
yes
MPDN audio+video (muted) with MPC-HC audio+video = distortion
yes
MPDN audio+video (muted) with MPC-HC audio only = distortion?
MPDN audio only with MPC-HC audio only = no distortion?
didn't tested this combinations. but i can do this test tomorrow.
As for WASAPI exclusive mode, you mentioned you never got it to work with MPC-HC either, is that correct?
i got issue with wasapi but generally i got audio just rarely some distortions. my guess is that i got distortion when a frame drop/repeate should happen but never did. i just used direct audio without any issue. but i can't remember such big issues.
there is a file that sounds very noisy when used with WASAPI and my soundcard so i guess the WASAPI "driver" are simply broken and can be ignored. ASIO works like a charm on the other hand.
Can you try running DPC latency checker to see if you get any obvious problems when distortion occurs? Compare that with DPC latency when there's no distortion, do you see any difference?
this program doesn't properly work on windows 8 and i'm on windows 10.
i used this program back at my windows 7 times with very low numbers.
i will try to record the issue later i may learn something from it.
Zachs
26th June 2015, 02:14
Zachs, Is it possible to use DXVA on IMAGE upscaling & downloading? I think this would help low to medium end users
It's on my todo list (as with a lot of other stuff) but I just haven't had any spare time to work on it.
EDIT: When I looked into it, I found it to be rather restrictive on what it could do. This hasn't changed AFAIK. For starters, it only accepts 8-bit input/output, which means it is worse in quality (colour correctness wise - i.e. you'll get banding issues, colour shift etc.) when compared to even hardware bilinear scaling with MPDN's "max performance" settings while requiring more processing power. Even on my low power budget device (e.g. Atom Tablet), I prefer MPDN's hardware bilinear (which has full 32-bit colour accuracy) on 10-bit FSE mode over DXVA. With 10-/16-bit sources, you essentially murder the quality when you use DXVA scaling.
huhn
26th June 2015, 11:53
MPDN audio+video (muted) with MPC-HC audio only = distortion?
MPDN audio only with MPC-HC audio only = no distortion?
tested and yes.
Can you try running DPC latency checker to see if you get any obvious problems when distortion occurs? Compare that with DPC latency when there's no distortion, do you see any difference?
i used LatencyMon 6.00: http://www.resplendence.com/downloads
obviously the issue: http://abload.de/img/bingogys3y.png
the high numbers come when the audio distortion appears.
i will let the program run in the background when i next time used madVR for a longer time like 2 h may take some time just to make sure madVR has no problem at all and the issue is limited to MPDN. but a short test with madVR didn't showed any issue.
Zachs
26th June 2015, 12:02
Looks like something in MPDN's video renderer (which has nothing to do with audio) is triggering an audio driver bug. 26ms from interrupt to process is definitely a big problem.
huhn
26th June 2015, 12:38
so i guess nothing to learn from recoding this issue. let's just hope this is not an general issue.
maybe someone with windows 10/windows 8.1 can do a test for this issue too.
you just have to run LatencyMon 6.00 in the background and watch an 24 min episode or something like that.
huhn
26th June 2015, 12:58
i get high numbers in madVR and foobar too (~4000). the only difference is that MPDN has audio issues and the rest not. so the driver are kinda broken or this software doesn't work properly on windows 10.
not sure if it is good to waste time on it.
Magik Mark
27th June 2015, 02:46
zach can we port super xbr in chroma upscaling? I'm getting nicer result compared to jincs in madvr
Anima123
27th June 2015, 04:47
I've tried both NEDI and Super-xBR with SuperRes, the new SuperRes result in a very pleasant picture quality with NEDI, from 1024x576 -> 1920x1080 videos.
Super-xBR is too sharp, the edges of faces sometimes 'harder' than with NEDI.
Also the new algorithm work great without the old rendering time increasing issue, which makes the MPDN an alternative to my choice of daily media players.
madshi
27th June 2015, 09:01
Just a heads-up: Downloaded the standalone version of MPDN and the extension binaries and sources into new folders (using the links from the first post), copied the extensions in the right folders. But now both 32bit and 64bit MPDN complain with "One or more extensions failed to load". I had deleted the old "AppData" MPDN folder. Tried emptying the PlayerExtensions folder, didn't help.
ryrynz
27th June 2015, 10:01
Just a heads-up: Downloaded the standalone version of MPDN and the extension binaries and sources into new folders (using the links from the first post), copied the extensions in the right folders. But now both 32bit and 64bit MPDN complain with "One or more extensions failed to load". I had deleted the old "AppData" MPDN folder. Tried emptying the PlayerExtensions folder, didn't help.
I've run into this a number of times and clearing out appdata and deleting the extensions folders before reinstalling has always fixed it.
I just downloaded latest x64 and x86 versions of MPDN and extensions from http://mpdn.zachsaw.com/Latest/ after completely uninstalling my old installation and I had no errors with either. You might want to try it again.
madshi
27th June 2015, 10:19
I've run into this a number of times and clearing out appdata and deleting the extensions folders before reinstalling has always fixed it.
I just downloaded latest x64 and x86 versions of MPDN and extensions from http://mpdn.zachsaw.com/Latest/ after completely uninstalling my old installation and I had no errors with either. You might want to try it again.
I did all that. But I found what the problem was:
When only using the MPDN standalone version + the binary extensions, everything works fine. But when also extracting the binary source code and copying the binary source code "Extensions" folder over to MPDN, the problem occurs. I guess I'm not supposed to do that? Still, seems like something to look into. The first post looks like I should download and "install" all 3 (standalone version, extension binaries and extension sources). Maybe it would make sense to move the "extension source" to the "Miscellaneous" section on the first page, to make it clearer which downloads are necessary to make the standalone version work with all extensions?
Shiandow
27th June 2015, 12:14
Also the new algorithm work great without the old rendering time increasing issue, which makes the MPDN an alternative to my choice of daily media players.
This is just getting weird now, but I'm glad that it works.
Zachs
27th June 2015, 12:58
I did all that. But I found what the problem was:
When only using the MPDN standalone version + the binary extensions, everything works fine. But when also extracting the binary source code and copying the binary source code "Extensions" folder over to MPDN, the problem occurs. I guess I'm not supposed to do that? Still, seems like something to look into. The first post looks like I should download and "install" all 3 (standalone version, extension binaries and extension sources). Maybe it would make sense to move the "extension source" to the "Miscellaneous" section on the first page, to make it clearer which downloads are necessary to make the standalone version work with all extensions?
I've changed the wording so hopefully that removes any ambiguities.
madshi
27th June 2015, 13:01
Ah, now I understand! I can either use the binary or the source version of the extensions, correct? If that's correct, then the wording should be clear now. Might still make sense to investigate why it gets broken if you install both the binary and source version? I mean, maybe someone installs the binary version first, then wants to switch to the source version, or something. Would be nice if that would still work.
Zachs
27th June 2015, 13:04
Yeah that's correct.
I might just remove the source version from the download section actually. Advanced users can always download them from github.
@Shiandow what do you think?
Shiandow
27th June 2015, 13:26
Yeah that's correct.
I might just remove the source version from the download section actually. Advanced users can always download them from github.
@Shiandow what do you think?
It might be best to remove them if it prevents confusion, although I'm not too happy with making it harder for people to try playing with the code. If possible I'd prefer if MPDN detected such a conflict and asked to remove the binaries (or the sources but it's hard to tell if those have been edited).
Can you install the sources with the installer by the way? Haven't had a chance to try it out yet.
Zachs
27th June 2015, 13:48
No. The installer only installs the binary version. If we want auto update / update checker for the extensions, the only way is to have the binary version, which has a product version that is tied to github release version.
I'll see if there's a way to detect if a conflict has occurred but that's just one of the many mistakes users could make when using the source version. I think end users shouldn't be tinkering with the scripts anyway. Anyone interested in poking around should be knowledgeable enough to download the source from github.
What we can do is perhaps distribute a readme with the binary version with instructions on how to get the source version. Anyone who's interested in poking around would surely have looked into the extensions folder and readme would be the first thing that stands out.
madshi
27th June 2015, 14:08
Maybe you can detect the conflict and change the wording of the message box to guide the user in solving the conflict? E.g. point the user to the readme. The current message box text is very generic and sounds more like some extension is corrupt/damaged.
Shiandow
27th June 2015, 14:11
What we can do is perhaps distribute a readme with the binary version with instructions on how to get the source version. Anyone who's interested in poking around would surely have looked into the extensions folder and readme would be the first thing that stands out.
That might be a good compromise. I still think it's a shame that users would lose the ability to change the extension's behaviour by changing a few lines of code, but maybe nobody did that anyway.
Zachs
27th June 2015, 14:12
Yeah that would be ideal. Just have to find out if it's possible to detect that it's a conflict and not any other errors...
Zachs
27th June 2015, 14:15
That might be a good compromise. I still think it's a shame that users would lose the ability to change the extension's behaviour by changing a few lines of code, but maybe nobody did that anyway.
Oh I think the ones who frequent this thread know how to switch to the source version in a heartbeat when there's something they need / want to change.
The installer is really meant to make it easy for users who simply just want a media player and don't necessary even know much about image scaling, let alone tinkering with it :)
Anima123
28th June 2015, 00:23
With the upgraded version of Super-xBR, I cannot distinguish it from NEDI with SuperRes now. I'd say it becomes as good with one of my test video.
Edit: For other video clips, NEDI still more 'natural' for me.
mrcorbo
28th June 2015, 15:56
Regarding extension versioning, prior to the binaries being implemented was using file hashing ever considered?
Zachs
29th June 2015, 02:29
Yes, but we wanted something more straight forward to start with. File hashing may still be implemented for the source version later. We don't even have an extensions version checker yet at the moment.
mrcorbo
29th June 2015, 14:24
Got it. I have some ideas about a possible process if you don't already have a mechanism in mind.
Zachs
29th June 2015, 14:26
Oh feel free to discuss here. Belphemur is the one looking into it.
Dark Eiri
29th June 2015, 18:39
Is there any way to support GPU acceleration via integrated GPUs like I do with MPC and LAV? On MPC I set LAV to use QuickSync instead of CUDA, that makes my GTX 770 sleepy and silent at 135 MHz Core and uses my HD4600, which has no monitor output (I believe you guys call that "headless GPU"?), to decode everything, . Any way to do that with MPDN so the GTX770 won't go full clock and noisy every time I boot it up? The iGPU doesn't even show up on the Adapters list.
huhn
29th June 2015, 18:50
the adapter is chosen for presentation not for decoding. you can just choice quicksync under lavfilter and MPDN will use it.
Belphemur
29th June 2015, 20:54
I did think of file hashing instead of Timestamp comparison (as how the uninstaller is done for now). Until now I couldn't find a plugin/script for NSIS to generate hash. Now I found a basic CRC32 that should be enough to check for modification.
I can later on make an installer for the source version, but I think this would get a little complicate for the user (and also could lead to some conflict when the framework get changed/refactored).
Anyway I'm open to any ideas !
huhn
29th June 2015, 22:38
i get high numbers in madVR and foobar too (~4000). the only difference is that MPDN has audio issues and the rest not. so the driver are kinda broken or this software doesn't work properly on windows 10.
not sure if it is good to waste time on it.
i disabled the asus sound card and used the AMD GPU as a sound card.
i saw again high interrupt to process values so the asus soundcard isn't the problem. but the real issue is that the values are way way higher with MPDN.
and this is on a completely reinstalled system.
the next thing i will try is switch out the GPU and have a look at the results.
Magik Mark
30th June 2015, 01:26
Zachs how do we activate the dxvahd render?
Zachs
30th June 2015, 04:08
I've just pushed the DXVA HD Scaler render script to github. This is unreleased yet but I'll be making a new MPDN_Extensions release shortly.
For more info, see https://github.com/zachsaw/MPDN_Extensions/wiki/DXVA-HD-Scaler
Anyway, not sure why anyone would want to use it, but you're the boss!
Zachs
30th June 2015, 04:09
i disabled the asus sound card and used the AMD GPU as a sound card.
i saw again high interrupt to process values so the asus soundcard isn't the problem. but the real issue is that the values are way way higher with MPDN.
and this is on a completely reinstalled system.
the next thing i will try is switch out the GPU and have a look at the results.
It sounds like your AMD driver is causing high DPC latency and MPDN may have uncovered a bug in their driver. Is it a beta version?
Dark Eiri
30th June 2015, 05:16
the adapter is chosen for presentation not for decoding. you can just choice quicksync under lavfilter and MPDN will use it.
It is. And still makes my GTX 770 spike all the way to 1045 MHz.
Zachs
30th June 2015, 05:25
It is. And still makes my GTX 770 spike all the way to 1045 MHz.
Do you see only one adapter on your drop down list? You should see 2. On my Win7 machine, I have the iGPU setup as a headless output and I can switch between the two easily. Are you sure MPC even supports using the headless iGPU to render your video? I certainly can't find an option to allow that.
Magik Mark
30th June 2015, 06:07
I've just pushed the DXVA HD Scaler render script to github. This is unreleased yet but I'll be making a new MPDN_Extensions release shortly.
For more info, see https://github.com/zachsaw/MPDN_Extensions/wiki/DXVA-HD-Scaler
Anyway, not sure why anyone would want to use it, but you're the boss!
Thanks you! I'm now able to use file sharp & adaptive sharpen wihout any problem in GTX 550ti. Most of the videos I play are 8bit including blue ray
I have activated debanding and hopefully it would address any banding issues
Zachs
30th June 2015, 06:12
Thanks you! I'm now able to use file sharp & adaptive sharpen wihout any problem in GTX 550ti. Most of the videos I play are 8bit including blue ray
I have activated debanding and hopefully it would address any banding issues
On GTX 550ti, you should just use hardware bilinear for better quality. DXVA HD will actually produce worse quality and is slower at the same time!
mrcorbo
30th June 2015, 06:23
I did think of file hashing instead of Timestamp comparison (as how the uninstaller is done for now). Until now I couldn't find a plugin/script for NSIS to generate hash. Now I found a basic CRC32 that should be enough to check for modification.
I can later on make an installer for the source version, but I think this would get a little complicate for the user (and also could lead to some conflict when the framework get changed/refactored).
Anyway I'm open to any ideas !
When I have some time I'll try to put together a more complete outline of how I think this might work, but mainly it centers on keeping a manifest of all of the extension files with a hash value for each file, the date modified file property as read at the time the current hash value was generated to detect when a file needs to be re-hashed and an additional property to allow users to mark certain extension files as manual update only. This last basically covering cases where the user has modified an extension and doesn't want the updater nagging them about it.
Magik Mark
30th June 2015, 06:28
On GTX 550ti, you should just use hardware bilinear for better quality. DXVA HD will actually produce worse quality and is slower at the same time!
How do I activate hardware bilinear? I could only see bilinear in chroma/luma upscaling/downscaling. It is not found in image scaling
Zachs
30th June 2015, 06:46
It's under "Scaling performed by GPU hardware" --> Bilinear.
nevcairiel
30th June 2015, 07:16
Does AMD implement DXVA HD now? A few years back when I investigated that API, they didn't offer DXVA HD at all.
Zachs
30th June 2015, 07:24
Well it doesn't work on my old 4350 and I haven't bought an AMD product since so I'm not sure really.
EDIT: Anyway, the DXVA HD scaler seems to only benefit Intel GPUs. They can do Bicubic 100 no AR with a bit less power than MPDN (by exactly 0.2W on both up and downscaling on my Intel HD 3000). Even Nvidia is simply using bilinear when scaling and is identical to MPDN's hardware bilinear.
huhn
30th June 2015, 09:20
madVr had problems using the better DXVA scaler too.
intel should be like lanczos 3 ar (8 bit) and amd and nvidia should be better than bilinear too even through amd is bilinear in madVR for me and something better in EVR. but i'm not even sure if you try to use the same API and i don't think they are useful too.
my GPU driver are software suite 15.20-150522a-184226e. the default WDDM 2.0 driver. these are not the 15.20 driver that promise a huge performance boost. the audio problem was older than preview windows 10 so not sure if a driver can be the reason.
huhn
30th June 2015, 09:37
It is. And still makes my GTX 770 spike all the way to 1045 MHz.
maybe your MPDN settings force your GPU to do this for rendering. quicksync headless mode is about decoding only and decoding with quicksync and presentation with EVR has title to no effect on the GPU unlike most better scaler in MPDN.
Do you see only one adapter on your drop down list? You should see 2. On my Win7 machine, I have the iGPU setup as a headless output and I can switch between the two easily. Are you sure MPC even supports using the headless iGPU to render your video? I certainly can't find an option to allow that.
intel quicksync headless mode is window 8+ only and is only about quicksync decoding. on windows 7 you need a fake monitor to access intel quicksync without putting an display to the GPU so this is no true headless mode.
at least he was talking about decoding not rendering. in headless mode the video is still rendered by the other GPU but EVR doesn't have an impact on them.
Zachs
2nd July 2015, 02:49
intel quicksync headless mode is window 8+ only and is only about quicksync decoding. on windows 7 you need a fake monitor to access intel quicksync without putting an display to the GPU so this is no true headless mode.
at least he was talking about decoding not rendering. in headless mode the video is still rendered by the other GPU but EVR doesn't have an impact on them.
Headless mode isn't exactly a technical term - it simply means a display adapter's output that isn't connected to any displays. In both Windows 7 and 8, you can do what you call "fake monitor". There's no need to do that for Win8 if you're just trying to use QuickSync. However, for rendering (and I assume he wanted his iGPU to do the rendering since he asked if it's possible to get his NV card to stay at lowest clock speed) you need to still "fake" a monitor.
It would make more sense if Microsoft simply allowed you to choose an adapter that isn't connected to a display to do the rendering. That's simply how Optimus works anyway.
the comparison was with MPC-HC and there was no word about rendering what so ever.
in the end very high settings are needed to get a 770 gtx to high power state and the intel wouldn't be able to handle it.
do you really think it is a good idea to render frames on a GPU that isn't presentation them.
just look at optimus system and there high present times.
and 8bit UHD@60 would be about 1.4 gigabytes per sec that needs to be transferred to the presentation GPU.
Zachs
2nd July 2015, 10:59
I didn't say it's a good idea but if you insist on rendering on your igpu, you should be allowed to do that. Optimus isn't a good idea but almost all nvidia GPU equipped laptops are optimus these days. Wouldn't be any worse allowing it.
Anyway I was just wondering if he meant rendering, not decoding. Not everyone knows the right jargon to use as you could see in the thread and I was just giving him the benefit of the doubt.
we can only guess. even though CUVID is forcing the GPU in highest powerstate.
Zachs
2nd July 2015, 12:23
@anima123
I've recently bought an old laptop with optimus just to see if I could replicate your problem with increasing render time but running an hour worth of video continuously with 2 pass SuperRes (default prescaler hardware bilinear) hasn't caused the problem. This is with the iGPU presenting and NV rendering. I've also tried directly using the NV GPU to drive its own display (therefore bypassing iGPU) and also found no problem.
Belphemur
2nd July 2015, 13:22
When I have some time I'll try to put together a more complete outline of how I think this might work, but mainly it centers on keeping a manifest of all of the extension files with a hash value for each file, the date modified file property as read at the time the current hash value was generated to detect when a file needs to be re-hashed and an additional property to allow users to mark certain extension files as manual update only. This last basically covering cases where the user has modified an extension and doesn't want the updater nagging them about it.
The next version of the extensions will use a MD5 hash of each file to check for changes. By default, the uninstaller leaves all files that has been modified and the installer doesn't override existing file.
Now this does only work for the Binary version of it. It's possible to create an installer that would use the Source version of it and do the same. But again, since the Extensions are open-source, and we welcome any change/new feature, if you find something troublesome in an extension, feel free to do a pull request or open an issue about it.
Of course, you can also code your own extension and put its file/dll into the Extensions folder and keep it for yourself. (Those file won't be touched by the installer/uninstaller).
Anima123
2nd July 2015, 21:50
@anima123
I've recently bought an old laptop with optimus just to see if I could replicate your problem with increasing render time but running an hour worth of video continuously with 2 pass SuperRes (default prescaler hardware bilinear) hasn't caused the problem. This is with the iGPU presenting and NV rendering. I've also tried directly using the NV GPU to drive its own display (therefore bypassing iGPU) and also found no problem.
Thank you for doing this. I have reported that the rendering time increasing issue has gone with the latest implementation of SuperRes by Shiandow.
Would you please try it with old one to see if you can replicate the issue?
Shiandow
5th July 2015, 17:00
@all
I've made some changes to the algorithms again. Should be available with the next release of the extensions.
SuperRes:
- Improve performance when softness is off (might change image slightly)
- Add HQ downscaling option. This improves quality and seems to work well with the change above.
SuperChromaRes:
- Same performance improvements
- Works in YUV instead of RGB
Debanding:
- Replace the 'margin' setting with something more intelligent. This seems to improve the image, but is still experimental.
Zachs
7th July 2015, 04:33
I really doubt the Microsoft WHQL certification process is working correctly when it comes to Optimus (perhaps they have no idea how to test all the different configs out there) as there have been 3 WHQL releases of R352 branch NVIDIA GPU drivers and certain configs of Optimus still suffer from a critical bug that causes a fault in ntdll.dll when you run certain applications (MPDN x64 is one of them unfortunately). Other apps are also affected - e.g. GPU-Z (32-bit) and Visual Studio 2010/2013 (see this bug report on Microsoft Connect (https://connect.microsoft.com/VisualStudio/feedback/details/1272232/ntdll-dll-crash-in-visual-studio-2013-on-windows-8-1-enterprise-on-laptop-when-using-a-dual-display-setup)).
It is caused by the Nvidia Optimus DLL Injection code (nvinit.dll for 32-bit apps and nvinitx.dll for 64-bit apps). 32-bit processes fail at fault offset 0x000e5624 in ntdll.dll while 64-bit processes fail at fault offset 0x00000000000f0f20. They both have the same exception code 0xc0000374 which means heap corruption.
The fault happens when the following conditions are true:
1) You are using NVIDIA R352 branch drivers (if you revert to R346 it'll work just fine)
2) Laptop is an NVIDIA Optimus laptop
3) Win8.1 (Win7 works fine)
4) Secondary monitor via HDMI (or DVI) output is set to "Extend my desktop" and is set to a different resolution to your laptop screen
5) System has been restarted after you've installed NVIDIA R352 branch drivers. DLL injected codes from nvinit.dll and nvinitx.dll won't get loaded before you reboot as they reside in the registry (AppInit_DLLs).
Workaround:
Remove nvinit.dll and nvinitx.dll in %systemroot%\sysWOW64 and %systemroot%\system32 respectively.
Note that you can't actually delete the files since they get loaded with every single process (including Explorer.exe) - it's DLL injection - so you have to rename the files (e.g. nvinitx.dl_ and nvinit.dl_) and restart. You can then remove the renamed files.
This removes the ability to make your primary screen (or GPU adapter) render with NV GPU and present with your Intel GPU (essentially disables Optimus) but if you setup MPDN to display on the secondary display, your NV GPU will still operate fine.
Other Optimus issues:
Some users have reported other odd behaviours when using MPDN with Optimus. If you believe Optimus is the culprit (it usually is), you can follow the instructions in the above workaround to "disable Optimus".
Anima123
7th July 2015, 07:24
What do you mean by "disable Optimus", especially with single screen settings? Does that mean that I can use nVidia card instead of the integrate one from Intel?
Zachs
7th July 2015, 07:25
No it's the other way around I'm afraid.
foxyshadis
7th July 2015, 09:11
Do you know if it also affects the 353 branch? If so, then I guess I've just been lucky so far.
aren't we still at branch 352? just over 100 driver so they name it 353.xx
nevcairiel
7th July 2015, 10:04
353.30 and .38 are 353 branch
Optimus is just terrible though, it has always been a source of fun problems.
Zachs
7th July 2015, 12:37
I think they're all from the R352 branch, at least according to the NVIDIA download page for my NVS GPU.
I have a feeling it doesn't happen with all Optimus systems out there. Perhaps its got something to do with the resolution of the external display and the laptop built in display. At least on mine the laptop screen is lower res than the external display, so that may be another condition that would cause the bug to manifest itself.
Belphemur
7th July 2015, 14:51
I think they're all from the R352 branch, at least according to the NVIDIA download page for my NVS GPU.
I have a feeling it doesn't happen with all Optimus systems out there. Perhaps its got something to do with the resolution of the external display and the laptop built in display. At least on mine the laptop screen is lower res than the external display, so that may be another condition that would cause the bug to manifest itself.
I have an Asus's Laptop 750GZ with nVidia 880m, Windows 8.1 and driver R353 and a Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz. I don't have this issue. I forced MPDN to be launched with the nVidia GPU in its control panel.
Tried with a Samsung TV using the thunderbolt port. It does also work with the HDMI port. Native resolution of 1080p on both screen.
Edit: Tried with extended, mirrored and only second screen. No issue.
aufkrawall
7th July 2015, 15:10
At least 353.38 is r353 branch for sure:
http://img.techpowerup.org/150707/nvidia_20150707_160849.png
I don't know about 353.30, but I wouldn't recommend to use it since .38 is far better.
Zachs
8th July 2015, 00:03
I have an Asus's Laptop 750GZ with nVidia 880m, Windows 8.1 and driver R353 and a Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz. I don't have this issue. I forced MPDN to be launched with the nVidia GPU in its control panel.
Tried with a Samsung TV using the thunderbolt port. It does also work with the HDMI port. Native resolution of 1080p on both screen.
Edit: Tried with extended, mirrored and only second screen. No issue.
I think it may only affect Win8.1 Enterprise only since the other person who reported VS2013 crashing immediately upon startup is also running the same OS. Perhaps like I said the 1080p native resolution of your laptop screen masks the problem. There must be some additional conditions I'm missing otherwise this problem will be a lot more widespread. Anyway I've submitted a bug report with Nvidia. We'll see where it goes from there.
At least 353.38 is r353 branch for sure:
http://img.techpowerup.org/150707/nvidia_20150707_160849.png
I don't know about 353.30, but I wouldn't recommend to use it since .38 is far better.
There's no .38 for Quadro yet - 353.30 is definitely from the R352 branch: http://www.nvidia.com/download/driverResults.aspx/86953/en-us
Zachs
8th July 2015, 04:09
@all
I've made some changes to the algorithms again. Should be available with the next release of the extensions.
SuperRes:
- Improve performance when softness is off (might change image slightly)
- Add HQ downscaling option. This improves quality and seems to work well with the change above.
SuperChromaRes:
- Same performance improvements
- Works in YUV instead of RGB
Debanding:
- Replace the 'margin' setting with something more intelligent. This seems to improve the image, but is still experimental.
Release v1.9.0 now includes these changes.
Anima123
8th July 2015, 05:50
Release v1.9.0 now includes these changes.
I am not sure what causes this, but the rendering time increasing problem is back with 1.9.0.
Zachs, if possible, would you please verify it with an Optimus laptop?
Zachs
8th July 2015, 06:47
Been running for 21 minutes and no problems yet. SuperChromaRes 2 pass | Strength 1.00 | Softness 0.00 | Use bilateral prescaler checked.
Started 20.50ms, currently still the same render time.
Anima123
8th July 2015, 07:26
I was using SuperChromaRes (1 pass, strength 1.0) + SuperRes (NEDI, 2 passes, Strength 0.7, Softness 0.0, Use HQ downscaling).
The nVidia driver is 353.30.
Zachs
8th July 2015, 07:29
This is the same driver but it's an old laptop so it hasn't got enough grunt to do both SuperChromaRes and SuperRes at the same time. Can you try with just SuperChromaRes with my settings to see if the problem occurs?
EDIT: FWIW I've also just tested 30 minutes of playback with SuperRes (by itself) 2 pass strength 1.0 softness 0.0 with default Prescaler (Use HQ downscaling enabled). All MPDN's scalers set to hardware bilinear. Can you try this too?
Anima123
8th July 2015, 07:31
With "Use HQ downscaling" off, the rendering time increasing disappeared. <== NO LUCKY, STILL THERE
Edit: Sorry, I was wrong about it, the rendering time increase is back.
aufkrawall
9th July 2015, 02:53
Can someone relink the "best" OpenCL -> D3D interop benchmark version?
Results of the new Catalyst would be interesting.
Zachs
9th July 2015, 04:26
http://mpdn.zachsaw.com/Misc/DxClTest12.zip
trandoanhung1991
9th July 2015, 05:58
I'm currently experiencing a problem with the latest builds.
The player would not respond after pausing the video. Steps to reproduce:
Open a video file.
Pause, then alt tab and wait a little bit.
It'll just hang.
Provided is the dumpfile.
ryrynz
9th July 2015, 06:38
The player would not respond after pausing the video.
No problem here. Try a fresh install.
hashanga
9th July 2015, 15:27
Hi,
Is there any way of adjusting the audio offset/delay in MPDN other than remuxing the input file?
(The reason is my bluetooth headset has a 500ms lag with A2DP)
Tried ffdshow with no luck. Both VLC and MPC has this audio sync feature with shortcut keys (also for subtitles) but it'd be really great if MPDN can do this as well.
Shiandow
9th July 2015, 15:46
The LAV audio decode should be able to delay the audio. I don't think there's a way to control it with shortcuts yet.
Zachs
10th July 2015, 01:48
I'll add that to my todo list. In the interim though you can do what Shiandow suggested - LAV Audio Decoder has an audio delay option.
Shiandow
10th July 2015, 09:08
By the way, as far as I can tell the LAV splitter should be able to play http links, but it doesn't seem to be possible to open one in MPDN. Any chance you could have a look at that?
Zachs
10th July 2015, 09:47
Hmm. I'll see what I can do.
Zachs
10th July 2015, 13:20
v2.34.0 should now be able to play http links.
aufkrawall
10th July 2015, 18:54
http://mpdn.zachsaw.com/Misc/DxClTest12.zip
Thanks. Now there'd be just someone here with a Radeon to test the new driver.
Anime Viewer
10th July 2015, 21:33
I'm currently experiencing a problem with the latest builds.
The player would not respond after pausing the video. Steps to reproduce:
Open a video file.
Pause, then alt tab and wait a little bit.
It'll just hang.
I haven't encountered that, but I have encountered a problem where the audio of a video plays, but the video from it halts at whatever frame it was showing when the window was maximized or switched back to the default window size. I tried reinstalling MPDN, and instructed both the main program and the extensions to do a clean install, but oddly it retained the settings. I had to uninstall from control panel and reinstall to clear out the settings. I thought the scripts I was running might be the problem, but even selecting none for scripts it still has the problem.
Anyone else encounter this type of problem? I noticed it starting a handful of versions ago where it seems to sporadically happen.
Keiyakusha
10th July 2015, 21:49
Hey, Zachs, I wonder maybe you can add radio-buttons (or some other stuff) to the chapter select context menu? So that it will show current chapter The reason is that if you have a lot of chapters, it is quite hard to navigate. Especially if chapters don't have specific names. I was watching 2hour+ concert the other day, but wanted to skip some songs... it wasn't the best experience ^^ Using timeline in this case wasn't optimal either (~3mins per song, small gaps between songs)
Garteal
10th July 2015, 21:57
Anyone else encounter this type of problem? I noticed it starting a handful of versions ago where it seems to sporadically happen.
Yeah, I have. Not sure what's causing it exactly. At one time it happened because I changed my refresh rate to 24hz, but now it works fine for example. Usually get to watch something late so I don't get to investigate or report unfortunately.
Keiyakusha
10th July 2015, 22:03
audio of a video plays, but the video from it halts at whatever frame it was showing when the window was maximized or switched back to the default window size.
Yeah, I noticed this. I think this is started somewhere at MPDN 2.3X versions
Zachs
10th July 2015, 23:40
I'll investigate.
aufkrawall
11th July 2015, 01:25
I asked some people to run the benchmark with the new Catalyst 15.7:
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=564983
190fps with a 7870@PCIe 3.0. Is this ok?
CruNcher
11th July 2015, 04:38
Geforce GTX 970
353.30 WHQL WDDM 1.1
http://abload.de/thumb/1080wfgtx9703szm0.png (http://abload.de/image.php?img=1080wfgtx9703szm0.png) http://abload.de/thumb/1080wgtx970zqxno.png (http://abload.de/image.php?img=1080wgtx970zqxno.png)
Zachs
11th July 2015, 04:53
Yeah, AMD's just plain bad when it comes to OpenCL <--> DX interoperability.
Zachs
11th July 2015, 04:56
Anyone else encounter this type of problem? I noticed it starting a handful of versions ago where it seems to sporadically happen.
Can you let me know the steps to replicate the problem? I tried maximizing and restoring the window over and over but can't get it to fail...
CruNcher
11th July 2015, 05:00
So nothing changed there even these days it seems from the results @ 3dcenter AMD seems still not interested improving it ;)
Though i guess the Day Microsoft want's to use DirectCompute for Xbox One Workflows in their Video Pipeline they all gonna run like crazy @ AMD ;)
Keiyakusha
11th July 2015, 07:04
Can you let me know the steps to replicate the problem? I tried maximizing and restoring the window over and over but can't get it to fail...
Here is how it works for me. Some of the steps might be not needed but just in case:
1) start player, open any video (resolution is less than screen size). Seek to any point and close (so that MPDN remember position in video). Close the player.
2) start player again - quick open - select the previous file -> it starts to play from saved position
3) double click inside MPDN window -> enter fullscreen (exclusive mode disabled!)
4) single click inside the window -> video is paused
5) doubleclick inside the window -> windowed mode again, video still paused
6) single click inside the window -> video is paused, audio plays
audio renderer - system default (not MPC)
D3D11 API, Windowed mode rendering path, rely on DWM
Zachs
11th July 2015, 13:01
Hmm I just tried these steps over 5 times but haven't managed to replicate it... Can you get it to occur consistently?
huhn
11th July 2015, 13:15
I asked some people to run the benchmark with the new Catalyst 15.7:
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=564983
190fps with a 7870@PCIe 3.0. Is this ok?
this test is hard blocked by openCL interop so these numbers are meaningless for AMD interm of openCL performence. you only see how fast your PCIe is.
pcie 3 170-210
pcie 2 80-110
the GPU it self doesn't really matter because it doesn't have to do a lot of work.
my nvidia gtx 760 is at about 920 fps and my AMD r9 270 is at about 180 fps but my AMD is still a lot faster in term of nnedi3.
aufkrawall
11th July 2015, 13:27
So the intertop isn't slowed down by the bug after 13.12, but the OpenCL processing itself?
huhn
11th July 2015, 13:56
So the intertop isn't slowed down by the bug after 13.12, but the OpenCL processing itself?
yes the interop issue was always there it's nothing added with a newer driver. 13.12 is just faster at processing.
and if i'm not mistaken madshi tool measured both interop cost and openCL speed.
so AMD will run in troubles at higher resolutions because PCIe isn't fast enough to copy the frames in time but the interop cost doesn't increase with higher neurons.
and the real issue is that some people get for what ever reason very low copy numbers like below 24 FPS even with PCIe 3.
just tested my r9 270 it is at 187 FPS with PCIe 3.
Zachs
11th July 2015, 14:13
The test measures interoperability speed between DX and OpenCL only. There are plenty of tools out there that test OpenCL DirectCompute Shader speeds already and its highly dependent on architecture and driver optimisations and more importantly what algorithm you're testing it with.
Knowing the interop speed is crucial. For example, we now know that at 1080p, it's 190fps for PCI 3.0. At 4k, you get 47.5fps (a lot less than this actually because a renderer needs to upload frames too). So no matter how fast your AMD GPU is, your bottleneck is the PCIe bandwidth.
However, keep in mind that you don't need NNEDI3 at that resolution, so there isn't really any pressing needs for AMD to fix the problem really.
aufkrawall
11th July 2015, 14:26
The non-OpenCL implementation of the extensions is using DirectCompute, right?
Btw: Any chance for Jinc scaling known of madVR in near future? :)
CruNcher
11th July 2015, 15:53
Nvidia definitely learned from their wrong Kepler Compute balance, most algorithm test show that even with the OpenCL Wrapper
only @ optical flow AMD still has a very slight advantage with kishontis used algorithm (though power efficiency uknown) ;)
http://www.videocardbenchmark.net/directCompute.html
http://www.anandtech.com/show/9421/the-amd-radeon-r9-fury-review-feat-sapphire-asus/16
Luxmark OpenCL Rendering has been optimized by Nvidia recently (submited patch, hardware) though no Reviewer is reflecting it yet.
Keiyakusha
11th July 2015, 16:21
Hmm I just tried these steps over 5 times but haven't managed to replicate it... Can you get it to occur consistently?
Yes, it happens every time if I follow these instructions. Just tested with latest MPDN x64. Render scripts were set to none. Not sure what else is there to say. Maybe it is somehow related to the source file, I haven't considered this possibility.
Edit: after some more tests it appears that steps for remembering file position might not be relevant. It also only happens if all the operations was done using mouse. Couldn't replicate with keyboard. Basically when you double click, with left click being responsible for changing screen mode AND play/pause - something happens. I click VERY fast, if that matters.
Anime Viewer
11th July 2015, 19:36
Can you let me know the steps to replicate the problem? I tried maximizing and restoring the window over and over but can't get it to fail...
Here is what my settings are:
General:
Window: Resize window to fit opening media (checked), Reset window size when closing media
Player Extensions (none currently set, but I was using Display Changer and Rate Tuner when I first encountered the problem (so if un-enabling them is buggy, and not completely disabling them that could be a factor - but they probably are disabling properly)
Video Render:
General: all unchecked
Presentation API: Direct3D 11
Graphics Adapter: Mvidia GeForce GTX 680M (LG TV)
Use new windowed mode rendering path when possible (checked)
Composition: Colormetic: Automatic, Range: Full, Bit Depth: 10-bit
Render Scripts: Script Chain: ChromaScaler, Deband, and SuperRes. All default settings for each except for SuperRes (passes 3, strength 1,softness 0, prescaler Super-xBR with settings edge strength 1.00, sharpness 1.00, use third pass (checked)
Dithering: Random (use colored noise unchecked)
Fluid Motion: off
Luma Upscaler: softcubic
chroma upscaler: bicubic
luma downscaler: softcubic
chroma downscaler: softcubic
I open a video, single click on it to pause it, double click on it to full screen it, now if bring the mouse down to hover at the bottom of the screen (displaying the progress bar) it shows the time counter moving (even though it should be paused), and audio can be heard playing. I can then double click to go back to the native screen size and the progress bar will continue to move, the audio will continue to play, and the video continues to stay frozen on the single frame. The window when switching screen sizes lists Paused in the top right corner - which indeed the video is doing, but not the audio. If I continually switch in and out of full screen mode (using the mouse) the video will eventually start moving again, but it will be out of sync with the audio which continues from where it was already playing. It kind of appears that pausing and playing (resuming) may be where the problem lies.
Yes, it happens every time if I follow these instructions. Just tested with latest MPDN x64. Render scripts were set to none. Not sure what else is there to say. Maybe it is somehow related to the source file, I haven't considered this possibility.
Edit: after some more tests it appears that steps for remembering file position might not be relevant. It also only happens if all the operations was done using mouse. Couldn't replicate with keyboard. Basically when you double click, with left click being responsible for changing screen mode AND play/pause - something happens. I click VERY fast, if that matters.
The resume from previously play is not relevant as it occurs for me opening files from the beginning. I have tried numerous files, and I can find nothing that links it to any particular source type.
You're right that using the ALT+Enter key to switch from fullscreen to window and back do not create the paused video effect (if its not already active), but if it is active it will switch window/fullscreen mode with the time and audio problem continuing.
Is your spacebar working to pause/resume play of the video? (Pressing spacebar on my keyboard with the video open does not pause, nor resume the playback like it should. Likewise pressing "." does not stop the video like it should).
patul
12th July 2015, 00:12
Zach,
I got two issues on v2.34.0. One is that after few minutes play in FSE (Win7, D3D 11, 16 bit), I totally lost the screen, it became transparent window with only seek bar is visible, not sure if it's replicable. Second issue, I deleted the MPDN config data in AppData, then I reopen MPDN, I can't seem to Open/Quick Open anything, the error is "Invalid URI: The URI is empty". I can only open via Playlist.
Garteal
12th July 2015, 00:53
Second issue, I deleted the MPDN config data in AppData, then I reopen MPDN, I can't seem to Open/Quick Open anything, the error is "Invalid URI: The URI is empty". I can only open via Playlist.
Replicated this, at least for "Quick open".
This happens when I load an url and I then attempt to "Quick open" with the url last loaded up.
===================================
An unexpected error 'System.UriFormatException' has occurred.
------------------------------
Error Type = System.UriFormatException
Error Message = Invalid URI: The URI is empty.
Error Source = System
Error Site = Void CreateThis(System.String, Boolean, System.UriKind)
Error occurred = at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
at Mpdn.Utilities.FileEx.IsLocal(String fileNameOrUri)
at MediaPlayerDotNet.OpenFileForm.ShowOpenFileDialog(IWin32Window owner, String& fileName)
CruNcher
16th July 2015, 00:22
High Efficiency Performance compare MPDN/MPC-HC (BE) (DX9)
http://i1.sendpic.org/t/n5/n5IgTTye9PJfRhHPdUyOV2ouqQr.jpg (http://sendpic.org/view/1/i/9BXEjgK7NFd3Jn7eJVm9LmOiGwr.png)
http://abload.de/thumb/gpuusagehjl8b.png (http://abload.de/image.php?img=gpuusagehjl8b.png)
MPDN doesn't have a stretch to Window Option ?
Keiyakusha
16th July 2015, 01:38
Btw I have another issue with mouse/keyboard. If I'll press Volume button with a mouse, then whenever i'll press Space on a keyboard, it will be bringing up Volume menu and with the next keypress will mute the sound. And it will keep muting it if i'll try to unmute it. To fix it I have to bring up context menu (RMB)
foxyshadis
16th July 2015, 11:26
Btw I have another issue with mouse/keyboard. If I'll press Volume button with a mouse, then whenever i'll press Space on a keyboard, it will be bringing up Volume menu and with the next keypress will mute the sound. And it will keep muting it if i'll try to unmute it. To fix it I have to bring up context menu (RMB)
So that's why hitting Printscreen muted MPDN today. I was so mystified until I checked the volume.
High Efficiency Performance compare MPDN/MPC-HC (BE) (DX9)
http://i1.sendpic.org/t/n5/n5IgTTye9PJfRhHPdUyOV2ouqQr.jpg (http://sendpic.org/view/1/i/9BXEjgK7NFd3Jn7eJVm9LmOiGwr.png)
http://abload.de/thumb/gpuusagehjl8b.png (http://abload.de/image.php?img=gpuusagehjl8b.png)
MPDN doesn't have a stretch to Window Option ?
Strange, MPC-HC x64 works much better in decoding HEVC 4k 10bit than MPDN x64, both using the same version of LAV.
ryrynz
17th July 2015, 01:30
Strange, MPC-HC x64 works much better in decoding HEVC 4k 10bit than MPDN x64, both using the same version of LAV.
Than x86? Yes that's right. 64 bit FFmpeg has a lot more optimisations for HEVC.
Zachs
17th July 2015, 04:57
Been away for a while but I'm back.
I've replicated the problem with audio continuing to play when video is paused. I'll fix it for next release.
I'll also fix the "sticky" volume button problem as well as the "Quick Open" on fresh install problem.
Than x86? Yes that's right. 64 bit FFmpeg has a lot more optimisations for HEVC.
No, both are x64.
Zachs
17th July 2015, 10:20
No ffdshow in your filter chain?
Don't know, just installed it without modifying anything:
http://phota.me/QfaP.png
I have also noticed that DXVA doesn't work for H.264 4k 8bit.
Zachs
17th July 2015, 11:48
BTW MPDN doesn't support dxva so that may be why you're seeing higher CPU usage. It's in my to do list but haven't got to it just yet.
Zachs
17th July 2015, 14:37
The non-OpenCL implementation of the extensions is using DirectCompute, right?
Btw: Any chance for Jinc scaling known of madVR in near future? :)
No. It's Shader, not DirectCompute.
Yeah madVR jinc is in my todo list. I haven't forgotten about it. It'll be implemented as a render script.
CruNcher
17th July 2015, 19:07
Strange, MPC-HC x64 works much better in decoding HEVC 4k 10bit than MPDN x64, both using the same version of LAV.
That is both a x64 chain it just shows that the most performant render way i could reach with MPDN (by default, configuration) isn't as performant (overhead) efficient as with the EVR Custom Renderer used in MPC-HC/BE BE currently being the most efficient the compare wasn't targeting the quality/performance ratio but entirely reachable 4K System Overhead Performance of the DX9 Render path under WDDM 1.1 ;)
It shows much higher overhead on the CPU and GPU as well (the GPU can't hold the Frequency as low)
This has absolutely nothing todo with DXVA as it wasn't even supported for the tested Bitstream here ;)
Zachs
18th July 2015, 05:06
I'm not sure i understand what you're saying but the default settings won't give you the lowest GPU usage. You'll have to disable dithering, select Max render performance, choose bilinear for all scalers, disable fluid motion etc to make the comparison fair.
CruNcher
18th July 2015, 09:02
i forgot the dithering overhead urghs but i don't think it will be much different overall in the current final results but well see
you should have seen from the screenshot that fluid motion was disabled though also ;)
and still no one answered
MPDN doesn't have a stretch to Window Option ?
Zachs
18th July 2015, 09:18
EVR will always be lighter on resources but you can get near it if you cripple MPDN enough. If lowest GPU usage is an absolute must, MPDN isn't the right tool for you. MPDN avoids shortcuts to give you the best quality possible and this means it doesn't use any of the hardware colour conversion features which would've reduced GPU usage by a larger margin. However, you'll likely get incorrect output if you do.
CruNcher
18th July 2015, 09:21
Thats whats next on the list quality/performance ratio ;)
but currently im pretty surprised about the missing stretch to window option, must be blind i don't find it. ;)
Zachs
18th July 2015, 09:21
It always stretches video to window, and you can choose to override aspect ratio too. Or do you mean something else?
CruNcher
18th July 2015, 09:25
It doesn't see the black boarders on the screen compared to the stretch to window of MPC-HC which maximized does what it should do
EVR will always be lighter on resources but you can get near it if you cripple MPDN enough. If lowest GPU usage is an absolute must, MPDN isn't the right tool for you. MPDN avoids shortcuts to give you the best quality possible and this means it doesn't use any of the hardware colour conversion features which would've reduced GPU usage by a larger margin. However, you'll likely get incorrect output if you do.
It's not only the GPU Overhead but also CPU as well as you can see it was almost @ the end where with MPC-HC there where a lot of resources left
On a Laptop with Batteries MPDN would have seen Power depletion much faster not to speak of a x86 Tablet ;)
Zachs
18th July 2015, 09:29
You mean you want to get rid of letter and pillar boxing? If so, look again ;)
CPU is the same really. The hardware colour conversion feature removes the need for CPU to do a few steps.
CruNcher
18th July 2015, 09:41
i din't found the stretch to window option on the first look around @ the gui (not options) that wasn't a good sign ;)
the [View] part is hmm a little strange
Ahh ok i didn't forget dithering (puh) and i put all the scaler on nearestneighbour even ;)
so the results above are without dithering so everything you mentioned except nearestneighbour instead of billinear for all scaling modes
so everything correct from a performance system overhead measureing point on my side i would say :)
so i stand behind those overhead rendering results for DX9 EX and differences between both i show above ;)
In Presentation
both new windowed and Rely on DWM where disabled
Zachs
18th July 2015, 11:53
Did you set image quality - performance trade-off to Max Performance?
You can set scalers to hardware bilinear - they perform equally as fast as nearest neighbour.
BTW, I just took a look at your screen shots - EVR is using NV12 as input, basically asking LAV to cripple it to NV12 (8-bit) from 10-bit. MPDN is doing full 10-bit input (which is as slow as 16-bit inputs). As such, if you really want to do a fair comparison, you need to make sure LAV is set to output NV12 only - i.e. disable everything else except NV12.
How to remove xy-VSFilter?
sneaker_ger
18th July 2015, 13:09
open command prompt in folder where vsfilter.dll is located with admin rights and enter:
regsvr32 /u vsfilter.dll
aufkrawall
18th July 2015, 16:33
Is there something wrong with max quality mode?
I think in previous versions I could use it together with NNEDI3, but now this isn't possible anymore (neither OpenCL nor the other method). MPDN basically freezes.
burfadel
18th July 2015, 18:58
I've noticed with the latest build when 'Improve Chroma Reconstruction' is enabled, it seems to flare out bright areas of red with a cyan kind of blocky colour. Seems to do this with most sources and is only in full screen exclusive mode. Hard to explain! It didn't do it in earlier versions, though not sure what version the started with.
Anime Viewer
18th July 2015, 22:43
I've noticed with the latest build when 'Improve Chroma Reconstruction' is enabled, it seems to flare out bright areas of red with a cyan kind of blocky colour. Seems to do this with most sources and is only in full screen exclusive mode. Hard to explain! It didn't do it in earlier versions, though not sure what version the started with.
What you are describing sounds like what me and quite a few others experienced quite a while back when Improve Chroma Reconstruction was first put in as an option. It is tied with Video Input Colormetric, and the Automatic setting not correctly switching to the right setting. Try changing your setting from Automatic to one of the PC Range options, and see if that fixes it.
Zachs
19th July 2015, 05:42
Is there something wrong with max quality mode?
I think in previous versions I could use it together with NNEDI3, but now this isn't possible anymore (neither OpenCL nor the other method). MPDN basically freezes.
Hmm I found a problem with the latest version of MPDN breaking NNEDI3 for some video/target resolution but it still plays. Tried both max quality / quality modes and they behave the same way. Max quality mode does require more VRAM but unless you've run out, it won't affect anything. Can you try running just NNEDI3 and not have any other scripts in your chain?
Edit: The issue I mentioned above has been fixed in v2.36.0.
Zachs
19th July 2015, 05:44
I've noticed with the latest build when 'Improve Chroma Reconstruction' is enabled, it seems to flare out bright areas of red with a cyan kind of blocky colour. Seems to do this with most sources and is only in full screen exclusive mode. Hard to explain! It didn't do it in earlier versions, though not sure what version the started with.
Can you give the earlier version a try? I haven't seen any issues like that on my end but I'd like to find out what's changed that could potentially cause it.
burfadel
19th July 2015, 09:04
Can you give the earlier version a try? I haven't seen any issues like that on my end but I'd like to find out what's changed that could potentially cause it.
I'll have a look. Changing to one of the PC Range items like Anime Viewer suggested worked. BT.709 seemed to be the one that handled the extremes the best.
Marnes
19th July 2015, 20:24
For several weeks now, I've often run into the following problem:
start mpdn by opening a video file
close mpdn
repeat several times
at some point, this message appears every next time mpdn starts: http://i.imgur.com/apufyFR.png
reboot to make it go away
I can't tell why or how this happens. Windows 8.1 x64, nvidia gpu, intel integrated display.
Is this the place to report bugs or or is there a better place? Github only has the extensions and zach's private site didn't mention anything last time I checked
Edit: visual studio says it's an access violation in direct3d11 but I can't load the sources or anything
Shiandow
19th July 2015, 21:29
I've noticed with the latest build when 'Improve Chroma Reconstruction' is enabled, it seems to flare out bright areas of red with a cyan kind of blocky colour. Seems to do this with most sources and is only in full screen exclusive mode. Hard to explain! It didn't do it in earlier versions, though not sure what version the started with.
Can you give the earlier version a try? I haven't seen any issues like that on my end but I'd like to find out what's changed that could potentially cause it.
This sounds like a bug I encountered before. There was a divide by zero error somewhere which caused weird artefacts. I thought I'd fixed it by making sure that the thing that became zero was at least 1e-6, by changing the code from "dot(X,Y)" to "max(1e-6, dot(X,Y))", maybe that should be increased to 1e-3. Unfortunately it seems to be a rather rare bug, which makes it difficult to be sure it's fixed.
burfadel
20th July 2015, 04:59
This sounds like a bug I encountered before. There was a divide by zero error somewhere which caused weird artefacts. I thought I'd fixed it by making sure that the thing that became zero was at least 1e-6, by changing the code from "dot(X,Y)" to "max(1e-6, dot(X,Y))", maybe that should be increased to 1e-3. Unfortunately it seems to be a rather rare bug, which makes it difficult to be sure it's fixed.
I'd be happy to test something out. The issue appeared only to affect bright red, like red lights or lights with red in the light covers. I did also notice it in one instance of a more yellow light but I believe had red in it anyway by the looks of it.
madshi
20th July 2015, 08:08
I'd be happy to test something out. The issue appeared only to affect bright red, like red lights or lights with red in the light covers. I did also notice it in one instance of a more yellow light but I believe had red in it anyway by the looks of it.
Samples for things like this are always helpful... :)
burfadel
20th July 2015, 12:13
In the latest version v2.36.0, I've notice something with the Max Quality mode that didn't occur in the previous v2.35.0 version.
When using the experimental adaptive sharpen filter here:
http://forum.doom9.org/showthread.php?t=172131
(experimental 2015-07-14 version linked at the bottom)
the whole player window is green, regardless of in Windowed or Full screen. It is set to pass 1 first :).
The issue only occurs in 'Max Image Quality' mode, it works fine under 'Image Quality' mode. It also only occurs in v2.36.0, v2.35.0 'Max Image Quality' worked perfectly. 'Max Image Quality' works fine without the use of the adaptive sharpen shaders, so I'm guessing it's something in the latest update that has affected how some shaders operate.
Zachs
20th July 2015, 12:55
I've reverted one of the very minor changes in 2.37.0 that is related to Max Quality mode. Let me know if this fixes it.
burfadel
20th July 2015, 13:58
I've reverted one of the very minor changes in 2.37.0 that is related to Max Quality mode. Let me know if this fixes it.
No, the screen is still green when set to Max Quality mode and using that shader. I've tried v2.35 again and it works fine, so the issue is still with v2.36.0/v2.37.0.
bacondither
20th July 2015, 14:13
2.37.0 works fine for me with max image quality and the 2-pass experimental adaptive sharpen.
http://s12.postimg.org/5pv0fuy15/shader.jpg (http://postimg.org/image/5pv0fuy15/)
burfadel
20th July 2015, 14:50
2.37.0 works fine for me with max image quality.
http://s12.postimg.org/5pv0fuy15/shader.jpg (http://postimg.org/image/5pv0fuy15/)
It's only when using the adaptive sharpen experimental shader (it's a separate package as linked by me previously). It could be indicative that other shaders may not behave like they should either.
bacondither
20th July 2015, 14:56
It's only when using the adaptive sharpen experimental shader (it's a separate package as linked by me previously). It could be indicative that other shaders may not behave like they should either.
I'm running the experimental adaptive sharpen in that picture.
burfadel
20th July 2015, 16:33
Ah so you are! It's not for me though, and only in v2.36.0 and v2.37.0. Might be a hardware thing too?
Zachs
21st July 2015, 00:00
I tested it with all 3 versions on both Intel and NVIDIA GPUs and can't replicate your issue - what hardware are you using?
EDIT: Replicated it. Strangely though it's happening with Image Quality mode for me. I'll have a look and see what's causing it.
EDIT2: Looks like the shader code won't work with UNORM textures. I'll add a compatibility mode for Image Processor in the next MPDN extensions release. If you want to quickly patch it to get it working in the current version, simple change line 52 of Mpdn.ImageProcessor.ConfigDialog.cs (https://github.com/zachsaw/MPDN_Extensions/blob/master/Extensions/RenderScripts/Mpdn.ImageProcessor.cs#L52) to the following
// [Existing line] (current, filename) => new ShaderFilter(CompileShader(filename), current));
(current, filename) => new ShaderFilter(CompileShader(filename).Configure(format: TextureFormat.Float16), current));
Zachs
21st July 2015, 03:19
I've just done a commit for the initial version of cylindrical jinc (madVR Jinc). It's a quick and dirty write up (proof of concept) that is still a work in progress and it's only a 4-tap jinc (2 lobed jinc) but as you can see from the code it's written to easily scale to higher tap / lobe count (which will come later).
Feel free to have a play with it and report back if you encounter any problem.
EDIT: It is now complete with 6- and 8-tap options.
Zachs
22nd July 2015, 13:50
Hi guys,
Just a quick note about the latest release.
The latest extensions (v1.10.0) must be used with v2.38.0 or later due to API changes so you'll need to download and install both of them.
Thanks to all the developers, v1.10.0 is the biggest update yet.
[ New ] Jinc (cylindrical) - ala madVR Jinc
- 4- 6- or 8-taps with Anti-ringing
[ New ] AudioSettings player extensions
- Allows MPDN to change audio delay via shortcut keys or context menu
Massive playlist improvements
- New: When a file is in the playlist on load, activate play button
- New: Added the ability to add files to the playlist from the clipboard
- New: Improved handling of media duration
- New: Reposition playlist window if it's entirely offscreen
- New: Added regex to allow filtering in playlist
- New: Added striking or removing previously played files
- New: Various other user interface improvements
- Fixed: Error Message when playing/pausing + crash when loading file
- Fixed: Close Button in Config Regex close the whole Configuration Panel
- Fixed: Playlist positioning can be incorrect in certain cases
- Fixed: Playlist flying out of bounds when undocking in certain cases
- Fixed: Restoring an empty list & only count playCount when playback ends
Update Checker improvements
- New: MPDN and its extensions can now be downloaded within the update window
- New: Various user interface improvements
Image Processor
- New: Compatibility mode option to allow shaders such as adaptive sharpen to work with all quality trade-off modes
MPDN v2.38.0 also fixed the colour flares issues some users had encountered when "Improved Chroma Reconstruction" is enabled. We believe it's good enough to be enabled so this is now the default setting for fresh installs. You may still get adverse effects if your stream flags an incorrect YUV matrix but you can always easily cycle through the different matrices until you get to the correct one. We are not too worried about bad encodes since the adverse effects from ICR would be relatively mild compared to the faded/crushed whites/blacks you'll see anyway.
Have fun and thanks again to all the developers!
Cheers.
Zachs
22nd July 2015, 14:17
For several weeks now, I've often run into the following problem:
start mpdn by opening a video file
close mpdn
repeat several times
at some point, this message appears every next time mpdn starts: http://i.imgur.com/apufyFR.png
reboot to make it go away
I can't tell why or how this happens. Windows 8.1 x64, nvidia gpu, intel integrated display.
Is this the place to report bugs or or is there a better place? Github only has the extensions and zach's private site didn't mention anything last time I checked
Edit: visual studio says it's an access violation in direct3d11 but I can't load the sources or anything
Yes this is the right place to report bugs.
I have tested this several times (over 10 times) and couldn't replicate it. If only a reboot can make it go away, that suggests it's something persistent that would go beyond the life-time of a user-mode application. As such it's unlikely to be an MPDN bug.
burfadel
22nd July 2015, 16:55
Thanks! Works properly now with the Adaptive Sharpen (which has a new version as well).
Volfield
22nd July 2015, 19:06
TITLE: SharpDX Error
------------------------------
An unexpected error 'SharpDX.SharpDXException' has occurred.
------------------------------
ADDITIONAL INFORMATION:
HRESULT: [0x80070057], Module: [General], ApiCode: [E_INVALIDARG/Invalid Arguments], Message: Parametr jest niepoprawny.
(SharpDX)
------------------------------
BUTTONS:
&Abort
------------------------------
Presentation API: Direct3D 10.1, image quality: render performance (on image quality play fine) , GF GT 320M , Win7x64
EDIT: Problem 2:
image quality: render performance, XySubfilter -> subtitles ok
image quality: image quality, XySubfilter -> black rectangle around subtitles.
Shiandow
22nd July 2015, 20:11
Presentation API: Direct3D 10.1, image quality: render performance (on image quality play fine) , GF GT 320M , Win7x64
EDIT: Problem 2:
image quality: render performance, XySubfilter -> subtitles ok
image quality: image quality, XySubfilter -> black rectangle around subtitles.
Have you tried updating the extensions?
Volfield
22nd July 2015, 20:27
With MPDN-Extensions_v1.10.0 and without it the same problem.
aufkrawall
22nd July 2015, 22:16
Max quality with NNEDI3 is now fixed here with new versions. :)
Aren't MPDN and madVR supposed to look equal with bicubic 75 scaling w.o. AR?
MPDN is somehow much softer.
MPDN:
http://abload.de/thumb/mpdnxtzza.png (http://abload.de/image.php?img=mpdnxtzza.png)
madVR:
http://abload.de/thumb/madvrf8ysp.png (http://abload.de/image.php?img=madvrf8ysp.png)
Dithering, render script etc. is all disabled.
Zachs
23rd July 2015, 00:12
Presentation API: Direct3D 10.1, image quality: render performance (on image quality play fine) , GF GT 320M , Win7x64
EDIT: Problem 2:
image quality: render performance, XySubfilter -> subtitles ok
image quality: image quality, XySubfilter -> black rectangle around subtitles.
I have an NVS 4200M (Optimus) and a 8400GS (which is way older than yours) and on both of these machines I couldn't reproduce either problem. I've also tested it on Intel HD3000 and P4600, and an AMD HD 4350 without any problems.
Are you running the latest drivers?
Zachs
23rd July 2015, 00:21
Max quality with NNEDI3 is now fixed here with new versions. :)
Aren't MPDN and madVR supposed to look equal with bicubic 75 scaling w.o. AR?
MPDN is somehow much softer.
MPDN:
http://abload.de/thumb/mpdnxtzza.png (http://abload.de/image.php?img=mpdnxtzza.png)
madVR:
http://abload.de/thumb/madvrf8ysp.png (http://abload.de/image.php?img=madvrf8ysp.png)
Dithering, render script etc. is all disabled.
I have no idea what madVR's bicubic is but MPDN's bicubic was explained some time ago in this thread.
To reiterate, MPDN's bicubic follows the "Keys Filters" line in the image you can find on this page - http://www.imagemagick.org/Usage/filter/#mitchell
If you want sharper image, go with Lanczos, or move the sharpness bar to 100.
ryrynz
23rd July 2015, 00:34
Aren't MPDN and madVR supposed to look equal with bicubic 75 scaling w.o. AR?
MPDN is somehow much softer.
Noo, noo. If you want to "match" madVR's Bicubic 75 then move up to Bicubic 100.
ryrynz
23rd July 2015, 00:45
Hey Zach, when doing comparisons I missed the ability for MPDN to change the video frame size while in full screen, can you add that? Use the same values as "fit to"
Also can you add the OGM extension to the file list support?
Zachs
23rd July 2015, 00:51
You mean the video letter boxing option?
I'll make an enhancement request on GitHub.
aufkrawall
23rd July 2015, 01:05
Noo, noo. If you want to "match" madVR's Bicubic 75 then move up to Bicubic 100.
Thanks, gonna try it. I'd like to compare Robidoux-Sharp chroma scaling to madVR Jinc under clean circumstances.
ryrynz
23rd July 2015, 01:38
Thanks, gonna try it. I'd like to compare Robidoux-Sharp chroma scaling to madVR Jinc under clean circumstances.
Cool. Post your results, it'd be appreciated.
Hey Zach could double clicking on the window to enter fullscreen not be detected as play and pause events and thus avoid displaying as such on the OSD?
Zachs
23rd July 2015, 02:45
Cool. Post your results, it'd be appreciated.
Hey Zach could double clicking on the window to enter fullscreen not be detected as play and pause events and thus avoid displaying as such on the OSD?
No. There's no way to differentiate double-clicking vs single clicking - single click happens before double-click occurs so unless you can predict the future, you'll have to use a timer but the last I tried it's both unreliable and causes single click events to be delayed so much it's annoying to use.
ryrynz
23rd July 2015, 03:51
No. There's no way to differentiate double-clicking vs single clicking
Okay. What I've noticed is that MPDN when switching from windowed to fullscreen exclusive with any D3D version @8-bit performs a double blinking of the image before finishing the scale.
If comparing t MPC-BE/madVR with similar settings the transition is IMO seamless. Windowed mode with MPDN of course goes fullscreen perfectly as expected.
Also, thoughts on being able to configure LAV from within MPDN even when a file isn't active? Basically keeping the filters options in the context menu active for selection?
Volfield
23rd July 2015, 05:45
I have an NVS 4200M (Optimus) and a 8400GS (which is way older than yours) and on both of these machines I couldn't reproduce either problem. I've also tested it on Intel HD3000 and P4600, and an AMD HD 4350 without any problems.
Are you running the latest drivers?
Yes 341.44.
More details:
===================================
An unexpected error 'SharpDX.SharpDXException' has occurred.
------------------------------
Error Type = SharpDX.SharpDXException
Error Message = HRESULT: [0x80070057], Module: [General], ApiCode: [E_INVALIDARG/Invalid Arguments], Message: Parametr jest niepoprawny.
Error Source = SharpDX
Error Site = Void CheckError()
Error occurred = w SharpDX.Result.CheckError()
w SharpDX.Direct3D11.Device.OpenSharedResource(IntPtr hResource, Guid returnedInterface, IntPtr& resourceOut)
w SharpDX.Direct3D11.Device.OpenSharedResource[T](IntPtr resourceHandle)
w Mpdn.D3D9VideoRenderer.FrameComposer.Dx11.FrameComposer.†††
†††‡ś™(IntPtr )
w Mpdn.D3D9VideoRenderer.FrameComposer.Dx11.FrameComposer.SetRendererRenderTargets(RenderTarget[] rendererRenderTargets)
w Mpdn.D3D9VideoRenderer.VideoRenderer.†††
†††•()
w Mpdn.D3D9VideoRenderer.VideoRenderer.†††
†††‡(Boolean )
w Mpdn.D3D9VideoRenderer.VideoRenderer.SetVideoParams(String videoFileName, FrameBufferInputFormat inputFormat, Int32 width, Int32 height, Int32 aspectRatioX, Int32 aspectRatioY, InterlaceFlags interlaceFlags, Double fps)
w Mpdn.VideoPlayer.VideoPlayer.†††
†††‰–™(String , FrameBufferInputFormat , Int32 , Int32 , YuvColorimetric , InterlaceFlags , PointF )
w Mpdn.VideoPlayer.VideoPlayer.Load(String fileName, LoadParams loadParams)
w MediaPlayerDotNet.MainForm.†††
†††‡†’(String )
w MediaPlayerDotNet.MainForm.LoadMedia(String fileName, Boolean resizeWindowToFit, Boolean play, Boolean showOsd)
w MediaPlayerDotNet.MainForm.OpenMedia(String filename, Boolean play, Boolean showOsd, Boolean allowResize)
w MediaPlayerDotNet.MainForm.†††
†††‡†›(Object , EventArgs )
w System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
w System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
w System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
w System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
w System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
w System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
w System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
w System.Windows.Forms.Control.WndProc(Message& m)
w System.Windows.Forms.ToolStrip.WndProc(Message& m)
w System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
w System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
OS Version = Microsoft Windows NT 6.1.7601 Service Pack 1
Total Physical Memory = 8 GB
Available Physical Memory = 6,1 GB
Date Time = 2015-07-23 06:41:52
User Name = HPDV6-2120EW\Michał
Application Startup Path = C:\Program Files\MPDN
Application Executable Path = C:\Program Files\MPDN\MediaPlayerDotNet.exe
CurrentDirectory = C:\Program Files\MPDN
SystemDirectory = C:\Windows\system32
Ran As Admin = True
HasShutdownStarted = False
MachineName = HPDV6-2120EW
ProcessorCount = 4
LogicalDrives = C:\, D:\, E:\, F:\, Y:\, Z:\
EnvironmentVariables = COMPUTERNAME = HPDV6-2120EW; USERPROFILE = C:\Users\Michał; HOMEPATH = \Users\Michał; LOCALAPPDATA = C:\Users\Michał\AppData\Local; PSModulePath = C:\Windows\system32\WindowsPowerShell\v1.0\Modules\; PROCESSOR_ARCHITECTURE = AMD64; Path = C:\ProgramData\Oracle\Java\javapath;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Bandizip\7z; CommonProgramFiles(x86) = C:\Program Files (x86)\Common Files; ProgramFiles(x86) = C:\Program Files (x86); PROCESSOR_LEVEL = 6; windows_tracing_flags = 3; LOGONSERVER = \\HPDV6-2120EW; PATHEXT = .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC; HOMEDRIVE = C:; SystemRoot = C:\Windows; SESSIONNAME = Console; ALLUSERSPROFILE = C:\ProgramData; PUBLIC = C:\Users\Public; FP_NO_HOST_CHECK = NO; APPDATA = C:\Users\Michał\AppData\Roaming; PROCESSOR_REVISION = 2502; USERNAME = Michał; CommonProgramW6432 = C:\Program Files\Common Files; ESET_OPTIONS = ; CommonProgramFiles = C:\Program Files\Common Files; OS = Windows_NT; PROCESSOR_IDENTIFIER = Intel64 Family 6 Model 37 Stepping 2, GenuineIntel; ComSpec = C:\Windows\system32\cmd.exe; SystemDrive = C:; TEMP = C:\Users\MICHA~1\AppData\Local\Temp; ProgramFiles = C:\Program Files; NUMBER_OF_PROCESSORS = 4; windows_tracing_logfile = C:\BVTBin\Tests\installpackage\csilogfile.log; TMP = C:\Users\MICHA~1\AppData\Local\Temp; ProgramData = C:\ProgramData; ProgramW6432 = C:\Program Files; windir = C:\Windows; USERDOMAIN = HPDV6-2120EW
RuntimeVersion = 4.0.30319.42000
Thread Count = 45
Handle Count = 573
VM Size = 885,2 MB
Peak VM Size = 885,7 MB
Working Set Size = 140,6 MB
Max Working Set Size = 1,3 MB
Min Working Set Size = 200 KB
Modules = MediaPlayerDotNet.exe, ntdll.dll, MSCOREE.DLL, KERNEL32.dll, KERNELBASE.dll, ADVAPI32.dll, msvcrt.dll, sechost.dll, RPCRT4.dll, mscoreei.dll, SHLWAPI.dll, GDI32.dll, USER32.dll, LPK.dll, USP10.dll, IMM32.DLL, MSCTF.dll, VERSION.dll, clr.dll, MSVCR120_CLR0400.dll, mscorlib.ni.dll, ole32.dll, CRYPTBASE.dll, uxtheme.dll, System.ni.dll, System.Core.ni.dll, clrjit.dll, OLEAUT32.dll, System.Drawing.ni.dll, System.Windows.Forms.ni.dll, CRYPTSP.dll, rsaenh.dll, RpcRtRemote.dll, nlssorting.dll, bcrypt.dll, comctl32.dll, dwmapi.dll, System.Configuration.ni.dll, System.Xml.ni.dll, gdiplus.dll, WindowsCodecs.dll, shell32.dll, System.Xml.Linq.ni.dll, VideoFrameServicesNative.dll, MediaInfo.dll, d3d9.dll, d3d8thk.dll, nvd3dumx.dll, PSAPI.DLL, D3D9NativeServices.dll, SETUPAPI.dll, CFGMGR32.dll, DEVOBJ.dll, AVRT.dll, dxva2.dll, WINMM.dll, WTSAPI32.dll, opencl.dll, powrprof.dll, WINSTA.dll, dxgi.dll, WINTRUST.dll, CRYPT32.dll, MSASN1.dll, d3d11.dll, nvopencl.dll, WS2_32.dll, NSI.dll, diasymreader.dll, nvapi64.dll, nvwgf2umx.dll, Dx11Font.dll, FW1FontWrapper.dll, DWrite.dll, bcryptprimitives.dll, CLBCatQ.DLL, quartz.dll, LAVSplitter.ax, avformat-lav-56.dll, avcodec-lav-56.dll, avresample-lav-2.dll, avutil-lav-54.dll, libbluray.dll, qcap.dll, sxs.dll, XySubFilter.dll, COMDLG32.dll, WINSPOOL.DRV, WININET.dll, api-ms-win-downlevel-user32-l1-1-0.dll, api-ms-win-downlevel-shlwapi-l1-1-0.dll, api-ms-win-downlevel-version-l1-1-0.dll, api-ms-win-downlevel-normaliz-l1-1-0.dll, normaliz.DLL, iertutil.dll, api-ms-win-downlevel-advapi32-l1-1-0.dll, USERENV.dll, profapi.dll, LAVVideo.ax, swscale-lav-3.dll, avfilter-lav-5.dll, CallbackFilter.ax, qedit.dll, MSVFW32.dll, LAVAudio.ax, devenum.dll, URLMon.DLL, api-ms-win-downlevel-ole32-l1-1-0.dll, MpcAudioRenderer.ax, OLEACC.dll, MMDevApi.dll, PROPSYS.dll, DDRAW.dll, DCIMAN32.dll, AUDIOSES.DLL, Microsoft.VisualBasic.ni.dll, System.Management.ni.dll, SspiCli.dll
===================================
HRESULT: [0x80070057], Module: [General], ApiCode: [E_INVALIDARG/Invalid Arguments], Message: Parametr jest niepoprawny.
(SharpDX)
------------------------------
Program Location:
w SharpDX.Result.CheckError()
w SharpDX.Direct3D11.Device.OpenSharedResource(IntPtr hResource, Guid returnedInterface, IntPtr& resourceOut)
w SharpDX.Direct3D11.Device.OpenSharedResource[T](IntPtr resourceHandle)
w Mpdn.D3D9VideoRenderer.FrameComposer.Dx11.FrameComposer.†††
†††‡ś™(IntPtr )
w Mpdn.D3D9VideoRenderer.FrameComposer.Dx11.FrameComposer.SetRendererRenderTargets(RenderTarget[] rendererRenderTargets)
w Mpdn.D3D9VideoRenderer.VideoRenderer.†††
†††•()
w Mpdn.D3D9VideoRenderer.VideoRenderer.†††
†††‡(Boolean )
w Mpdn.D3D9VideoRenderer.VideoRenderer.SetVideoParams(String videoFileName, FrameBufferInputFormat inputFormat, Int32 width, Int32 height, Int32 aspectRatioX, Int32 aspectRatioY, InterlaceFlags interlaceFlags, Double fps)
w Mpdn.VideoPlayer.VideoPlayer.†††
†††‰–™(String , FrameBufferInputFormat , Int32 , Int32 , YuvColorimetric , InterlaceFlags , PointF )
w Mpdn.VideoPlayer.VideoPlayer.Load(String fileName, LoadParams loadParams)
w MediaPlayerDotNet.MainForm.†††
†††‡†’(String )
w MediaPlayerDotNet.MainForm.LoadMedia(String fileName, Boolean resizeWindowToFit, Boolean play, Boolean showOsd)
w MediaPlayerDotNet.MainForm.OpenMedia(String filename, Boolean play, Boolean showOsd, Boolean allowResize)
w MediaPlayerDotNet.MainForm.†††
†††‡†›(Object , EventArgs )
w System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
w System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
w System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
w System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
w System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
w System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
w System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
w System.Windows.Forms.Control.WndProc(Message& m)
w System.Windows.Forms.ToolStrip.WndProc(Message& m)
w System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
w System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Zachs
23rd July 2015, 06:38
Yes 341.44.
More details:
Ah ok reproduced the problem. Will get it fixed thanks!
Anima123
23rd July 2015, 06:49
Are there api changes for the latest extensions in Github? Running MPDN result in error messages as follow:
Error
One or more extensions failed to load!
The extensions you have installed may be incompatible with the current version of MPDN.
...
Zachs
23rd July 2015, 07:15
No, one of the devs stuffed it up. :)
Don't use the unreleased source for now until it's fixed.
Zachs
23rd July 2015, 07:30
Also, thoughts on being able to configure LAV from within MPDN even when a file isn't active? Basically keeping the filters options in the context menu active for selection?
Add a request on GitHub.
ryrynz
23rd July 2015, 08:26
Running MPDN result in error messages as follow:
Error One or more extensions failed to load!
Yeah got that earlier today, didn't bother reporting it as they know what's up, figured I'd just wait it out.
Add a request on GitHub.
Will do.
ryrynz
23rd July 2015, 08:34
Zach could you make the OSD only display when the player switches to fullscreen after loading a file when 'launch media in fullscreen mode' is active?
I got a nice big OSD flashing up for a moment before it changed to fullscreen.
Belphemur
23rd July 2015, 09:51
Yeah got that earlier today, didn't bother reporting it as they know what's up, figured I'd just wait it out.
Will do.
Sorry for this, it was my doing. I upgraded to the last version of Visual Studio and didn't pay attention that I was using the C# syntax (that isn't supported by MPDN). I commited my changes to correct this. Now the source version available on github works with MPDN.
ryrynz
23rd July 2015, 10:36
Sorry for this, it was my doing. I upgraded to the last version of Visual Studio and didn't pay attention that I was using the C# syntax (that isn't supported by MPDN). I commited my changes to correct this. Now the source version available on github works with MPDN.
Yeah, I've been following that :) I've encountered this a few times already during MPDN's development so no big deal.
I suppose though if the main branch is going to be considered kinda stable (I think that might be the case) it could be worth giving the code a quick test first before submitting for a merge.
Also Garteal got caught out not submitting the regex config fix both you and I gave him a heads up on before 1.10 got released, so it's probably good practice
to make sure the submission is stable. But hey, it's not like it's a drama if it isn't. Everyone seems to be pretty hot on the code here.. quite refreshing really.
Zach is it possible to give the master a version number so the updater doesn't prompt to update the extensions to the latest released possibly earlier code version? Perhaps all commits could add 0.0.1 or 0.0.0.1?
Whatever works..
Zachs
23rd July 2015, 13:18
Zach could you make the OSD only display when the player switches to fullscreen after loading a file when 'launch media in fullscreen mode' is active?
I got a nice big OSD flashing up for a moment before it changed to fullscreen.
It only shows the OSD after going to fullscreen mode. In fact, the code to switch to fullscreen comes before the OSD display code...
Zachs
23rd July 2015, 13:21
Zach is it possible to give the master a version number so the updater doesn't prompt to update the extensions to the latest released possibly earlier code version? Perhaps all commits could add 0.0.1 or 0.0.0.1?
Whatever works..
You mean when you're using the source code instead of the binaries? If so can you put a request on GitHub to get the update checker to auto disable when the source version is used?
Zachs
23rd July 2015, 13:46
Presentation API: Direct3D 10.1, image quality: render performance (on image quality play fine) , GF GT 320M , Win7x64
EDIT: Problem 2:
image quality: render performance, XySubfilter -> subtitles ok
image quality: image quality, XySubfilter -> black rectangle around subtitles.
The first issue you encountered has now been fixed.
Problem #2 I can't reproduce though...
ryrynz
23rd July 2015, 14:03
You mean when you're using the source code instead of the binaries? If so can you put a request on GitHub to get the update checker to auto disable when the source version is used?
Will do. Could be an idea just ignoring the latest binary releases I guess.
It only shows the OSD after going to fullscreen mode. In fact, the code to switch to fullscreen comes before the OSD display code...
There's something funky going on there.. maybe it had reached fullscreen mode at the time it displayed the OSD, the OSD did stretch though on resize.
aufkrawall
23rd July 2015, 18:00
Sinc-Blackman 8 taps w.o. AR seems to be a great chroma scaler.
MPDN S-B:
http://abload.de/thumb/mpdns-b8hju3h.png (http://abload.de/image.php?img=mpdns-b8hju3h.png)
madVR Jinc3AR:
http://abload.de/thumb/madvrjincartiupp.png (http://abload.de/image.php?img=madvrjincartiupp.png)
But enabling AR filter of MPDN is a bad idea for chroma, it becomes blurry by this.
Btw: Bicubic 50 in madVR is pretty much bicubic 100 in MPDN.
Volfield
23rd July 2015, 18:10
The first issue you encountered has now been fixed.
Problem #2 I can't reproduce though...
Is there any way for me to help you find solution?
P.S. screenshots include
aufkrawall
23rd July 2015, 18:40
I just discovered that the OpenCL implementation of NNEDI3 looks worse than the other.
OpenCL:
http://abload.de/thumb/mpdnopencl21sef.png (http://abload.de/image.php?img=mpdnopencl21sef.png)
PS5.0:
http://abload.de/thumb/mpdnjpsb7.png (http://abload.de/image.php?img=mpdnjpsb7.png)
(look at the doorframe, image is exactly doubled per axis)
Is it supposed to be that way? MPDN OpenCL and madVR OpenCL look the same. btw.
Anima123
23rd July 2015, 18:59
More aliasing in OpenCL version. BTW, does madVR have PS 5.0 implementation of NNEDI3?
aufkrawall
23rd July 2015, 19:11
More aliasing in OpenCL version.
Exactly.
BTW, does madVR have PS 5.0 implementation of NNEDI3?
No, but madshi is not against it (however, no etas as usual).
Btw: I'd really love to see options in the MPDN GUI/extensions for defining doubling/quadrupling settings like in madVR. :)
madshi
23rd July 2015, 22:12
I just discovered that the OpenCL implementation of NNEDI3 looks worse than the other.
It's always dangerous to base such conclusions on just one image... ;)
Without having looked into the matter, one wild guess would be that the OpenCL implementation might scale X first while PS5.0 might scale Y first, or vica versa. Doing that will change the angle of the lines, which can have a huge impact on the aliasing, especially when using a low neuron count.
You could try rotating the image 90° before scaling, as a double check. Does that make the two variants look identical?
aufkrawall
23rd July 2015, 22:51
lul what
Nice guess, sir! :eek:
OpenCL:
http://abload.de/thumb/openclj6beh.png (http://abload.de/image.php?img=openclj6beh.png)
PS5.0:
http://abload.de/thumb/ps56jymw.png (http://abload.de/image.php?img=ps56jymw.png)
Zachs
24th July 2015, 00:41
Is there any way for me to help you find solution?
P.S. screenshots include
The screenshots links are broken but do you get this problem with every file with subtitles or just specific ones?
Zachs
24th July 2015, 00:51
Btw: I'd really love to see options in the MPDN GUI/extensions for defining doubling/quadrupling settings like in madVR. :)
The "Conditional" script was created exactly for such a thing.
You can easily replicate madVR's simple behaviour with it but it's a lot more powerful - e.g. you can double with NNEDI3, then double again with NEDI or Super-xBR (or with NNEDI3 again, with the same or different number of neurons), only when it's required. Or you can have 3 in the chain to give you 8x, or 4 to get 16x etc.
Zachs
24th July 2015, 01:05
lul what
Nice guess, sir! :eek:
Yes, it depends on which direction it scales first (and OclNNEDI3 is the opposite of the SM5 version). The second pass will result in lower quality. It may be a good idea then to scale first pass with higher neurons.
Go ahead and create a request on GitHub for separate neuron settings for each pass. Either Shiandow or myself could add the feature when we get to it. Or anyone else who wants to have a play with the render script. It's a very small change so might be a good place to start if you want to learn.
Zachs
24th July 2015, 01:14
BTW, while we're on the subject, has anyone noticed the SM5 NNEDI3 is now around 10% faster with the same neurons vs OpenCL with the recent Nvidia drivers? At least on my Fermi cards, it was neck and neck (with SM5 just a touch faster) when we first implemented it. We haven't updated the NNEDI3 code and the only thing that's changed would've been the drivers. Just wondering if anyone's noticed the speed improvements.
Volfield
24th July 2015, 04:47
The screenshots links are broken but do you get this problem with every file with subtitles or just specific ones?
http://imgur.com/LQKSGcr,sxEUjSs#0
Every file(ass,str,txt).
Zachs
24th July 2015, 05:04
That's strange. I just can't replicate the problem on any of my systems...
Do you have any render scripts running?
Could you send me your config folder so I could try and see if there's anything else that might be needed to trigger the problem?
Volfield
24th July 2015, 05:09
That's strange. I just can't replicate the problem on any of my systems...
Do you have any render scripts running?
Could you send me your config folder so I could try and see if there's anything else that might be needed to trigger the problem?
https://mega.nz/#!pZ0QXbDA!Dg2YFWkspvLcjTkkflARqmC-ClQdipsmc7y9y3UQHeU
Anima123
24th July 2015, 05:30
When using nnedi3 as image doubler, the resulted image has a lot of little cubic as mosaic, look like the following
https://www.dropbox.com/s/mukmjum4o9dphld/MPDN_nnedi3_mosaic.png?dl=0
There's no similar problem with madVR.
nVidia 880M with 350.30 driver, windows 8.1 64-bit.
Zachs
24th July 2015, 05:38
Does this happen with all the files or just this?
Anima123
24th July 2015, 05:41
Just tested with lower resolution videos, no this effect.
The one that I found that has this problem is when upscaling 1024x576 -> 1920x1080. Not sure other resolutions been affected though.
Zachs
24th July 2015, 05:47
Just created an image with a resolution of 1024x576 to test. I'm not seeing the mosaic effect with either NNEDI3 implementation. LAV Video Decoder set to NV12 only to simulate the typical video file output format. I've also tried with the various settings of different scalers, with or without super res etc.
NVS 4200M with 353.30, Win8.1 64-bit too.
EDIT: Are you by any chance using Bicubic 100 AR chroma upscaling? I think I found a problem with it but I don't understand why... It seems setting sharpness to 99 fixes it, if that's the same problem.
EDIT2: Nevermind. Found the cause. Will be fixed in the next release. As a temporary workaround, don't use the same settings for upscaler and downscaler. For example, if you use bicubic 100 for upscaler, and you want to use the same for downscaler, select 99 for sharpness instead. It's to do with how MPDN caches weights for render scripts.
Zachs
24th July 2015, 05:52
https://mega.nz/#!pZ0QXbDA!Dg2YFWkspvLcjTkkflARqmC-ClQdipsmc7y9y3UQHeU
I just tested your config file with Image Quality set as trade-off mode and it works fine... Not sure why you're seeing the problem. That's especially strange since both Image Quality and Render Performance modes use the UNORM textures thus share the exact same code.
Belphemur
24th July 2015, 09:40
Is there any way for me to help you find solution?
P.S. screenshots include
Which version of XySubFilter are you using ?
aufkrawall
24th July 2015, 17:24
Shiandow, do you want to take a look at this sample?
It has severe banding which gives your deband filter a real struggle.
http://www18.zippyshare.com/v/0Jil84gy/file.html
Shiandow
24th July 2015, 17:37
Shiandow, do you want to take a look at this sample?
It has severe banding which gives your deband filter a real struggle.
http://www18.zippyshare.com/v/0Jil84gy/file.html
You need something more than a debanding filter to get rid of banding that bad. Heck even I am not sure if some of it may not have been intentional (the circular band accros Turkey and Syria sure seems to be). It might be better to use a denoising filter for this.
aufkrawall
24th July 2015, 18:01
madVR deband with most aggressive settings takes mostly care of it. :)
I think the banding accross Turkey and Syria is because of some kind of vignette effect. Yes, it's terrible content, but I think it's still "unwanted" banding.
Volfield
24th July 2015, 19:27
Which version of XySubFilter are you using ?
XysubFiler 3.1.0.705
Shiandow
24th July 2015, 23:14
madVR deband with most aggressive settings takes mostly care of it. :)
I think the banding accross Turkey and Syria is because of some kind of vignette effect. Yes, it's terrible content, but I think it's still "unwanted" banding.
Well I agree that it's unwanted, I'm just not sure how to classify it, it really seems to be closer to 'noise' than simple banding. If it had occurred in a reliable source I'd have concluded that it was meant to be there. It's also interesting to note that MadVR set to high starts to remove the 'intentional' band across Turkey and Syria, and even MadVR doesn't successfully remove all the banding.
By the way, if you haven't tried it already, there's been a very recent update to the debanding filter which might help a little (although fixing this image is till beyond it). It should be available in the next release of the extensions, or you can just download the source.
Anyway, thanks for the feedback!
Marnes
24th July 2015, 23:15
Yes this is the right place to report bugs.
I have tested this several times (over 10 times) and couldn't replicate it. If only a reboot can make it go away, that suggests it's something persistent that would go beyond the life-time of a user-mode application. As such it's unlikely to be an MPDN bug.
Guess it must be a video driver problem or something then...
On a different note, will there be improvements to startup speed and such soon? I've been a big fan of mpdn for a while now because the image quality is so good, resource usage is low and the fluid motion filtering is just perfect, but I didn't realize until I installed potplayer that mpdn easily takes 5x as long to open and start playing. Even with my fast ssd, mpdn takes kinda annoyingly long to open when you're trying to go through many files. I tried to look for a replacement for fluid motion (the main reason I don't want to use other players anymore) but all that's available is interframe (haloing artifacts and different end goal) and other avisynth stuff (tedious to set up).
burfadel
24th July 2015, 23:53
Not sure what version of NET Framework it is compiled in. Not sure if compiling with NET Framework 4.6 (Windows 10) would change performance any.
aufkrawall
25th July 2015, 00:20
Well I agree that it's unwanted, I'm just not sure how to classify it, it really seems to be closer to 'noise' than simple banding. If it had occurred in a reliable source I'd have concluded that it was meant to be there. It's also interesting to note that MadVR set to high starts to remove the 'intentional' band across Turkey and Syria, and even MadVR doesn't successfully remove all the banding.
Yes, still some banding can be perceived. However, I think the high setting is a good compromise between sustaining detail and fighting banding.
My interpretation of this map would be that it's not supposed to contain any banding. There are many gradients, which I think should be smooth and are just meant as eye candy.
By the way, if you haven't tried it already, there's been a very recent update to the debanding filter which might help a little (although fixing this image is till beyond it). It should be available in the next release of the extensions, or you can just download the source.
Anyway, thanks for the feedback!
Will try the next extensions, I'm really bad with anything text/script-related.
I hope my feedback can be helpful in some way.
Marnes
25th July 2015, 01:19
Would it be possible to invert the color scheme on the status bar when the black theme is enabled btw? The black-on-white bar is a bit of an eye sore right now while everything else is dark.
I feel I should point out that I do appreciate Zach's and everyone else's (if anyone, I've no clue about the project's scale) work on mpdn :) It's a great player
aufkrawall
25th July 2015, 01:26
BTW, while we're on the subject, has anyone noticed the SM5 NNEDI3 is now around 10% faster with the same neurons vs OpenCL with the recent Nvidia drivers? At least on my Fermi cards, it was neck and neck (with SM5 just a touch faster) when we first implemented it. We haven't updated the NNEDI3 code and the only thing that's changed would've been the drivers. Just wondering if anyone's noticed the speed improvements.
With Maxwell 2.0, OpenCL is still a bit faster, but they are almost equal. In my memory, the gap was wider, maybe SM5 has really improved by driver.
My benchmark results (720p -> WQHD 64 neurons, chroma bicubic, max quality mode, everything else turned off, GTX 980 OC 353.49 driver on Windows 10):
OpenCL:
~20,5ms
~47% GPU usage
1126mhz
SM5:
prefer vector:
~22,7ms
~50% GPU usage
1126mhz
prefer scalar:
~24ms
~54% GPU usage
1278mhz
madVR result is interesting too, it's quite faster:
~13,9ms (maybe can't be compared directly)
~34% GPU usage
1126mhz
Both renderers used D3D11 and the same settings/queue lengths, as far as this can be possible.
Zachs
25th July 2015, 04:14
You'll need to cripple MPDN a bit for a fair comparison. MadVR doesn't have a max quality mode.
aufkrawall
25th July 2015, 13:20
Is MPDN's processing queue using more than 16 bit in max quality mode?
huhn
25th July 2015, 13:29
http://forum.doom9.org/showpost.php?p=1692075&postcount=3
looks like max quality is still using 32 bit float.
foxyshadis
25th July 2015, 13:38
Yes, still some banding can be perceived. However, I think the high setting is a good compromise between sustaining detail and fighting banding.
My interpretation of this map would be that it's not supposed to contain any banding. There are many gradients, which I think should be smooth and are just meant as eye candy.
Will try the next extensions, I'm really bad with anything text/script-related.
I hope my feedback can be helpful in some way.
My interpretation is that it's not possible to correct all encoding defects. I actually don't see any problem with the green nations, perhaps because mine is set a little higher than yours, but the blue water is horrifying. That looks like round-off, encoding, further processing, then round-off and re-encoding. What it does dither well (the green area) still improves the quality, even if it doesn't improve it maximally.
aufkrawall
25th July 2015, 15:08
Go ahead and create a request on GitHub for separate neuron settings for each pass.
*sigh*, not something a person not used to GitHub could do in three seconds, it seems?
ryrynz
26th July 2015, 04:12
*sigh*, not something a person not used to GitHub could do in three seconds, it seems?
Either he or Shiandow will get around to it, just create the request and wait. You likely won't be waiting terribly long.
Zachs
26th July 2015, 05:52
*sigh*, not something a person not used to GitHub could do in three seconds, it seems?
Well, GitHub isn't any more complicated than your typical issue tracking system.
Anyway the link is here: https://github.com/zachsaw/MPDN_Extensions/issues
Zachs
26th July 2015, 05:56
On a different note, will there be improvements to startup speed and such soon? I've been a big fan of mpdn for a while now because the image quality is so good, resource usage is low and the fluid motion filtering is just perfect, but I didn't realize until I installed potplayer that mpdn easily takes 5x as long to open and start playing. Even with my fast ssd, mpdn takes kinda annoyingly long to open when you're trying to go through many files. I tried to look for a replacement for fluid motion (the main reason I don't want to use other players anymore) but all that's available is interframe (haloing artifacts and different end goal) and other avisynth stuff (tedious to set up).
On x86, startup time is nearly instant on my system. For some reason, the .NET framework takes longer to start the x64 edition. The rest of the time it's to do with loading and initialising render scripts etc. Unless PotPlayer has something as sophisticated and as advanced as MPDN's features, you really can't compare the two.
aufkrawall
26th July 2015, 19:21
Well, GitHub isn't any more complicated than your typical issue tracking system.
Anyway the link is here: https://github.com/zachsaw/MPDN_Extensions/issues
Oops, sorry. I confused it with "pull request".
Have written an issue. :)
Regarding doubling/quadrupling: Yes, such scripts are very powerful, but you have to spend quite some time to get along with it. Thus a simple GUI option would be nice.
With my NNEDI3 tests, I recognized that under heavy load, the render queues sometimes don't fill up completely unless video is paused and then resumed.
Therefore, an option to fill up the queues before playing would be nice.
With default quality mode, MPDN OpenCL is even a little faster than madVR:
~13,34ms
~30% GPU usage
1126mhz
Is that "image quality" preset full 16bit like madVR?
madshi
26th July 2015, 19:26
FWIW, it's hard to make this a perfect apples to apples comparison. E.g. which algorithm is used by either madVR or MPDN to upscale chroma, when luma is doubled with NNEDI3? Which algorithm is used to fix the NNEDI3 pixel shift (if fixing is needed) etc. In order to get a 100% comparable situation all algorithms need to be 100% identical. Which is difficult because e.g. anti-ring filter implementations are different etc.
aufkrawall
26th July 2015, 19:41
I used bicubic resizing otherwise which looks "almost" completely identical and else turned everything off that can be turned off (AR filter, dithering etc.), same queue lengths etc.
But no guarantee for pixel shift correction. Anyway, the difference in GPU load is neglectable.
That reported load is not very accurate:
When I set OpenCL NNEDI3 in madVR to 128 neurons, I don't have anymore than 90% load reported, but power consumption is very high despite of this.
General question: Next year's GPUs will have much faster FP16 processing due to "mixed precision". Will this be helpful for video renderers?
Zachs
27th July 2015, 01:28
I used bicubic resizing otherwise which looks "almost" completely identical and else turned everything off that can be turned off (AR filter, dithering etc.), same queue lengths etc.
But no guarantee for pixel shift correction. Anyway, the difference in GPU load is neglectable.
That reported load is not very accurate:
When I set OpenCL NNEDI3 in madVR to 128 neurons, I don't have anymore than 90% load reported, but power consumption is very high despite of this.
General question: Next year's GPUs will have much faster FP16 processing due to "mixed precision". Will this be helpful for video renderers?
Well MPDN no longer uses FP16 - it uses 16-bit integer - for its default mode (Image Quality mode). I believe madVR also introduced it shortly after MPDN did. But I suppose if you use Render Performance / Max Render Performance modes, it might be faster... unless they also have a UNORM16 processing mode... who knows.
aufkrawall
27th July 2015, 01:38
Ok, I managed to make conditional render scripts do what I want them to do.
The result is NNEDI3 64 quadrupling via SM5.0 + AdaptiveSharpen after each doubling. Thanks a lot, Zachs and Shiandow! :)
My new favorite chroma scaler for this player is Jinc16 AR (of MPDN itself) + SuperChromaRes (1 pass, 2 strength, 0 softness).
It looks very much like Jinc AR of madVR.
So, if debanding would look better with stuff like bad news broadcasts I'd be almost totally happy with image quality.
Almost, because see the following.
Some strange observations:
MPDN D3D9 and 11 don't give equal results, with bilinear TMU scaling pixels differ (each red pixel has a different color between d3d9 and 11):
http://abload.de/thumb/d3d11vs9mpdnm7u01.png (http://abload.de/image.php?img=d3d11vs9mpdnm7u01.png)
This is not the case with madVR, with it D3D9 and 11 look the same.
I also notice that MPDN is a bit darker than madVR. You can see it best at the wall behind the stairs:
MPDN D3D9:
http://abload.de/thumb/mpdnd3d9m3b9v.png (http://abload.de/image.php?img=mpdnd3d9m3b9v.png)
madVR D3D9:
http://abload.de/thumb/madvrd3d9fibxb.png (http://abload.de/image.php?img=madvrd3d9fibxb.png)
Settings were as much identical as they can be (dithering off, bilinear TMU etc.).
Zachs
27th July 2015, 02:22
That looks like a serious bug to me as I haven't encountered any difference in D3D9 / 11.
Is this with bilinear / dithering off / fluid motion off / improve chroma reconstruction off etc.? Does this happen without NNEDI3?
Could you enable dithering to see if there's any discernible colour difference? I suspect that's just a difference how the rounding is done.
aufkrawall
27th July 2015, 02:29
That looks like a serious bug to me as I haven't encountered any difference in D3D9 / 11.
Is this with bilinear / dithering off / fluid motion off / improve chroma reconstruction off etc.? Does this happen without NNEDI3?
Yes, all off and no NNEDI3 nor any render script active.
Could you enable dithering to see if there's any discernible colour difference?
Will do tomorrow, it's very late here.
Zachs
27th July 2015, 05:13
Such a serious bug would've been noticed by other users. MPDN has had dx11 for a long time now, and personally I've not encountered the problem or anyone else with that problem. Was it just that particular file?
aufkrawall
27th July 2015, 05:39
Wait: the red pixels just portray pixels that don't share the same color between two different pictures. I don't see a difference just with my eyes. However, there's mathematically a difference between d3d9 and 11 which shouldn't be there.
and it has nothing to do with the issue that mpdn seems slightly too dark.
Zachs
27th July 2015, 05:40
Oh right I thought it was showing such crazy artefacts. I'll have a look.
madshi
27th July 2015, 09:11
Well MPDN no longer uses FP16 - it uses 16-bit integer - for its default mode (Image Quality mode). I believe madVR also introduced it shortly after MPDN did.
Actually, madVR has been using 16bit integer as the "main" texture format for more than 5 years now.
aufkrawall
27th July 2015, 19:01
Took a look at the new Jinc (cylindrical):
It's softer than Jinc3 AR of madVR but shows less aliasing. The more taps, the less aliasing. Seems like it's "best" to use 8 taps with maximum AR filter strength.
Shiandow
27th July 2015, 23:41
So, if debanding would look better with stuff like bad news broadcasts I'd be almost totally happy with image quality.
To make things clear I would like to point out that there are two kinds of 'banding', which in my opinion should be treated differently.
There's the banding which is caused by rounding the image to a low bit depth, this banding is usually made somewhat 'blocky' by the image compression. This is what I usually mean when I say banding, and it is the kind of banding that the debanding filter I made is supposed to remove. And it does so quite well (even if I say so myself).
And then there's all kinds of band shaped noise that can be caused by improper handling of the image, usually by processing the image without debanding beforehand, and then quantizing the image again. A fairly common example is a gradient which misses some values, so instead of going 111222333444 it goes 111222222444. MPDN's debanding is still capable of making this slightly better, but it basically recovers the original image, which already had banding (because of the multi-staged processing).
In my opinion this latter kind is no longer just banding, since the source itself is wrong. It would be better to classify it as noise. To fix it would probably be best to use some kind of denoising filter. I suspect that a trilateral filter would fix it quite nicely. MadVR's method might even be somewhat similar to a trilateral filter, but using a denoising filter to remove banding is not generally a good idea. You run the risk that it will remove things which aren't banding (the first kind). In fact MadVR set to high indeed does remove some detail, sometimes this is just unwanted noise (as with that news broadcast), but sometimes it isn't.
madshi
28th July 2015, 08:37
You make it sound as if debanding caused by rounding were safe and would never remove any image detail. IMHO that's just not true, unfortunately. Of course increasing debanding strength will also increase detail loss at the same time. But from what I can see, there's no magical strength boundary, that avoids detail loss if you stay under, and suddenly introduces dramatic detail loss if you go over.
In real life there's not only rounding, but also dithering and grain which needs to be taken into account. Banded gradients often jump around a bit. It could be 1121132224223334544555 etc.
And a debanding strength knob doesn't have to be limited to only handle exact 1 step gradients or exact 2 step gradients. If you use a more complex threshold logic, you can also e.g. use a debanding strength of 1.3 steps, averaged over a larger distance.
Shiandow
28th July 2015, 10:51
Well of course removing rounding errors will also remove some detail, although in my experience the amount of useful detail mixed in with the rounding errors is rather low, most of it doesn't seem to survive the compression. Still in higher quality sources removing the banding might indeed mean that you also remove some detail. But still, to some extent it is possible to distinguish (possible) rounding errors from other detail, and I think a debanding filter should take that into account.
I'm not too sure what you mean by removing 1.3 step banding, the image itself contains only integer steps. Of course that doesn't mean you have to treat all '1 step bands' equally, you could always look at the context to see if it should or shouldn't be removed, and both MadVR's and MPDN's debanding do so, in their own way.
madshi
28th July 2015, 11:20
I mean if you look at the "bigger picture", e.g. the value difference of two pixels which have a distance of 10 pixels distance between them, they might have an integer value difference of 13. Which makes the average value difference between them 1.3, if you're inside of a big gradient. So if you look at pixels that are further apart in a large gradient, you can use any threshold you want. It doesn't have to be integer. What I'm meaning to say is that if you want to do more debanding than just 1 integer value rounding differences, the next step up doesn't necessarily have to be a step size of 2. Your original post somewhat sounded like you could only either deband 1 value steps or 2 value steps.
Shiandow
28th July 2015, 12:33
I think I see what you mean, but those aren't really the kind of gradients that need debanding. The most obvious bands occur when the total difference is 1 over a distance of 10 or more pixels, which would make the average difference less than 0.1.
Besides in the example you gave, 10 pixels spanning a total of 13 values, there might be a difference greater than 1 between several (at least 3) of those pixels but the difference between their rounded values and their actual value is at most 1 (or 0.5 if they were always rounded to the nearest value). True you can allow a debanding filter to change the value of a pixel by more than 1, but in my opinion that means you've started to remove noise and not just banding.
FWIW the current versions of my debanding script use statistical properties to try to distinguish between rounding errors and detail, which essentially make it impossible to simply allow it to remove slightly more 'noise'. This is a limitation that is caused by designing an algorithm specifically to remove rounding errors. If you used a general denoiser at a very low strength you should be able to simply dial up the strength to remove more noise, but those algorithm have the disadvantage that they're not as good at distinguishing between rounding errors and detail, so you might need to remove more detail in order to remove all banding.
What I'm trying to say is that both type of algorithms have their uses, but they do different things. Trying to use a debander to remove noise or a denoiser to remove banding might work but the result will be far from perfect.
aufkrawall
28th July 2015, 13:10
I'd be very grateful for a denoise-checkbox in your algorithm though. :o
aufkrawall
28th July 2015, 13:36
Ok, D3D9 and 11 look identical now (I also tested render scripts).
MPDN still looks different to madVR with colors. MPDN is a bit closer to EVR CP of MPC HC, but they are different though.
MPDN:
http://abload.de/thumb/mpdndx117aj0f.png (http://abload.de/image.php?img=mpdndx117aj0f.png)
madVR:
http://abload.de/thumb/madvrfokzs.png (http://abload.de/image.php?img=madvrfokzs.png)
EVR CP of MPC HC (ignore chroma scaling and just look at the wall behind the stairs):
http://abload.de/thumb/evrcpouk7n.png (http://abload.de/image.php?img=evrcpouk7n.png)
Royal question: Who is right? madVR is known to be suitable for exact calibration. However, this doesn't have to be a guarantee.
What's the experts' opinion?
Edit: There is also a huge difference with the brown-orange carpet.
EVR-sync looks very close to madVR:
http://abload.de/thumb/evrsyncezzuc.png (http://abload.de/image.php?img=evrsyncezzuc.png)
ryrynz
28th July 2015, 14:14
MPDN still looks different to madVR with colors. MPDN is a bit closer to EVR CP of MPC HC, but they are different though.
There are pixel details in the MPDN image that are simply not there with madVR, that makes me think the resizer (bicubic?) being used for madVR is slightly less sharp. Fairly small differences though at the end of the day.
A few edges and areas there with reasonable differences which would be still hard to notice, but there's generally a 1/1/1 or 2/2/2 difference which wouldn't be noticeable.
I do favor the MPDN image here up close simply because of the pixel detail. Would it make a shred of difference while watching video, nope. Would be interesting to see a slightly sharper madVR upscaler for comparison.
Zachs
28th July 2015, 14:26
On my monitor, I really can't see any difference between EVR and MPDN. To rule out any rounding differences, try enabling dithering and see if you find the difference smaller.
As I understand it (correct me if I'm wrong), calibration needs to be done for a specific renderer, doesn't it?
ryrynz
28th July 2015, 14:27
What was the deal with the d3d11 color difference (re latest update)?
Zachs
28th July 2015, 14:35
It was actually just a tiny pixel shift in dx10/11 mode. Not something you can see with your naked eyes.
huhn
28th July 2015, 14:51
On my monitor, I really can't see any difference between EVR and MPDN. To rule out any rounding differences, try enabling dithering and see if you find the difference smaller.
As I understand it (correct me if I'm wrong), calibration needs to be done for a specific renderer, doesn't it?
no it doesn't. a normal calibration is done using the CMS from a TV and it has to work with every renderer/source.
3d is an exception most people on earth don't care about 3D anyway.
madshi
28th July 2015, 15:27
True you can allow a debanding filter to change the value of a pixel by more than 1, but in my opinion that means you've started to remove noise and not just banding.
FWIW the current versions of my debanding script use statistical properties to try to distinguish between rounding errors and detail, which essentially make it impossible to simply allow it to remove slightly more 'noise'. This is a limitation that is caused by designing an algorithm specifically to remove rounding errors. If you used a general denoiser at a very low strength you should be able to simply dial up the strength to remove more noise, but those algorithm have the disadvantage that they're not as good at distinguishing between rounding errors and detail, so you might need to remove more detail in order to remove all banding.
What I'm trying to say is that both type of algorithms have their uses, but they do different things. Trying to use a debander to remove noise or a denoiser to remove banding might work but the result will be far from perfect.
I think we're almost in philisophical land now. Your definition of banding and debanding seems to be slightly different to mine. Yours seems to be "banding = max 1 integer steps caused by rounding". Mine is more like "visible step lines in gradients that are not supposed to be there". Consequently, your ideal debanding algorithm would never remove more than rounding errors, while mine might, if the source seems to need it. I don't think madVR's debanding filter can be labeled "denoise", in any case. It's overall design is very much targetted at making gradients smoother and nothing else, which is unlike what any "noise reducer" would do. Also I would classify "noise" to be somewhat randomly distributed dots. Which is very different to banding.
MPDN still looks different to madVR with colors. MPDN is a bit closer to EVR CP of MPC HC, but they are different though.
Royal question: Who is right? madVR is known to be suitable for exact calibration. However, this doesn't have to be a guarantee.
What's the experts' opinion?
Might be as easy as a case of different matrix/primaries guesses. Which matrix and primaries have MPDN, EVR and madVR been using in your screenshots?
As I understand it (correct me if I'm wrong), calibration needs to be done for a specific renderer, doesn't it?
Ideally, every render would produce exactly the same (= correct) colors. If that were true, one calibration should suffice for all renderers. In real life things are not always as perfect. There are even standalone Blu-Ray players which produce slightly different colors. So sometimes in real life a calibration needs to be done per source device (or renderer). But of course that's not how it should be, in an ideal world.
aufkrawall
28th July 2015, 16:57
There are pixel details in the MPDN image that are simply not there with madVR, that makes me think the resizer (bicubic?) being used for madVR is slightly less sharp. Fairly small differences though at the end of the day.
It's both bilinear scaling via TMUs for comparison's sake.
What I notice, apart from that slight color difference, is that below the headband of the girl, there's a green square with madVR which isn't there with MPDN.
Most interesting is that it's always there with madVR and never with MPDN, no matter which scaling algorithm is used. :confused:
A few edges and areas there with reasonable differences which would be still hard to notice, but there's generally a 1/1/1 or 2/2/2 difference which wouldn't be noticeable.
I do favor the MPDN image here up close simply because of the pixel detail. Would it make a shred of difference while watching video, nope. Would be interesting to see a slightly sharper madVR upscaler for comparison.
We shouldn't compare image quality by single pixels with the pictures above since it's just bilinear TMU.
With NNEDI3 quadrupling via OpenCL there's not a real difference either, apart from colors.
On my monitor, I really can't see any difference between EVR and MPDN. To rule out any rounding differences, try enabling dithering and see if you find the difference smaller.
The difference is still there with dithering (both random).
The difference between EVR CP and MPDN is veery small, but it's there. I just checked in a dimmed room. However, since it's so small, it could be related to chroma upscaling.
This could also apply to madVR and EVR-sync. We could say we have to groups here: EVR-CP and MPDN on the one side and madVR and EVR-sync on the other one.
Might be as easy as a case of different matrix/primaries guesses. Which matrix and primaries have MPDN, EVR and madVR been using in your screenshots?
Both MPDN and madVR report BT.709, but madVR detects TV levels as input (information by upstream) while MPDN reports full range (not clear if it's meant for input or output).
Edit: Ok, I think it's surely meant for output.
Here's the sample again:
http://www20.zippyshare.com/v/0K5ArS12/file.html
Btw: MPDN doesn't accept PNGs with 8BPP whie it has no problems with 24BPP.
8BPP: http://www20.zippyshare.com/v/niiU7x21/file.html
24BPP: http://www20.zippyshare.com/v/USMxFxEL/file.html
madshi
28th July 2015, 17:09
What I notice, apart from that slight color difference, is that below the headband of the girl, there's a green square with madVR which isn't there with MPDN.
Most interesting is that it's always there with madVR and never with MPDN, no matter which scaling algorithm is used. :confused:
It seems there are actually 2 frames in that file. madVR shows the first, MPDN the 2nd. You can see that madVR has a decoder queue of 2/2.
aufkrawall
28th July 2015, 17:25
oh my, you nailed it..
Thank you, madshi!
I need to take a look again at Handbrake's kind of frame counting. It may work a bit (or a frame?) different than avs trim... :o
huhn
28th July 2015, 19:39
MPDN nnedi3 openCL doesn't work as madVr openCL nnedi 3 doesn't work.
Zachs does your openCL nnedi3 version use cl_nv_d3d9_sharing?
because it looks like this isn't part of newer drivers anymore.
Zachs
29th July 2015, 00:11
They better bring it back. I don't see a reason why they need to remove it especially when all their earlier Win10 drivers have it. Maybe they feel they have such a lead in the market place they're giving AMD a chance to catch up? :)
EDIT: All jokes aside, unless they've implemented the KHR methods, they've just shot themselves in the foot by crippling their own products. Can you check if the corresponding KHR extensions are now part of their new drivers? You can dump all the OpenCL extensions with GPU Caps Viewer.
Zachs
29th July 2015, 00:13
Btw: MPDN doesn't accept PNGs with 8BPP whie it has no problems with 24BPP.
8BPP: http://www20.zippyshare.com/v/niiU7x21/file.html
24BPP: http://www20.zippyshare.com/v/USMxFxEL/file.html
LAV is responsible for "not accepting" it. MPDN doesn't decode media files.
huhn
29th July 2015, 00:20
They better bring it back. I don't see a reason why they need to remove it especially when all their earlier Win10 drivers have it. Maybe they feel they have such a lead in the market place they're giving AMD a chance to catch up? :)
i hope they just removed it by accident. and yes it is very sad that AMD doesn't deliver at the moment...
Zachs
29th July 2015, 00:25
It could very well be that they have finally implemented the Khronos ones so they removed their equivalent NV extensions. Could you quickly dump the OpenCL extensions of their new drivers please?
huhn
29th July 2015, 00:25
LAV is responsible for "not accepting" it. MPDN doesn't decode media files.
and why does the lavfilter in MPC-HC handle this 8 bit png?
huhn
29th July 2015, 00:34
It could very well be that they have finally implemented the Khronos ones so they removed their equivalent NV extensions. Could you quickly dump the OpenCL extensions of their new drivers please?
i did this already with gpu cap and no they didn't.
couldn't the Khronos api version the reason for the copyback issue with AMD? so not sure if this is a good idea...
thsi whole topic is a mystery for me any way. according to this source: https://anteru.net/2012/10/30/1998/
cl_khr_d3d10_sharing is a 1:1 copy from cl_nv_d3d10_sharing. nvidia has both version with should be 100 % the same and doesn't make any sense to me but what ever.
madshi
29th July 2015, 08:16
The Khronos API version is *not* responsible for the copyback issue. Intel GPUs use the Khronos API and don't have any copyback issues. The D3D9 version of Khronos differs quite noticeably from the NV version.
huhn
29th July 2015, 12:41
wasn't it "ok" to do copyback with the openCL khronos extension. which makes the amd copyback issue not a "bug".
Zachs
29th July 2015, 13:46
Yeah the Khronos group didn't mandate the need to do interop without a copyback so it's not technically a bug, but that doesn't mean it isn't a problem.
Anyway until Nvidia brings back their interop extension, you'll have to use the shader version of NNEDI3. On my Kepler, the OpenCL version is a fair bit faster. Fermi is the other way around... Go figure.
Zachs
29th July 2015, 13:57
Dear devs,
The latest code check-in on GitHub is meant for v2.39.0 (available as test build only at the moment), which unfortunately has some breaking changes to the extensions API due to the introduction of ScalerTaps.Two.
Hardware scalers have also been removed and nearest neighbour / bilinear now works properly when used as a downscaler - i.e. they are 1-tap box and 2-tap triangular filters respectively.
The new nearest neighbour downscaler should be around the same quality as the old hardware bilinear (and non hardware bilinear) when downscaling by a small amount but it should give much better quality at larger downscale factors (but it's still just a box filter at the end of the day). You may find the new bilinear to be adequate in most cases without the need to go to Bicubic even.
Anyway if anyone wants to have a play with it besides the devs, feel free to download the test build from http://mpdn.zachsaw.com/Test%20Builds/3220/. If you encounter any problems, please report them here. Do note however that if you want to use it with extensions, you'll have to use the latest source from GitHub.
Cheers.
aufkrawall
29th July 2015, 16:12
How can I use SuperRes after each doubling when using NNEDI3 quadrupling?
I have two conditional scripts in a row set up for quadrupling:
if SourceSize.Width < 1280 and SourceSize.Height < 720 and NeedsUpscaling
-> use NNEDI3 + Image Processor
if SourceSize.Width <= 1600 and SourceSize.Height <= 900 and NeedsUpscaling
-> use NNEDI3 + Image Processor
If I simply replace NNEDI3 in these two scripts with SuperRes (each with NNEDI3 as prescaler), I seem to end up with only NNEDI3 doubling instead of quadrupling. :confused:
Shiandow
29th July 2015, 16:53
As of now that's not possible since SuperRes always scales to the screen size. There are also some subtleties when you use SuperRes multiple times like that since it's best for SuperRes to know that the original image was, which it won't if you simply use it after the image has been doubled.
For now it's best to just use the NNEDI3 quadrupler as a prescaler for SuperRes.
aufkrawall
29th July 2015, 17:13
Ok, :thanks: .
Anima123
30th July 2015, 00:08
Dear devs,
The new nearest neighbour downscaler should be around the same quality as the old hardware bilinear (and non hardware bilinear) when downscaling by a small amount but it should give much better quality at larger downscale factors (but it's still just a box filter at the end of the day). You may find the new bilinear to be adequate in most cases without the need to go to Bicubic even.
Cheers.
Does the new scalers would be of any benefit together with SuperRes in the future versions, where bilinear played a role in downscaling 2x scaled image to the original size?
Zachs
30th July 2015, 00:14
It should already have an effect. You should try it out. Feedback's always appreciated as usual.
ryrynz
30th July 2015, 02:07
BTW, while we're on the subject, has anyone noticed the SM5 NNEDI3 is now around 10% faster with the same neurons vs OpenCL with the recent Nvidia drivers? At least on my Fermi cards, it was neck and neck (with SM5 just a touch faster) when we first implemented it. We haven't updated the NNEDI3 code and the only thing that's changed would've been the drivers. Just wondering if anyone's noticed the speed improvements.
My 750Ti can do 256 neurons at 720 x 480 x 24FPS now.. It's pretty much at it's limit though.
D3D9, with hardware bilinear chroma and luma no SM or FM and no dithering on a 720x480 24 FPS file using NNEDI3 on OpenCL with a target resolution of 1920 x 1080
MPDN
Neurons Rendering time GPU %
16 10.6 15%
32 13.3 20%
64 17.8 30%
128 23.7 53%
256 39.6 91%
madVR
Neurons Rendering time GPU %
16 10.4 12%
32 13.1 18%
64 17.7 31%
128 25.6 57%
256 43.7 96% ~Frame drops~
Zachs
30th July 2015, 02:31
Speaking of NNEDI3, I've just checked in some codes that allow you to select different neuron count for each pass.
First pass is definitely much more important than second as the second relies on the first.
Go have a play. :)
aufkrawall
30th July 2015, 20:15
Zachs, MPDN often crashes with this error when I change lots of settings in a row, e.g. when comparing scaling results:
http://abload.de/img/mpdncrashb1ler.png (http://abload.de/image.php?img=mpdncrashb1ler.png)
Sometimes the player also becomes sluggish before this when switching between fullscreen several times (non-FSE).
Furthermore, the dialog to add shaders to image processor can't be reached if media is opened in the player, it then opens somwhere in the background or so and can't be pulled to the foreground.
The player must be terminated because it locks itself out.
ryrynz
31st July 2015, 00:16
Good thing there's two NNEDI3 versions.. Since Nvidias w10 driver kills openCL compatibility ATM with no ETA on the fix.
Zachs
31st July 2015, 02:03
Zachs, MPDN often crashes with this error when I change lots of settings in a row, e.g. when comparing scaling results:
http://abload.de/img/mpdncrashb1ler.png (http://abload.de/image.php?img=mpdncrashb1ler.png)
Sometimes the player also becomes sluggish before this when switching between fullscreen several times (non-FSE).
Furthermore, the dialog to add shaders to image processor can't be reached if media is opened in the player, it then opens somwhere in the background or so and can't be pulled to the foreground.
The player must be terminated because it locks itself out.
This error message is from the CLR (i.e. .NET runtime) and indicates a serious problem in the runtime. First thing that comes to mind is that there's a memory corruption that has affected the runtime. It could be caused by a number of things though... even a GPU driver can cause that since they run mostly in user mode now.
Zachs
31st July 2015, 02:04
Good thing there's two NNEDI3 versions.. Since Nvidias w10 driver kills openCL compatibility ATM with no ETA on the fix.
Have they even said they're going to fix it?
aufkrawall
31st July 2015, 02:14
They may bring it back or not, we have not been told yet:
https://forums.geforce.com/default/topic/860152/geforce-drivers/official-windows-10-353-62-game-ready-display-driver-feedback-thread-7-29-15-/post/4618371/#4618371
And SM5.0 NNEDI3 is still working well here. :cool:
This error message is from the CLR (i.e. .NET runtime) and indicates a serious problem in the runtime. First thing that comes to mind is that there's a memory corruption that has affected the runtime. It could be caused by a number of things though... even a GPU driver can cause that since they run mostly in user mode now.
It happens out of nowhere while I'm in the settings dialog, mostly of render scripts.
ryrynz
31st July 2015, 02:23
They may bring it back or not, we have not been told yet
And SM5.0 NNEDI3 is still working well here. :cool:
Yeah real shame after I posted those glorious openCL NNEDI3 results.
Zachs
31st July 2015, 03:52
Is it actually possible to run 353.49 Hotfix drivers under Windows 10? I heard they force the latest one on you via Windows Update. I wonder what would happen if you are running a beta driver that is newer than what Windows Update has...
huhn
31st July 2015, 11:15
you can run 353.49 and you can disable the update. it's not true that you can't stop updates.
ryrynz
31st July 2015, 12:50
you can run 353.49 and you can disable the update. it's not true that you can't stop updates.
Confirmed 343.59 fixes OpenCL. Huhn you might wanna let people know about this on the madVR forum, also mention the device installation settings option to disable auto updating from Windows Update.
Zachs
31st July 2015, 13:02
Uh detailed instructions on how to disabled windows update for GPU drivers would be nice... :)
huhn
31st July 2015, 13:15
this should stop all none security updates for now:
http://abload.de/img/update8mxgw.png
and there is a file/option from microsoft to stop "third party" updates. and there is a software to block some updates here a german page with it: http://www.chip.de/downloads/Microsoft-Hotfix-Windows-10-Updates-verstecken-oder-blockieren_81466169.html
I personally use 353.62 so I don't use any of this.
and here a work around from the beta times: http://answers.microsoft.com/en-us/insider/forum/insider_wintp-insider_devices/how-do-i-stop-nvidia-driver-34965-from-auto/1e82e119-789c-4809-bcd3-56e1515bedc2?tab=question&status=AllReplies#tabs
aufkrawall
31st July 2015, 13:28
Problem is that not the device is hidden from WU, but only the specific driver. That means if a new driver is released on WU, it will automatically be downloaded and installed if you don't run the tool from MS to hide drivers timely.
The setting in the advanced system options to not download driver updates from WU doesn't really have an effect, it downloaded drivers with it disabled for many users (me included).
The only safe way is to manually disable Windows Update service and manually start it again and directly after this start the update hide tool from MS before searching for updates.
But this can't be reommended to most users, since they will forget to enable the service again and miss out security updates.
ryrynz
31st July 2015, 13:30
Here ya are lads.
http://i.imgur.com/NN961F9l.jpg
http://i.imgur.com/Tfz6mJRl.jpg
aufkrawall
31st July 2015, 13:51
I alrady said that it doesn't have to work.
ryrynz
31st July 2015, 14:06
Seems to be working fine for me.
aufkrawall
31st July 2015, 14:10
But internet forums are full of reports that it didn't work.
huhn
31st July 2015, 14:43
don't forget most people on the internet aren't any good with PCs.
Belphemur
31st July 2015, 16:29
I went for this tool first : http://www.guru3d.com/files-details/display-driver-uninstaller-download.html
To remove all old drivers and everything that could be problematic. It also disable for you the automatic update of drivers.
Then when I restarted and I installed the version of the driver I wanted. I've done the the same for the Intel drivers (I was having some crash with it).
aufkrawall
31st July 2015, 16:30
afaik, DDU just sets the option in the advanced system settings that is shown on ryrynz' screenshots above.
aufkrawall
31st July 2015, 17:55
This time, MPDN crashed with this error while being in the render script settings:
http://abload.de/thumb/mpdncrash8osya.png (http://abload.de/image.php?img=mpdncrash8osya.png)
Well, however playback so far is totally fine when doing nothing else. There's some stutter during playback when changing volume via mouse scroll, but that's not a huge issue to me.
Btw: Jinc2D with few taps can be well used together with SuperRes for scaling below factor 1.5x, image isn't doubled and so a lot of GPU resources are saved, compared to the other available algorithms.
Scaling BD content to WQHD looks great this way.
I lowered SuperChromaRes strength a bit (to 1.7), since it brightens colors (mostly red) up a bit (or more than a bit). MPDN Jinc with 4 taps w.o. AR looks good and isn't too expensive together with SuperChromaRes.
However, Jinc3 AR of madVR is still better for this purpose, imho.
Zachs
1st August 2015, 15:08
On a different note, will there be improvements to startup speed and such soon?
Check out the latest release. With the installed version, MPDN without extensions now starts up immediately for both x86 and x64 editions.
Startup time with extensions had also been improved and on my system it is now less than half a second. We will continue to look into startup speed improvements (the bulk of the time is spent in creating and initialising the playlist extension).
Zachs
1st August 2015, 15:12
This time, MPDN crashed with this error while being in the render script settings:
http://abload.de/thumb/mpdncrash8osya.png (http://abload.de/image.php?img=mpdncrash8osya.png)
Well, however playback so far is totally fine when doing nothing else. There's some stutter during playback when changing volume via mouse scroll, but that's not a huge issue to me.
Btw: Jinc2D with few taps can be well used together with SuperRes for scaling below factor 1.5x, image isn't doubled and so a lot of GPU resources are saved, compared to the other available algorithms.
Scaling BD content to WQHD looks great this way.
I lowered SuperChromaRes strength a bit (to 1.7), since it brightens colors (mostly red) up a bit (or more than a bit). MPDN Jinc with 4 taps w.o. AR looks good and isn't too expensive together with SuperChromaRes.
However, Jinc3 AR of madVR is still better for this purpose, imho.
I'm not sure what the crash is and I haven't been able to replicate the problem. Perhaps send me your config files and some instructions on how to replicate the issue?
MPDN's Jinc2D is similar to AviSynth's - in fact, you'll find the code to reference AviSynth's Jinc implementation too. I'm not sure what madVR's Jinc is but I think it is similar (i.e. both EWA) to MPDN's Jinc2D. Perhaps madVR uses different weights, but only madshi can answer that (MPDN's Jinc2D is open source, madVR's Jinc is closed source).
aufkrawall
1st August 2015, 16:19
MPDN's Jinc2D would probably be fine for chroma, but yet it can only be used for luma (and only for upscaling).
That other Jinc of MPDN (that comes with the player itself, not with the render scripts) is muuuch softer.
My config isn't anything special, I think crashes are rather related to specific actions in a row than to a specific config.
Maybe enable some kind of debug mode? Then I can provide logs.
aufkrawall
1st August 2015, 18:36
2.39 hasn't yet crashed even once while changing render script settings.
Deband seems noticeably improved: In the example I posted earlier, higher power now reduces the banding better.
And even if set to 1, it doesn't seem to be a huge detail killer.
However, I really dislike the grain. It is easy to perceive but doesn't seem to have a real positive effect. Thankfully it can be turned off.
In some areas, Shiandow's algorithm is better than madshi's and vice versa.
For SuperRes, smoothness is still in the GUI (but doesn't seem to have an effect). I found it very useless anyway, introducing lots of aliasing (shouldn't it do the exact opposite?).
As for chroma, I'm now with custom chroma scaler (B: 1; C: 0.2) + SuperChromaRes (1 pass, strength 1.3). Hard to notice a difference to madVR Jinc3 AR without a comparison with some cartoon examples.
Jinc2D with configurable AR filter, like already existing for luma, would probably be better though.
aufkrawall
1st August 2015, 19:46
Ok, here's an example (filmed skies) where madVR deband still looks clearly better:
http://www41.zippyshare.com/v/hqA15LOW/file.html
ryrynz
2nd August 2015, 02:42
2.39 hasn't yet crashed even once while changing render script settings.
I noticed switching between NNEDI3 versions a couple of nights back that I didn't get any crashing, I was totally expecting it to.
Zachs
2nd August 2015, 04:28
Did you experience crashing when switching scripts too?
Anima123
2nd August 2015, 05:09
Just noticed that MPDN's FSE mode actually performs worse than desktop mode, due to spikes of high rendering time which causes in-fluidity during playback of videos. Desktop mode plays well though.
Windows 8.1 64-bit, nVidia 880M Optimus system, with latest version of MPDN, render script SuperRes used.
ryrynz
2nd August 2015, 07:25
Just noticed that MPDN's FSE mode actually performs worse than desktop mode, due to spikes of high rendering time which causes in-fluidity during playback of videos. Desktop mode plays well though.
Windows 8.1 64-bit, nVidia 880M Optimus system, with latest version of MPDN, render script SuperRes used.
Does it apply to all D3D versions and bit depth outputs? Is your refresh rate the same in FSE mode?
kingpage
2nd August 2015, 08:23
Thanks for such an awesome player. I love it!
I came from Potplayer where I could jump forward and backward instantaneously (but inaccurately).
http://i.imgur.com/GbO8wtG.png
I had a look to see if I could modify one of your extensions, Navigation.cs. Since it is trying to calculate where the next frame is, it's quite slow. StepFrame() is the only quick one but it pauses the playback and it's only forwarding by 1 single frame). Going back 1 frame on the other hand, Jumpframe (-1), is as slow as the Jump(x) method.
The next or previous keyframe isn't exposed in the methods of the PlayerControl class, unfortunately. I was wondering if you would consider adding a feature like that (it's also implemented in all the major media players, such as VLC, kmplayer, MPC-HC, etc) that allows users to instantly jump to keyframes so that we don't need to wait. The intervals between keyframes are usually 5-10 seconds long, really nice to have when precision isn't required (we can still have the ability to jump single frames), which is most of the time.
Zachs
2nd August 2015, 11:42
Thanks for such an awesome player. I love it!
I came from Potplayer where I could jump forward and backward instantaneously (but inaccurately).
http://i.imgur.com/GbO8wtG.png
I had a look to see if I could modify one of your extensions, Navigation.cs. Since it is trying to calculate where the next frame is, it's quite slow. StepFrame() is the only quick one but it pauses the playback and it's only forwarding by 1 single frame). Going back 1 frame on the other hand, Jumpframe (-1), is as slow as the Jump(x) method.
The next or previous keyframe isn't exposed in the methods of the PlayerControl class, unfortunately. I was wondering if you would consider adding a feature like that (it's also implemented in all the major media players, such as VLC, kmplayer, MPC-HC, etc) that allows users to instantly jump to keyframes so that we don't need to wait. The intervals between keyframes are usually 5-10 seconds long, really nice to have when precision isn't required (we can still have the ability to jump single frames), which is most of the time.
I'll add that to the PlayerControl class.
kingpage
2nd August 2015, 12:49
I'll add that to the PlayerControl class.
Great! Thanks so much for your great work. Keep it up!
Zachs
3rd August 2015, 06:56
Great! Thanks so much for your great work. Keep it up!
Turns out there's no need to. A simple change to Navigation.cs (https://github.com/zachsaw/MPDN_Extensions/commit/2ffc56e765fe18a6787e9640a3a449bb2f280169) was enough to do the trick. It'll be available in the next MPDN Extensions release.
EDIT: v1.12.0 is now available.
Zachs
4th August 2015, 07:23
MPDN's Jinc2D would probably be fine for chroma, but yet it can only be used for luma (and only for upscaling).
That other Jinc of MPDN (that comes with the player itself, not with the render scripts) is muuuch softer.
Just released v1.12.0 - it now has Jinc2D Chroma. Oh by the way Jinc2D not only used for luma - it's used for upscaling the whole image (chroma included - actually RGB to be more accurate). It's just the first stage where chroma is upscaled to luma size isn't being done in Jinc2D. Now Jinc2D Chroma can be used for this particular purpose.
ryrynz
4th August 2015, 09:36
Zach, does two pass NNEDI3 make sense over just one pass? There's no option for a single pass so I assume the benefits outweigh the additional performance hit.
My quick evaluation of the second pass yielded little in the way of any tangible improvement setting the second pass from 16 to 256.
nevcairiel
4th August 2015, 09:55
Zach, does two pass NNEDI3 make sense over just one pass? There's no option for a single pass so I assume the benefits outweigh the additional performance hit.
My quick evaluation of the second pass yielded little in the way of any tangible improvement setting the second pass from 16 to 256.
Its always two passes, the new options just allow you to specify different strength for the second pass. The first pass is more important, so its probably useless to set the second pass to a higher neuron count - instead increase the first pass and lower the second.
ryrynz
4th August 2015, 10:03
Its always two passes, the new options just allow you to specify different strength for the second pass. The first pass is more important, so its probably useless to set the second pass to a higher neuron count - instead increase the first pass and lower the second.
Ah, madVR never made any reference it from what I saw.
That makes sense not setting it higher than the first pass (large waste of resources)
Zach, in this case would you think it would be wise to disable higher counts for the second pass?
Also could you look at the anti-ringing? I enabled it for Jinc 2D chroma @strength 0.85 and the whole image softened considerably.. something's wrong there.
kingpage
4th August 2015, 11:13
Turns out there's no need to. A simple change to Navigation.cs (https://github.com/zachsaw/MPDN_Extensions/commit/2ffc56e765fe18a6787e9640a3a449bb2f280169) was enough to do the trick. It'll be available in the next MPDN Extensions release.
EDIT: v1.12.0 is now available.
It's working perfectly!!! Thanks again for everything.
ryrynz
4th August 2015, 11:21
It's working perfectly!!! Thanks again for everything.
Yup I had a play with it also, FYI for any files where there isn't any keyframe info it'll use the 30 second jump.
Zachs
4th August 2015, 11:45
Ah, madVR never made any reference it from what I saw.
That makes sense not setting it higher than the first pass (large waste of resources)
Zach, in this case would you think it would be wise to disable higher counts for the second pass?
I think you weren't looking at the right places - first pass scales one axis, second pass scales another. So if you only look at a horizontal straight line for example, you'll find the second pass to do nothing at all. Keep in mind SM5 and OpenCL versions do first and second passes in the opposite sequence.
Also could you look at the anti-ringing? I enabled it for Jinc 2D chroma @strength 0.85 and the whole image softened considerably.. something's wrong there.
I'll have a look.
Zachs
4th August 2015, 11:59
When you said it made the whole image considerably softer, do you mean as compared to when anti-ringing isn't enabled?
I can't see any difference at all to be honest. In fact, I'm not seeing much difference at all with anti-ringing enabled / disabled when it's used in chroma.
aufkrawall
4th August 2015, 22:59
Thanks for adding Jinc2D for chroma. However, it's still very soft, imho too soft for chroma.
There's a bug of deband: When strength is 1.0, there are white pixels sparkling. It disappears when using any value below 1.0.
Zachs
5th August 2015, 00:23
The Jinc kernel is from AviSynth's JincResize (https://github.com/AviSynth/jinc-resize/blob/master/JincResize/JincFilter.cpp) - I haven't checked but I would imagine the AviSynth Jinc to give you roughly the same results.
I think you're basing it off madVR though but its kernel isn't available for comparison so it's kind of pointless, or if it's even in fact similar to AviSynth JincResize.
aufkrawall
5th August 2015, 00:32
Yeah, I realize.
I think NNEDI3 will just be the way to go: not a real performance issue with 16 neurons for chroma and thanks to Shiandow's SM5.0 port, there'd be no stupid driver issues. :)
Zachs
5th August 2015, 01:11
FWIW, you can use other kernels with Jinc2D - it's a generic EWA scaler that will be made compatible with all the custom scalers that MPDN already supports. For example, you'll find SincBlackman (EWA version, not the current one in MPDN) to be much sharper than JincJinc (which is what Jinc2D currently is). In fact any Sinc filter (e.g. Lanczos) will give you much higher sharpness, but with more ringing as well.
aufkrawall
5th August 2015, 01:58
Could you elaborate what an EWA scaler is?
It's really hard to find a good chroma scaler for bad cartoon sources:
They all blur, ring or aliase. SuperChromaRes can be used as a kind of sharpening, but it can significantly make colors brighter.
Btw: MPDN still can't open 8bpp PNGs, while MPC HC with LAV can.
Not important, buy why is that so?
ryrynz
5th August 2015, 02:06
Could you elaborate what an EWA scaler is?
Elliptical Weighted Averaging.
http://www.imagemagick.org/discourse-server/viewtopic.php?t=25653
Zachs
5th August 2015, 02:06
Without going into technical details, an EWA scaler generally gives you less aliasing and produces sharper image.
I'll have a look at the 8bpp PNG problem.
Zachs
5th August 2015, 02:34
Hmm. I think I know what you guys are saying now about using Jinc2D in chroma and I've probably misunderstood what you were after.
As it stands, Jinc2DChroma only scales from source to luma size and has no effects in NNEDI3's chroma scaler.
That's probably why you're saying it's still soft.
To achieve this, I'll need to add a selection box to NNEDI3's config dialog to select chroma scaler.
aufkrawall
5th August 2015, 02:48
Elliptical Weighted Averaging.
http://www.imagemagick.org/discourse-server/viewtopic.php?t=25653
Thanks, will take a read.
Hmm. I think I know what you guys are saying now about using Jinc2D in chroma and I've probably misunderstood what you were after.
As it stands, Jinc2DChroma only scales from source to luma size and has no effects in NNEDI3's chroma scaler.
That's probably why you're saying it's still soft.
To achieve this, I'll need to add a selection box to NNEDI3's config dialog to select chroma scaler.
I really just meant scaling from source to luma.
Take a look at the flowers of the headband:
http://www7.zippyshare.com/v/Yck0L3UK/file.html
(yes, it's still the two frames-sample, but let's not be bothered by this since it doesn't affect us for this :) )
Every soft algorithm will mix up green with the pink stars (no matter if luma is upscaled afterwards or not).
And here's an example where other algorithms can introduce heavy ringing or mix up red and black:
http://www34.zippyshare.com/v/6gcCgyDm/file.html
madVR's Jinc3 AR does well in both cases, but since we don't know what it does, I think we really need to doge to NNEDI3 for chroma upscaling (which should always be best with enough neurons anyway and even with just 16 still way to go).
Zachs
5th August 2015, 03:18
Took a look at it and it has nothing to do with scalers. It's just a badly encoded source with chroma offset that doesn't conform to standards. MPDN follows Nev and Microsoft's advise in using a half pixel horizontal offset for MPEG2 and above sources when it hasn't provided any specifics about its chroma offset. With your source, it's encoded with zero offset but has neglected to put that information in its DXVA_ExtendedFormat structure. It was established in the past madVR uses a different scheme to determine the chroma offset but it was hardly reliable as well.
FWIW there's a hidden setting in MPDN's config file that allows you to override the default chroma offset but I wouldn't recommend changing with it since it will most likely cause problems with properly encoded sources.
aufkrawall
5th August 2015, 03:28
I can't evaluate this.
However, I'm still sure that NNEDI3 chroma scaling would look better.
And not only with bad cartoon sources, but also a lot more with low-res pixel-art like old games. No linear scaling algorithm will ever look good with that.
Zachs
5th August 2015, 03:32
I do plan to add NNEDI3 chroma scaling but it's not top priority since there isn't a convincing evidence to show that it's really that much better than just Lanczos for example.
Zachs
5th August 2015, 05:53
I've just committed a bunch of changes that introduces a generic EWA scaler in place of the 'old' Jinc2D scaler.
Jinc2D is still there under the new EWA scaler's config dialog but you can now also choose any of the custom linear scalers. In particular, Sinc-Blackman seems to give very sharp results that isn't too sharp while the other Sincs probably are. Then again, some people want super sharp images so you may want to have a play with it to find the optimal scaler for your eyes.
Testing this a little more and it seems these sharper scalers are very suitable as post scaler for any of the image doublers (NEDI/Super-xBR/NNEDI3).
Zachs
5th August 2015, 14:28
Btw: MPDN still can't open 8bpp PNGs, while MPC HC with LAV can.
Not important, buy why is that so?
You should be able to do that now with v2.39.2.
aufkrawall
5th August 2015, 14:37
You should be able to do that now with v2.39.2.
Yes, but now white is gray with it. Problem with transparency?
Zachs
5th August 2015, 14:47
Not sure. I'll look into it (low priority).
aufkrawall
5th August 2015, 22:36
Why is chroma scaling via render scripts only for pre-scaling luma?
Seems contradictory to luma scaling via render scripts to me, which completely replaces main MPDN's luma scalers when setting up corresponding conditional scripts.
Zachs
6th August 2015, 01:10
Because to make chroma scaler work as a chroma scaler for NNEDI3 would require it to work within that script (i.e. alongside it, not before or after). NNEDI3 has to explicitly support it, and the chroma scaler has to be written such that it is able to be used that way too.
In other use cases, chroma scaling in render scripts does completely replace MPDN's chroma scalers, just like scaling luma does.
aufkrawall
6th August 2015, 03:00
Alright, now I got it. Thanks. I'll probably stick to Sinc-Blackman 16 AR for now, it's not bad at all.
Zachs
6th August 2015, 03:02
Yeah, EWA chroma for NNEDI3 is top priority. So hopefully it won't take long to implement.
Sinc-Blackman EWA is superb in terms of sharpness. I've switched to it now for all my post NNEDI3 upscales.
aufkrawall
6th August 2015, 03:06
Your doing a great job. :)
Little suggestion for the UI: When moving the cursor onto the seekbar, could we have a pop-up that shows the media's time at that position, without having to click?
Zachs
6th August 2015, 03:13
Great idea!
Anima123
6th August 2015, 06:40
Version 2.39.2 seems broken something, which won't render video anymore, error message is about null pointer. Reverted to the previous version, all problems gone.
Zachs
6th August 2015, 07:08
Version 2.39.2 seems broken something, which won't render video anymore, error message is about null pointer. Reverted to the previous version, all problems gone.
Did you use the installer? If not could you try installing with the installer to rule out any human errors in your upgrade process?
Anima123
6th August 2015, 07:27
No I'm not using the installer. Always use manual updates for quite a long time.
Just double checked by deleting all configurations, and the error still there with the latest version. Sorry I cannot test with installer right now.
Zachs
6th August 2015, 07:29
Did you delete the whole MPDN folder (except Extensions but including Native folder) and unzip all from the latest zip file?
Anima123
6th August 2015, 07:41
Alright, I just did what you told, and the upgrades seems OK now.
I used to use the synchronizing dir feature of Total Commander to do the upgrade, it usually do except for the binary bundle added some new files.
Zachs
6th August 2015, 08:01
Well there's always going to be files renamed or added or even removed.
kopija
6th August 2015, 13:17
Greetings,
is it possible to select the display for fullscreen playback?
I cannot find the option.
Thanks.
Zachs
6th August 2015, 14:26
Not yet but you can easily write a player extension to move the player window to a different location (i.e. within your intended display bounds) before the player goes into fullscreen mode (there's an event for it).
Anyway go ahead and create a request on GitHub. But feel free to have a go and implementing it if you are a programmer.
aufkrawall
6th August 2015, 15:00
What do you recommend for downscaling?
Probably Sinc-Blackman with < 10 taps will give a good result?
At least I'd subjectively say so, but I don't have crucial images for downscaling tests.
I'm still very happy with Jinc2D + SuperRes for 1080p -> WQHD. Very sharp and artifact-free and fast GPUs have no problems with 60fps.
SuperRes probably works better if the source has more information (high resolution like 1080p)?
aufkrawall
6th August 2015, 15:58
There's a UI bug with latest 1.13 extensions: Selected custom chroma scaling algorithm in MPDN doesn't stay correctly. e.g. if I select Sinc-Jinc, it sets itself to Sinc-blackman when restarting MPDN. I already deleted MPDN config folder, it's not related to this.
Oh, and it would be very nice if AR filter strength could also be controlled in main MPDN and not just extension.
Zachs
7th August 2015, 05:02
Could you add the bug on github issue tracker so we can keep track of it?
Downscaling is a personal preference as with upscaling but for me I usually use softcubic. The reason is I hate moiré pattern and the sharper downscalers exhibit some form of the pattern that irks me.
edison
7th August 2015, 10:51
can we show the video content on other screen in full screen mode now?
Belphemur
7th August 2015, 11:47
can we show the video content on other screen in full screen mode now?
Follow this issue: https://github.com/zachsaw/MPDN_Extensions/issues/129
When it's closed and a new MPDN Extensions is released, it mean it's available. Until that, no, it's not possible yet.
Zachs
7th August 2015, 14:06
MPDN Extensions v1.14.0 Released with support for choosing which display you want it to display in full screen mode.
Note that for the display to go full screen EXCLUSIVE mode, you need to also select the corresponding Adapter ID in MPDN options dialog.
Zachs
7th August 2015, 14:08
There's a UI bug with latest 1.13 extensions: Selected custom chroma scaling algorithm in MPDN doesn't stay correctly. e.g. if I select Sinc-Jinc, it sets itself to Sinc-blackman when restarting MPDN. I already deleted MPDN config folder, it's not related to this.
Oh, and it would be very nice if AR filter strength could also be controlled in main MPDN and not just extension.
Turns out it was a bug with MPDN not showing the correct custom scaler! Fixed in v2.39.3.
I'll see what I can do with AR filter strength in MPDN.
ryrynz
7th August 2015, 14:11
I opened the player as it was downloading an update and then clicked on the proceeding updater window as it prompted me to update, I clicked on forget (as it was already downloading) and got the not set to instance of an object error.
Zachs
7th August 2015, 14:14
Stack trace please?
ryrynz
7th August 2015, 14:18
Cancel button is throwing this up, and the forget button is doing nothing.
===================================
An unexpected error 'System.NullReferenceException' has occurred.
------------------------------
Error Type = System.NullReferenceException
Error Message = Object reference not set to an instance of an object.
Error Source = Mpdn.Extensions
Error Site = Void CancelButtonClick(System.Object, System.EventArgs)
Error occurred = at Mpdn.Extensions.PlayerExtensions.UpdateChecker.SimpleUpdateForm.CancelButtonClick(Object sender, EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
OS Version = Microsoft Windows NT 6.1.7601 Service Pack 1
Total Physical Memory = 7.7 GB
Available Physical Memory = 4.6 GB
Date Time = 8/08/2015 1:17:44 a.m.
User Name = RYANSPC\Ryan
Application Startup Path = C:\Program Files\MPDN
Application Executable Path = C:\Program Files\MPDN\MediaPlayerDotNet.exe
CurrentDirectory = C:\Program Files\MPDN
SystemDirectory = C:\Windows\system32
Ran As Admin = True
HasShutdownStarted = False
MachineName = RYANSPC
ProcessorCount = 4
LogicalDrives = C:\, D:\, I:\, J:\, K:\, L:\, Z:\
EnvironmentVariables = COMPUTERNAME = RYANSPC; USERPROFILE = C:\Users\Ryan; HOMEPATH = \Users\Ryan; LOCALAPPDATA = C:\Users\Ryan\AppData\Local; PSModulePath = C:\Windows\system32\WindowsPowerShell\v1.0\Modules\; PROCESSOR_ARCHITECTURE = AMD64; Path = C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\MKVToolNix;;C:\Program Files (x86)\Smart Projects\IsoBuster;C:\Program Files (x86)\Skype\Phone\;C:\Program Files (x86)\EaseUS\Todo Backup\bin\x64\; CommonProgramFiles(x86) = C:\Program Files (x86)\Common Files; ProgramFiles(x86) = C:\Program Files (x86); PROCESSOR_LEVEL = 6; windows_tracing_flags = 3; LOGONSERVER = \\RYANSPC; PATHEXT = .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC; HOMEDRIVE = C:; SystemRoot = C:\Windows; SESSIONNAME = Console; ALLUSERSPROFILE = C:\ProgramData; PUBLIC = C:\Users\Public; FP_NO_HOST_CHECK = NO; APPDATA = C:\Users\Ryan\AppData\Roaming; PROCESSOR_REVISION = 3a09; USERNAME = Ryan; CommonProgramW6432 = C:\Program Files\Common Files; CommonProgramFiles = C:\Program Files\Common Files; OS = Windows_NT; PROCESSOR_IDENTIFIER = Intel64 Family 6 Model 58 Stepping 9, GenuineIntel; ComSpec = C:\Windows\system32\cmd.exe; SystemDrive = C:; TEMP = C:\Users\Ryan\AppData\Local\Temp; ProgramFiles = C:\Program Files; MOZ_PLUGIN_PATH = C:\Program Files (x86)\Foxit Software\Foxit Reader\plugins\; NUMBER_OF_PROCESSORS = 4; windows_tracing_logfile = C:\BVTBin\Tests\installpackage\csilogfile.log; TMP = C:\Users\Ryan\AppData\Local\Temp; ProgramData = C:\ProgramData; ProgramW6432 = C:\Program Files; windir = C:\Windows; USERDOMAIN = RYANSPC
RuntimeVersion = 4.0.30319.34209
Thread Count = 21
Handle Count = 436
VM Size = 924.1 MB
Peak VM Size = 924.1 MB
Working Set Size = 134.7 MB
Max Working Set Size = 1.3 MB
Min Working Set Size = 200 KB
Modules = MediaPlayerDotNet.exe, ntdll.dll, MSCOREE.DLL, KERNEL32.dll, KERNELBASE.dll, ADVAPI32.dll, msvcrt.dll, sechost.dll, RPCRT4.dll, mscoreei.dll, SHLWAPI.dll, GDI32.dll, USER32.dll, LPK.dll, USP10.dll, IMM32.DLL, MSCTF.dll, clr.dll, MSVCR120_CLR0400.dll, mscorlib.ni.dll, ole32.dll, CRYPTBASE.dll, uxtheme.dll, System.ni.dll, CRYPTSP.dll, rsaenh.dll, System.Core.ni.dll, MediaPlayerDotNet.ni.exe, System.Drawing.ni.dll, System.Windows.Forms.ni.dll, Mpdn.Core.ni.dll, comctl32.dll, dwmapi.dll, System.Configuration.ni.dll, System.Xml.ni.dll, nlssorting.dll, gdiplus.dll, WindowsCodecs.dll, RpcRtRemote.dll, CommandLine.ni.dll, clrjit.dll, OLEAUT32.dll, shell32.dll, YAXLib.ni.dll, System.Xml.Linq.ni.dll, MediaInfoDotNet.ni.dll, VideoFrameServicesNative.dll, MediaInfo.dll, SharpDX.ni.dll, SharpDX.Direct3D9.ni.dll, d3d9.dll, VERSION.dll, d3d8thk.dll, igdumdim64.dll, igdusc64.dll, SharpDX.DXGI.ni.dll, SharpDX.Direct3D11.ni.dll, Mpdn.RenderScript.dll, D3D9NativeServices.dll, SETUPAPI.dll, CFGMGR32.dll, DEVOBJ.dll, AVRT.dll, dxva2.dll, WINMM.dll, WTSAPI32.dll, opencl.dll, WINSTA.dll, dxgi.dll, WINTRUST.dll, CRYPT32.dll, MSASN1.dll, d3d11.dll, igd10iumd64.dll, bcrypt.dll, ncrypt.dll, IntelOpenCL64.dll, intelocl64.dll, task_executor64.dll, OPENGL32.dll, GLU32.dll, DDRAW.dll, DCIMAN32.dll, ntmarta.dll, WLDAP32.dll, cpu_device64.dll, tbb.dll, igdrcl64.dll, igdfcl64.dll, dbghelp.dll, igdbcl64.dll, d3dx9_43.dll, CSScriptLibrary.ni.dll, Extensions.dll, ClearScript.dll, CommonMark.dll, ICSharpCode.AvalonEdit.dll, Microsoft.WindowsAPICodePack.dll, Microsoft.WindowsAPICodePack.Shell.dll, Newtonsoft.Json.dll, Ookii.Dialogs.dll, ShellBasics.dll, SplitButton.dll, Mpdn.Extensions.dll, Mpdn.Extensions.Framework.dll, Microsoft.CSharp.ni.dll, WindowsBase.ni.dll, PresentationCore.ni.dll, PresentationFramework.ni.dll, System.Xaml.ni.dll, UIAutomationProvider.ni.dll, System.Design.ni.dll, WindowsFormsIntegration.ni.dll, CLBCatQ.DLL, explorerframe.dll, DUser.dll, DUI70.dll, Microsoft.ExceptionMessageBox.ni.dll, Microsoft.VisualBasic.ni.dll, diasymreader.dll, SspiCli.dll, psapi.dll
===================================
Object reference not set to an instance of an object. (Mpdn.Extensions)
------------------------------
Program Location:
at Mpdn.Extensions.PlayerExtensions.UpdateChecker.SimpleUpdateForm.CancelButtonClick(Object sender, EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Zachs
7th August 2015, 14:21
Thanks. Belphemur will fix that in no time :)
ryrynz
7th August 2015, 14:23
Yeah, you both Codesmiths through n through. Hammer away.
Zachs
7th August 2015, 14:26
Oh it's really fun making renderscripts and extensions for MPDN, thanks to Shiandow's brilliant framework.
Belphemur
7th August 2015, 14:35
And C# is quite a nice language to work with :)
Btw @ryrynz sorry for the bug ... it's corrected in the Extension 1.14.0 that Zach just released.
For the forget button, true it should give a feedback like closing the window ...
Keiyakusha
7th August 2015, 20:14
Zachs
Hi. This is me again with my "quality of life" things ^^
If we have multiple external subtitles for the same file, by default vsfilter (any flavor of it) expects files to be named something like this:
Movie.mkv
Movie.jp.srt
Movie.forced.srt
...whatever is marked bold can be any text. In this case the text between the dots will be interpreted as a track name.
The thing is, when used together with MPDN, while vsfilter itself works as expected, MPDN's "Subtitle" context menu is grayed out.
Personally I don't care about this and I am not requesting to do anything about it, just wanted to let you know.
amayra
8th August 2015, 01:05
thanks for your work but how about image support :D ? :goodpost:
Zachs
8th August 2015, 04:45
The thing is, when used together with MPDN, while vsfilter itself works as expected, MPDN's "Subtitle" context menu is grayed out.
Personally I don't care about this and I am not requesting to do anything about it, just wanted to let you know.
I'll have a look.
thanks for your work but how about image support :D ? :goodpost:
MPDN opens any files that LAV filter can decode.
kopija
8th August 2015, 09:18
MPDN Extensions v1.14.0 Released with support for choosing which display you want it to display in full screen mode.
Thank you Mr. Developer.
aufkrawall
9th August 2015, 05:13
I just realized that there already is a text pop up that shows the media's time at a certain position of the seekbar.
However, it's not visible in (windowed) full screen mode.
Zachs
9th August 2015, 05:42
Yes. That's done on purpose to make fullscreen mode consistent between exclusive and widowed.
aufkrawall
9th August 2015, 06:43
Can we have a checkbox to enable, though?
In MPC HC, it is there in windowed fullscreen mode.
It's for the following purpose: You are watching some episodes of a certain serial and want to skip the first x seconds (because of intro etc.). You can't do this with one click in windowed fullscreen because of the missing time information of seekbar. Doing it in windowed mode is quite annoying since the window usually is much smaller due to lower resolution. Probably very painful with 4k display.
ryrynz
9th August 2015, 07:26
Missing time info? Why not just click and drag the seekbar, time is there on the right.
aufkrawall
9th August 2015, 07:54
This works, but is unnecessarily inconvenient.
You have to hold left mouse button to move the slider around until you hit the desired time as good as possible. Not great at all, compared to one simple click, if there'd be the time pop up.
Zachs
9th August 2015, 12:57
I'll see if I can do something in full screen mode. Probably with the same extension that draws media position and duration.
wanezhiling
9th August 2015, 13:21
Hmm I still don't know what MPDN is... :o
Need some time to learn it.
aufkrawall
9th August 2015, 13:31
I'll see if I can do something in full screen mode. Probably with the same extension that draws media position and duration.
Please consider also fullscreen windowed mode. :)
Hmm I still don't know what MPDN is... :o
Need some time to learn it.
It's well invested, and not very difficult.
The earlier you start using conditional render scripts, the better. I'd suggest to use script group and create a script chain inside of it with the conditionals etc.
So you can easily create different script chains and switch between them, if you don't want to modify the ones you already have created.
Btw: I downscaled a photograph I shot in the woods and Sinc-Blackman 8 taps AR looks very similar to Catmull-Rom of madVR. Probably safe to say that it's a good setting for each scaling kind in MPDN main program.
Belphemur
9th August 2015, 14:26
For people that use a lot of subtitle, I added a new feature in the extensions:
You can now safely drag and drop your subtitle in the player. If you do it before a media is loaded, the extension will remember it and load the subtitle once the media is loaded.
Anima123
9th August 2015, 23:46
Just noticed there's constantly increased delayed frames when playback 29.970 fps 640x480 on 1920x1080 screen with fresh rate 60 Hz, no matter what upscaling algorithms used.
My system configuration is: Intel HD 4600 + nVidia 880M Optimus, windows 8.1 64-bit.
Edit: Never mind, the issue gone after the OS restarted.
Zachs
10th August 2015, 00:19
You'll find the presentation time to be rather high with an Optimus system. That's probably the reason why you're getting delayed frames. Anyway delayed frames aren't always noticeable. MPDN reports delayed frame when your GPU has failed to deliver the frame within the intended vertical refresh (i.e. your GPU had 16.67ms to do it but it failed). In other words, it's a measurement of how your GPU and/or driver is functioning (or even CPU since it could be the one that had been slow to ask the GPU to present). The only other reason which is unlikely in your case since you said upscaling algos did not matter, would be that your GPU is stressed too much it runs out of time before servicing the present calls. In this case, presentation time would still be low but it's delayed.
Zachs
10th August 2015, 00:33
Btw: I downscaled a photograph I shot in the woods and Sinc-Blackman 8 taps AR looks very similar to Catmull-Rom of madVR. Probably safe to say that it's a good setting for each scaling kind in MPDN main program.
Catrom it is almost an identical cubic equivalent of a 2 lobed Lanczos filter (4-taps). See: http://www.imagemagick.org/Usage/filter/#catrom-i
You should get almost similar downscaling result if you use Lanczos 4 taps with MPDN.
Zachs
11th August 2015, 13:01
Hi guys,
MPDN v2.40.0 (test build here (http://mpdn.zachsaw.com/Test%20Builds/3300/)) will introduce a new feature called "Audio Script". It is similar in concept to Render Script except it's for audio processing. This isn't compatible with audio bitstreaming, as usual, but I'd like to make sure it hasn't adversely affected its functionality (relative to MPDN v2.39).
Unfortunately I don't have a receiver capable of audio bitstreaming so I'll need your help. If you could test MPDN v2.40.0 (bitstreaming audio to your receiver) and let me know it still works fine for you, I'd appreciate it.
The MPDN Extensions repository on GitHub (master branch) now also contains several example Audio Scripts. Have a play with them if you like.
Cheers!
Zachs
11th August 2015, 13:20
It's still too early to bring DX12 to MPDN but here's a start - a DX12 test app. I've already written up a small post about it here (http://zachsaw.blogspot.com.au/2015/08/direct3d12-test-application.html) so you can have a read on how to use it.
Direct-link: http://mpdn.zachsaw.com/Misc/Dx12Test.zip
Let me know if it works for you (only if you have a DX12 capable system of course).
ryrynz
11th August 2015, 13:50
No adverse effects when bitstreaming with no audio scripts active using Sanear or MPC renderers. I see the audio transform filter listed in the filters menu which has no property page.
The DX12 test tool works as expected I guess, I has color cycling. 750Ti 343.49 W10.
Belphemur
11th August 2015, 13:58
DX12 works on Nvidia 880M in Windows 10 (R353.62 (r352_00-234))
Both with Nvidia card and Intel(R) HD Graphics 4600 (10.18.15.4256)
Zachs
11th August 2015, 14:00
Perfect! All as expected. Could you also test bitstreaming with an audio script active to see if it crashes? It should just have no effect.
ryrynz
11th August 2015, 14:28
Perfect! All as expected. Could you also test bitstreaming with an audio script active to see if it crashes? It should just have no effect.
Doesn't crash, but Gargle and Silencer certainly affects it. Gargle gives me a tatt a tatt a tatt type sound and the Silencer is like that only a lot faster. Same results with both MPC and Sanear.
Can confirm ffdshow/avisynth issue is resolved also.
Zachs
11th August 2015, 14:32
Hmm. You are bitstreaming compressed formats right? Not LPCM?
ryrynz
11th August 2015, 14:33
Hmm. You are bitstreaming compressed formats right? Not LPCM?
Aye, this was a Dolby Digital stream. LAV shows bitstreaming under the info tab, also the receiver states Dolby Digital also when the script is inactive.
Zachs
11th August 2015, 14:37
Thanks mate!
I think there's something I have to do to stop it from messing up compressed streams...
Anyway I'll call it a night for now. Thanks again!
Zachs
12th August 2015, 00:12
Aye, this was a Dolby Digital stream. LAV shows bitstreaming under the info tab, also the receiver states Dolby Digital also when the script is inactive.
BTW, do you remember seeing MPDN Audio Transform Filter in the filter list when you were bitstreaming?
ryrynz
12th August 2015, 00:52
It's there.
Zachs
13th August 2015, 13:47
AudioScript development is progressing well and the framework now utilizes OpenCL. It currently only uses your CPU via OpenCL but there's no reason why it can't use any OpenCL device - I just haven't got around to making a screen to let you select an OpenCL device. I imagine the best combination would be to use a discrete GPU for video rendering and integrated GPU for audio processing.
I've added a simple audio gain (amplification) script on GitHub that demonstrates how easy it is to write OpenCL code with MPDN's AudioScript framework.
It's still experimental at this stage so I urge everyone to give it a try and report any bugs here. It's also missing a "Chain" script that allows you to stack AudioScripts. I'm looking for someone to help me write one so if you're interested, feel free to let me know. It's basically just a subset of the Render Chain script and shouldn't be hard to implement.
Anyway without further ado, the latest MPDN test build is here: http://mpdn.zachsaw.com/Test%20Builds/3310/
You can use the updated MPDN extensions from GitHub here: https://github.com/zachsaw/MPDN_Extensions/tree/5579d52fcff5060f26b882637a335a77964ab7b0
Zachs
13th August 2015, 13:48
@ryrynz can you test this latest version to see if bitstreaming works now?
jaju123
13th August 2015, 19:14
MPDN crashes when pausing for longer than 30 seconds or so with AMD 15.7.1 drivers in Windows 10 :L I have 2x r9 290s.
aufkrawall
13th August 2015, 20:54
Can't confirm with 980. Did you try a different render path, e.g. D3D11 instead of 9?
jaju123
13th August 2015, 22:08
Can't confirm with 980. Did you try a different render path, e.g. D3D11 instead of 9?
If you're referring to me, this issue has only occurred after AMD released their W10 driver branch (15.200). On 15.6 drivers the problem doesn't occur (14.xxx branch).
Zachs
13th August 2015, 22:58
Well then you know the answer to that one...
Zachs
14th August 2015, 07:15
Hi guys,
Just committed a new audio script - Reclock. It does what reclock does and if you want to try it out, grab the MPDN test build and latest sources on GitHub.
It's compatible with DirectSound and Sanear Audio Renderers (Sanear will give you best audio quality when used with MPDN Reclock). However, MPC Audio Renderer isn't compatible.
Cheers!
http://i.imgur.com/iiexIzb.png
ryrynz
14th August 2015, 10:21
@ryrynz can you test this latest version to see if bitstreaming works now?
It works. No transform filter is showing now.
I got this the last time and forgot to mention it, I thought it might be related to the source code extensions sharing the same config as the installer version but after deleting the config it's still happening.
http://i.imgur.com/ofDQ9BD.jpg
Double clicking on it exposes the buttons when the window goes fullscreen.
Zachs
14th August 2015, 10:22
@belphemur can you have a look at the issue?
Belphemur
14th August 2015, 11:00
I dont really know how to reproduce this ... Especially the size of the Form is fixed.
I'm changing the way the button are anchored into the window.
@ryrynz: Did you modify in any way the UI of Windows ?
ryrynz
14th August 2015, 11:28
I dont really know how to reproduce this ... Especially the size of the Form is fixed.
I'm changing the way the button are anchored into the window.
@ryrynz: Did you modify in any way the UI of Windows ?
Oh yeah I should mention I have the UI size set to 150% which tends show issues like cut off forms and such..
BTW Zach I still have the same issue with ffdshow/Avisynth I reported earlier even with 2.39.3
Zachs
14th August 2015, 12:32
The problem you reported has been fixed in the test build. It'll be released soon.
ryrynz
14th August 2015, 12:47
The problem you reported has been fixed in the test build. It'll be released soon.
Oh yeah, somehow I thought that made it into a released build. Knew I should've checked that..
Belphemur
14th August 2015, 12:55
Oh yeah I should mention I have the UI size set to 150% which tends show issues like cut off forms and such..
BTW Zach I still have the same issue with ffdshow/Avisynth I reported earlier even with 2.39.3
I made a big commit that changes the way the SimpleUpdate works.
Can you check if you still have the issues with the buttons ? I changed the way they should be anchored to the window. I also made the window bigger, I hope it'll resolve your issue.
ryrynz
14th August 2015, 12:59
I made a big commit that changes the way the SimpleUpdate works.
Can you check if you still have the issues with the buttons ? I changed the way they should be anchored to the window. I also made the window bigger, I hope it'll resolve your issue.
Yeah saw it, I'll check it out now and update the post.
ryrynz
14th August 2015, 13:01
Nah, the form is a bit bigger but there's still no buttons.
With that update when the window is maximized I can't see the buttons at all.
Might just make a issue for it, no biggie, just revert that change and deal with it later.
Zachs
14th August 2015, 13:09
Can you try with my latest commit instead?
ryrynz
14th August 2015, 13:16
Can you try with my latest commit instead?
Oh yeah.. that nailed it.
ryrynz
14th August 2015, 13:17
Can you try with my latest commit instead?
Pressing cancel though made MPDN stop working though. Forget too.
Will wait for Belphemur's commit.
Zachs
14th August 2015, 13:21
Ah yes I'll get that fixed.
Edit: done.
ryrynz
14th August 2015, 13:26
Ah yes I'll get that fixed.
Edit: done.
I hope you're not pissing him off by doing that.. :D
Zachs
14th August 2015, 13:28
Oops my bad.
aufkrawall
14th August 2015, 15:41
Maybe default dithering strength of 2.0 is a bit high?
With this picture, a strength of 1.5 seems to be sufficient (8 bit display):
http://forum.doom9.org/showthread.php?t=172128
It would be neat if we could choose a lower bitdepth output than 8 to try out dithering settings.
Anima123
14th August 2015, 22:47
Feature request:
It would be nice if MPDN included some kind of video decimation, which is especially useful if one wants to enjoy good scaling algorithm with limited GPU power for high fps videos.
Zachs
14th August 2015, 23:35
It already includes some kind of fps decimation. It's decimated to your display refresh rate. Do you mean decimating the fps to a lower rate than refresh?
Zachs
14th August 2015, 23:35
Maybe default dithering strength of 2.0 is a bit high?
With this picture, a strength of 1.5 seems to be sufficient (8 bit display):
http://forum.doom9.org/showthread.php?t=172128
It would be neat if we could choose a lower bitdepth output than 8 to try out dithering settings.
Hmm Shiandow hasn't been around for some time now... Hope he's just taking a break.
Anima123
14th August 2015, 23:59
It already includes some kind of fps decimation. It's decimated to your display refresh rate. Do you mean decimating the fps to a lower rate than refresh?
Yes. For example, there's 60 fps videos that my nVidia 880M cannot handle using NNEDI3 for image doubling.
It's not like fluid motion feature which blend frames together to forge intermediate frames that do not need scaling at all, hence much more less GPU-hungry compared to scaling each frames.
Zachs
15th August 2015, 05:17
I think you might find that using NEDI or Super-xBR might be better than decimating frame rate...
Shiandow
15th August 2015, 09:53
Hmm Shiandow hasn't been around for some time now... Hope he's just taking a break.
I'm on vacation with somewhat unreliable internet access. I'll be back in a week or so.
Zachs
15th August 2015, 10:30
Ah good to know! Enjoy your vacation mate!
Zachs
15th August 2015, 12:33
Hi everyone,
MPDN 2.40.0 and MPDN Extensions 1.15.0 have been released.
The new audio script feature is now available and there's now a Reclock feature that works automatically (when video frame rate is within 3% of display refresh rate) - i.e. it does what SlySoft's Reclock does with the help of Sanear Audio Renderer (which is now included with MPDN installer). MPDN Reclock also works with DirectSound. It continually adjusts the clock so it matches the display rate so after a minute or two into the playback, you'll find your 'video frame rate (ref clock)' to be very close to your display refresh rate (just a touch under to give refresh rate measurement some error margin). Reclock is one of the simplest audio scripts you can create with MPDN. Other examples (e.g. Gain using OpenCL) are also available in the source version (in the Examples folder).
Belphemur's subtitle drag-and-drop feature is now also available.
Have fun!
Cheers.
Anima123
16th August 2015, 00:00
Thank you for bringing us the re-clock into MPDN. Actually I tried it as soon as I can, and found it not working as well with Optimus as with discrete video card systems.
With Optimus it has been noticed that the ref clock has to tune below the source fps to achieve 2s average closer to the source fps, and the actual refresh rate fluctuate quite a lot.
I do know that Optimus has it's flaws. However, since a lot of game laptops have it, it would be most appreciated if you guys can improve re-clock on the performance on Optimus systems.
Zachs
16th August 2015, 00:03
It was actually implemented on my Optimus laptop. Have a look at the screen shot a couple of pages back. Not sure why your Optimus behaves so differently.
Anima123
16th August 2015, 00:04
I'll post some screenshots when I can.
aufkrawall
16th August 2015, 03:33
With that Reclock feature, MPDN gets mroe interesting for movie watchers. I personally don't need any deinterlacing, but probably MPDN would be more suitable for movies if it had GPU deinterlacer?
Zachs
16th August 2015, 04:06
LAV can deinterlace using Quicksync and Cuvid. Only thing it is lacking is DXVA deinterlacing. At since stage I'll add that but I don't exactly need it personally too.
aufkrawall
16th August 2015, 04:57
Cool. Even cooler if it will be open source extension. :)
Anima123
16th August 2015, 05:04
It was actually implemented on my Optimus laptop. Have a look at the screen shot a couple of pages back. Not sure why your Optimus behaves so differently.
Just double checked, and nothing weird with Optimus when using the latest version. What I observed was possibly due to the fault of the usb audio driver of windows 2000.
Anima123
16th August 2015, 20:46
Bug report:
Wasn't the new display refresh-rate automatic adjustment only be applied when Reclock AudioScript is used? Or else it might cause audio dropout after sometime of playback?
Zachs
17th August 2015, 01:53
Display refresh-rate automatic adjustment? No. Reclock doesn't do and neither does MPDN's Reclock.
What exactly does ReClock do? (http://forum.doom9.org/showthread.php?t=155623)
Anima123
17th August 2015, 04:50
Display refresh-rate automatic adjustment? No. Reclock doesn't do and neither does MPDN's Reclock.
What exactly does ReClock do? (http://forum.doom9.org/showthread.php?t=155623)
Still, what if ReClock is not using, in which case should MPDN NOT speed up or down to match the screen display rate?
Zachs
17th August 2015, 04:51
If it's not in use, no it won't speed up or slow down.
Zachs
17th August 2015, 04:57
Confirmed 343.59 fixes OpenCL. Huhn you might wanna let people know about this on the madVR forum, also mention the device installation settings option to disable auto updating from Windows Update.
I just installed Windows 10 (fresh build) and it comes with v353.62 installed for my NVIDIA NVS 4200M. MPDN's OpenCL NNEDI3 works fine with it. What version of NVIDIA driver did you encounter a problem with?
ryrynz
17th August 2015, 05:07
what version of nvidia driver did you encounter a problem with?
355.60, watch out for Windows 10's broken disabling of its third party driver updating..
Zachs
17th August 2015, 05:13
355.60, watch out for Windows 10's broken disabling of its third party driver updating..
Well according to this page, it was 353.62 that first had the problem: https://forums.geforce.com/default/topic/860152/official-windows-10-353-62-game-ready-display-driver-feedback-thread-7-29-15-/?offset=109
Perhaps they haven't actually removed the extension - they just haven't implemented it for their WDDM 2.0 drivers (NVS 4200M is a Fermi GPU so it's not running WDDM 2.0). So only users with Kepler or newer GPUs are affected.
ryrynz
17th August 2015, 05:26
Well according to this page, it was 353.62 that first had the problem: https://forums.geforce.com/default/topic/860152/official-windows-10-353-62-game-ready-display-driver-feedback-thread-7-29-15-/?offset=109
Perhaps they haven't actually removed the extension - they just haven't implemented it for their WDDM 2.0 drivers (NVS 4200M is a Fermi GPU so it's not running WDDM 2.0). So only users with Kepler or newer GPUs are affected.
That's the thought yeah. I just straight up reverted to what worked and disabled those updates and everything's been sweet as ever since.
Zachs
17th August 2015, 05:41
That's the thought yeah. I just straight up reverted to what worked and disabled those updates and everything's been sweet as ever since.
Does DX12 work with the older driver?
aufkrawall
17th August 2015, 06:16
Yes. Probably they will also remove it for Fermi GPUs when they introduce WDDM 2.0 support for it.
From what I've been told, the extension will not come back.
We still don't know why they did remove it, as AMD and Intel didn't.
ryrynz
17th August 2015, 11:30
Does DX12 work with the older driver?
Your D3D12 test works okay, dunno about everything else though.
Zachs
17th August 2015, 12:04
Well then there's no reason why NVIDIA needed to remove the extension!
ryrynz
17th August 2015, 12:13
Yeah it's all a bit weird.. is it broken or removed? I think Manuel was looking into it, I might ask for an update.
BTW if anyone has their Windows 10 start menu stop working like I just did (also kills right click and left functionality on the taskbar)
then go here http://www.thewindowsclub.com/start-menu-does-not-open-windows-10 and run number 4)
You'll need to run an elevated powershell
http://serverfault.com/questions/464018/run-elevated-powershell-prompt-from-command-line
Bugger if I know what caused it.. Probably should've stuck with 8.1 for a bit longer.
Belphemur
17th August 2015, 13:03
Yeah it's all a bit weird.. is it broken or removed? I think Manuel was looking into it, I might ask for an update.
BTW if anyone has their Windows 10 start menu stop working like I just did (also kills right click and left functionality on the taskbar)
then go here http://www.thewindowsclub.com/start-menu-does-not-open-windows-10 and run number 4)
You'll need to run an elevated powershell
http://serverfault.com/questions/464018/run-elevated-powershell-prompt-from-command-line
Bugger if I know what caused it.. Probably should've stuck with 8.1 for a bit longer.
I advise you to simply replace it: http://www.classicshell.net/
Since Windows 8 I'm using this Start Menu ... I tried Windows 10 Start menu for a couple of week and really ... I prefer the classic shell.
ryrynz
17th August 2015, 13:13
I advise you to simply replace it: http://www.classicshell.net/
Since Windows 8 I'm using this Start Menu ... I tried Windows 10 Start menu for a couple of week and really ... I prefer the classic shell.
Yup, well aware of that one and Vistart too but will be running StartIsBack++ I think on my main machine when I upgrade, the new menu just doesn't have the same functionality. A little disappointing but hey I guess it works for the masses well enough.
I really thought it was an update I did, or the RAM speed I changed or the driver install I did. Real pain when you have one issue that springs up after you've made quite a number of changes recently and you just have to revert them all. Sure didn't help that I didn't have a restore point >.<
Anyway.. Windows 10.. not exactly a painless experience. I feel for the guys that have had their LCD's destroyed by what appears to be Nvidia's 353.62 driver (https://forums.geforce.com/default/topic/862417/geforce-drivers/windows-10-official-353-62-drivers-are-killing-samsung-and-lg-notebook-lcd-display-panels/1/). Fun times.
aufkrawall
18th August 2015, 07:02
Yeah it's all a bit weird.. is it broken or removed?
It is removed deliberately, according to ManuelG. A beta tester for Nvidia said it won't come back. Pretty certain, but not an official statement though! However, better bury any hopes.
Since OpenCL interop is or can be bugged on AMD as well (stupid PowerPlay bugs, especially with PCIe 2.0), I think it's not worth investing any time in new features that would rely on interop.
Shiandow's NNEDI3 SM 5.0 implementation works perfectly for me. GPU usage is a bit higher, but afair power consumption isn't.
GM200 probably can do 1080p60 64 neurons doubling via SM 5.0.
Btw: Could Asynchronous Compute of GCN be useful with DX12 for NNEDI3?
Zachs
18th August 2015, 08:11
I'm working on another code path for SM5.0 NNEDI3. This may or may not be faster but I'll probably need the AMD owners to test it out since I don't have an AMD GPU.
Anyway I'll make another post when it's ready. It'll require a new version of MPDN too unfortunately.
Edit: Not sure about async compute, but from my early research into DX12, it would seem that interoperability with D3D9 had been dropped. If it's true then DX12 support won't be possible since most of the shader codes are in SM3.0.
aufkrawall
18th August 2015, 09:40
I'm working on another code path for SM5.0 NNEDI3. This may or may not be faster but I'll probably need the AMD owners to test it out since I don't have an AMD GPU.
Sounds interesting, I'm curious how fast it will be.
I don't know how much time it would cost you, but what do you think of a "MPDN Benchmark" tool?
It would run each shader as fast as possible and measure finishing times. I think it would be very beneficial for determinating the best video card for HQ HTPC purposes. :)
ryrynz
18th August 2015, 09:53
I don't know how much time it would cost you, but what do you think of a "MPDN Benchmark" tool?
It would run each shader as fast as possible and measure finishing times. I think it would be very beneficial for determinating the best video card for HQ HTPC purposes. :)
Ah, we've been down this road before. Love me some benches..
Got a good name for this too Zach..
The Determinator :cool:
trandoanhung1991
18th August 2015, 12:24
Anyone else having a problem with the reclock script? It's causing, for me, a lot of dropped and delayed frames. I'm using SVP with it, might that be the problem?
ryrynz
18th August 2015, 12:31
Anyone else having a problem with the reclock script? It's causing, for me, a lot of dropped and delayed frames. I'm using SVP with it, might that be the problem?
Yeah possibly.. why not disable it and see, it's a quick test. SVP can be pretty intensive.
Zachs
18th August 2015, 12:34
I don't think you should use Reclock with SVP. MPDN doesn't know what the actually frame rate is in that case since SVP can change it at any time.
Zachs
18th August 2015, 12:36
Ah, we've been down this road before. Love me some benches..
Got a good name for this too Zach..
The Determinator :cool:
That's definitely doable with player extensions and render scripts. I wouldn't do it yet though since the algos are still changing and being optimised.
trandoanhung1991
18th August 2015, 14:37
Yeah possibly.. why not disable it and see, it's a quick test. SVP can be pretty intensive.
Yep, disabling the script keeps the frame rate stable.
I don't think you should use Reclock with SVP. MPDN doesn't know what the actually frame rate is in that case since SVP can change it at any time.
Something happened when both of them are on which causes frame rate to drop below 59, down to as low as below 40 for brief moments, which causes drops and delays.
I have another question. Is it possible to get MPDN to play BDMVs folders?
aufkrawall
18th August 2015, 23:43
Shouldn't MPDN be able to open jpegs via LAV the same way as it can open pngs?
It can't open this one:
http://abload.de/img/testqwud0.jpg
Zachs
19th August 2015, 00:01
I just tried your JPG with GraphStudioNext (LAV Splitter Source --> LAV Video Decoder --> Video Renderer) and it couldn't display anything too.
Zachs
19th August 2015, 00:02
I have another question. Is it possible to get MPDN to play BDMVs folders?
I don't think that's supported by LAV Splitter Source?
nevcairiel
19th August 2015, 06:46
I don't think that's supported by LAV Splitter Source?
It is, tell it to open the index.bdmv (for automatic playlist selection) or one of the playlists in the PLAYLIST folder, and it'll work.
Zachs
19th August 2015, 07:10
Test Build for MPDN v2.41.0 (Build 3320) is out (use it with the latest GitHub extensions) - http://mpdn.zachsaw.com/Test%20Builds/3320/
NNEDI3 (SM5.0) now has an alternate code path under optimizations. As I only have access to an old Fermi and an Intel P4600 currently, I can't say how much better or worse it'll perform beyond these two GPUs. My old first gen Fermi (NVS4200M) doesn't like this code path at all. However, on the P4600, it has sped up NNEDI3 by up to 100% in some situations. On the Intel GPU, the SM version was already much faster than the OpenCL version without this alternate code path but it is now more than twice as fast. The Intel GPU seems to always prefer the "Scalar and Small Code" optimization with alternate path whereas the first gen Fermi absolutely hates it (twice as slow).
I'd like your help now to find out what the best option for your GPU is - and I suspect different generations of GPU even from the same vendor will prefer different optimizations.
Nvidia and Intel GPUs have starkly contrasting fortunes with the alternate code path, so I'm very curious to see what it would do with an AMD GPU as well as other generations of Nvidia GPUs.
aufkrawall
19th August 2015, 07:43
I can confirm your Fermi findings with Maxwell.
Using alternate code path doubles GPU load to 100% and I have lots of dropped frames. No matter if vector or scalar.
Anima123
19th August 2015, 08:03
720p -> 1080p, GTX 880M + HD 4600 Optimus, Alternate weight access method used
neurons 64 + 64,
Prefer Scaler: 61ms
Prefer Vector: 61ms
Prefer Scaler & Small Code: 106ms (picture errors)
Prefer Vector & Small Code: 113ms (picture errors)
The error picture looks like:
https://www.dropbox.com/s/sb621se03b00r7k/Error_Using_Small_Code.png?dl=0
Normal picture without Small Code:
https://www.dropbox.com/s/al8rhyc3cadvsn5/Normal_Image.png?dl=0
neurons 32 + 32,
Prefer Scaler: 37ms
Prefer Vector: 37ms
Prefer Scaler & Small Code: 60ms (picture error)
Prefer Vector & Small Code: 59.4ms (picture error)
neurons 32 + 16,
Prefer Scaler: 33.2 ms
Prefer Vector: 33 ms
Prefer Scaler & Small Code: 33.5ms (picture error)
Prefer Vector & Small Code: 34.2ms (picture error)
Edit: Using traditional method, avoid branch is the most efficient for my GPU,
neurons 64 + 64: 33.2 ms
neurons 32 + 32: 23.2 ms
neurons 32 + 16: 19.1 ms
Zachs
19th August 2015, 08:16
Looks like it's not just Fermi hating this new path. The whole NVIDIA product line hates it. Try it with your HD4600, you'll find the results to be the complete opposite!
huhn
19th August 2015, 08:41
my r9 270 doesn't really care maybe 0.5 ms difference. prefer scalar was the fastest mode with and without alternative weight access method.
aufkrawall
19th August 2015, 08:58
Would it make any difference to use DirectCompute instead of SM 5.0?
Zachs
19th August 2015, 10:19
It really comes down to how well the driver maps the code to the underlying resource. Theoretically they should all perform equally but as we've seen it's very erratic - the same code using different version of Microsoft shader compiler would make a lot of difference.
aufkrawall
19th August 2015, 11:32
my r9 270 doesn't really care maybe 0.5 ms difference. prefer scalar was the fastest mode with and without alternative weight access method.
Is there a huge difference for you in GPU load, clocks and render times with prefer scalar over OpenCL?
ryrynz
19th August 2015, 14:45
As you know my 750 Ti loves avoiding branches so this alternative method is of no use to me.
I will mention however that each option was slower with the alternative weights and the small code options
gave me some lovely artifacting I could probably printscreen and sell as art.
But anyway, OpenCL is still faster for me by 6ms or so so I'll just stick with that for now until I get a 960 or something.
FWIW it's quite nice getting 256/16 neurons at only 66% GPU load & 27 ms render on a low end graphics card like the 750 Ti
on 704x480 content. Some mighty bang for my buck right there, madVR has to sit on 64 neurons for the same level of performance.
madshi
19th August 2015, 15:23
FWIW it's quite nice getting 256/16 neurons at only 66% GPU load & 27 ms render on a low end graphics card like the 750 Ti
on 704x480 content. Some mighty bang for my buck right there, madVR has to sit on 64 neurons for the same level of performance.
We're talking X/Y here, right? Does 256/16 look better than 64/64? In my experience 16 neurons doesn't handle certain edge angles well. So I'm not sure if it's a good idea to use 256/16 over 64/64. Have you compared this with test images etc?
ryrynz
20th August 2015, 01:55
We're talking X/Y here, right? Does 256/16 look better than 64/64? In my experience 16 neurons doesn't handle certain edge angles well. So I'm not sure if it's a good idea to use 256/16 over 64/64. Have you compared this with test images etc?
I've done a quick comparison but not on test images, but my results echo exactly what Nevcairiel said, the second neuron count has significantly less impact than the first.
In fact I would not be able to spot the difference in a moving image it's that small.
I tested this on an anime image where lines are obviously all over the place and any drop in neuron count could be seen to negatively affect lines for fingers etc.
I know exactly what to look for having done comparisons with 64 vs 256 neurons many times and I did not see any drawbacks setting to only 16 neurons for the second value.
As is often often said, test images don't reflect real world results and although I'm sure you could find some small drawbacks, the benefits would surely outweigh them.
I think your own testing here would also conclude that allowing this second value to be set independently would be a good idea.
Zachs
20th August 2015, 04:33
Hi everyone,
Could you let me know if this MPDN test build 3338 (http://mpdn.zachsaw.com/Test%20Builds/3338/) makes OpenCL work again with the new Nvidia drivers?
Cheers.
Anima123
20th August 2015, 05:11
Hi everyone,
Could you let me know if this MPDN test build 3338 (http://mpdn.zachsaw.com/Test%20Builds/3338/) makes OpenCL work again with the new Nvidia drivers?
Cheers.
Yes, this build's OpenCL NNEDI3 works with nVidia driver 353.62. I am using this version because the next version wasn't steady enough under windows 10.
Edit: And, OpenCL NNEDI3 is a little bit slower than it's fastest shader counterparts, which is 'Avoid Branches' for nVidia 880M.
Edit2: Without knowledge of which direction is the first processed for both implementations, but the OpenCL version seems shaper than the shader version with the same neurons 128 + 16 for both.
I guess the question which direction should be put first for the best quality has never been discussed before?
ryrynz
20th August 2015, 05:15
Hi everyone,
Could you let me know if this MPDN test build 3338 (http://mpdn.zachsaw.com/Test%20Builds/3338/) makes OpenCL work again with the new Nvidia drivers?
Yes, this build's OpenCL NNEDI3 works with nVidia driver 353.62. I am using this version because the next version wasn't steady enough under windows 10.
Also confirmed fixed on 355.60, thanks!
Didn't really notice any performance hit either ^.^
Anima123
20th August 2015, 07:10
Here's screen-shot of two version of NNEDI3, both with 128 neurons for first pass and 16 for second pass, picture is from 1024x768 -> 1920x1080:
NNEDI3 shader version:
https://www.dropbox.com/s/em95mv8c0euz7ue/NNEDI3_128n16.png?dl=0
NNEDI3 OpenCL version:
https://www.dropbox.com/s/i3m2z77z7v89ggy/OpenCL128n16.png?dl=0
Zachs
20th August 2015, 07:11
Also confirmed fixed on 355.60, thanks!
Didn't really notice any performance hit either ^.^
Well that's the quick hack version - the proper one will give you performance *gains* with this new interop path.
EDIT: It may very well prevent AMD GPUs from doing any copyback too but I have no way of testing it.
Zachs
20th August 2015, 07:14
I guess the question which direction should be put first for the best quality has never been discussed before?
Which direction should be scaled first really comes down to whether you're more sensitive to vertical or horizontal lines. For example, I tend to be a lot more sensitive to horizontal lines being jagged than vertical lines.
ryrynz
20th August 2015, 07:17
Well that's the quick hack version - the proper one will give you *gains*
Oh yeah. Need those gains man, bring it.
Which direction should be scaled first really comes down to whether you're more sensitive to vertical or horizontal lines. For example, I tend to be a lot more sensitive to horizontal lines being jagged than vertical lines.
Yeah I tested this today and the differences are minimal. I prefer the OpenCL version.
nevcairiel
20th August 2015, 07:20
I've done a quick comparison but not on test images, but my results echo exactly what Nevcairiel said, the second neuron count has significantly less impact than the first.
In fact I would not be able to spot the difference in a moving image it's that small.
I probably wouldn't use such extremes though, rather try 128/32 instead of 256/16, or something like that. As madshi said, 16 can have quite odd effects on some things.
ryrynz
20th August 2015, 07:23
I probably wouldn't use such extremes though, rather try 128/32 instead of 256/16, or something like that. As madshi said, 16 can have quite odd effects on some things.
Yeah, the upgrade to 64 on the second pass doesn't cost me much so I decided to settle on that, I'm not much a fan of 16 neuron NNEDI3 anyway (prefer 64 as a minimum TBH) I was just using it for testing.
Here's screen-shot of two version of NNEDI3, both with 128 neurons for first pass and 16 for second pass, picture is from 1024x768 -> 1920x1080:
You would not notice any difference between them at least according to the image you've screenshot.
I have yet to see any content that shows any reason to prefer one over the other, so don't worry about it.
Zachs
20th August 2015, 07:37
Oh yeah. Need those gains man, bring it.
The gain isn't much but I understand why Nvidia chose to drop the old crappy interop now...
ryrynz
20th August 2015, 07:40
The gain isn't much but I understand why Nvidia chose to drop the old crappy interop now...
Do enlighten us, because besides those Nvidia driver wizards you seem to be one of the few that knows why.
Zachs
20th August 2015, 08:03
Simply because it's a more efficient API.
aufkrawall
20th August 2015, 08:13
I think it really just depends on the content if OpenCL or SM 5.0 version looks better.
Maybe vertical lines are more often a problem and thus how it currently is implemented in OpenCL could be slightly better, but maybe not.
However, I don't think it's a good idea to do one pass with many and one pass with few neurons.
64 pass 1 & 2:
http://abload.de/thumb/64jur84.png (http://abload.de/image.php?img=64jur84.png)
256 + 16:
http://abload.de/thumb/25616muqse.png (http://abload.de/image.php?img=25616muqse.png)
(both SM 5.0)
ryrynz
20th August 2015, 08:42
However, I don't think it's a good idea to do one pass with many and one pass with few neurons.
Man, I'm gonna dream about that screenshot considering how many times I've seen it... but yeah you can see some really obvious differences on Hayley's
eyelid it's not as straight as on the 256/64 screenshot.
It's already been established that 16 neurons isn't very good in comparison to the other options and this highlights it pretty well.
aufkrawall
20th August 2015, 08:53
In this picture you can easily spot both advantages and disadvantages of SM 5.0 and OpenCL implementation (both 64 neurons for both passes quadrupling).
e.g. with OpenCL, there is more aliasing at the doorframe, while with SM 5.0, vertical angles like Francine's legs show some weird doubled line contoures. They can be alo noticed with vertical real life content like antennas.
I think 64 neurons are really the minimum for each pass. However, let's not forget how bad other algorithms can look with such difficult content. We really got used to NNEDI3 quality.
madshi
20th August 2015, 08:54
I could imagine a split like 128/32 working instead of 64/64, as nevcairiel suggested. Or instead of 64/64 some users might have just enough juice in their GPUs to go to 128/64. In any case, doesn't hurt to allow different settings for X/Y, I suppose.
aufkrawall
20th August 2015, 09:44
Simply because it's a more efficient API.
Why was the old one less efficient? A GTX 780 Ti scored 1600fps with your benchmark.
Zachs
20th August 2015, 12:20
Why was the old one less efficient? A GTX 780 Ti scored 1600fps with your benchmark.
Oh the FPS isn't much of an efficiency indicator for interop. It just means with that implementation, your GPU could theoretically run 1600fps max. At which point your memory bandwidth would've been the true indicator of the frame rate. So it isn't exactly a benchmark per se.
Zachs
20th August 2015, 12:46
The new interop path is not tested on AMD so I'd appreciate it if you could try it out and let me know if it works at all. [Options -> Video Renderer -> General -> Always Use New OpenCL Interop]
If it does, it would be good to find out if it still causes a copyback - but does anyone know how to empirically determine this?
Thanks guys.
aufkrawall
20th August 2015, 13:15
Why not write a new benchmark that uses the new interop?
Zachs
20th August 2015, 13:15
Haven't got the time to do it. Don't even know if it works on AMD yet...
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.