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

[Anime Viewer]

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]

MPDN only supports one monitor for FSE at any given time. You select this via the "Presentation - Graphics Adapter" option.

[trandoanhung1991]

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]

Can you let me know what sort of crash it is?

[foxyshadis]

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]

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]

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]

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]

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]

I've made some changes to the installer. Let me push it to github first.

[Zachs]

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]

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]

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]

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]

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]

Not possible I'm afraid.

[Zachs]

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]

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]

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]

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]

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]

Zach

I'm getting page not found when dowmloading the extensions for both installer and source

[Garteal]

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]

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]

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]

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]

i mean the number your rate tuner calculates as video frame rate

[Zachs]

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]

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]

This changes the audio clock in case you haven't noticed. That's why I told you there's no resampling.

[Zachs]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

I'm not sure I understand what you're trying to say...

[madshi]

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]

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]

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]

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]

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]

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]

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]

@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!