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

[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]

Originally Posted by 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?

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]

Originally Posted by mrcorbo

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]

Originally Posted by Zachs

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]

Originally Posted by 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?

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]

Originally Posted by ryrynz

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
MPDN Extensions Binaries
MPDN Extensions Source

[Zachs]

Originally Posted by 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

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.