osdep/w32_register: add register/unregister options for Windows

[kasper93]

I deleted the branch by accident and it nuked the PR, which cannot be reopened for recreated branches. Old PR: #15904

[kasper93]

Open questions:

• Should --install be renamed to --register?

I think users are more familiar with install word. There were voices that install has to move binary somewhere else, but looking at definition https://www.merriam-webster.com/dictionary/install

to set up for use or service

it is exactly what it does.

• Should --install in fact move mpv.exe into user programs?
  I prefer keeping it portable, the --install / --uninstall command are not tied to installation itself. For example you can move binary, install again and it will work. There is no need to uninstall anything, before moving.

• Should archive-exts list be added to mpv's supported formats
  I don't see a reason why not. It is still user decision to select application to use. This is handled externally by Windows. Although I agree, mpv it likely not primary choice for archives, it's nice to have it suggested in "open with" drop-down.

Anything else?

EDIT:

One more

• Do we want icon for this mpv-install, mpv-uninstall thing?
  And if, so contributions welcome. It would be awkward to use the same icon as for mpv.

---

Most softwares' installer, main exec and uninstaller are detached. And not all sw use the same dir for main exec and uninstaller.

Yes we don't have dedicated installer, which drops dozen of files everywhere. My objective is to make this as clean and light as possible, while still making things work in Windows.

Some installers could detect the installed one and could even directly uninstall it.

The same as mpv, you can do mpv --uninstall from any mpv binary and it will work correctly. In fact while --install is handy to be in mpv, because it can be parametrized easily for used extensions, without creating whole another application or using installer for that. The --uninstall command is mostly portable. Though I still don't like the idea of dropping files in random places. But this is one of the questions above. If people want this, we can copy the .exe to programs...

Though I see no real issue, if someone uses mpv.exe and removes it, nothing bad happens... Worse case thay have stale entry in control panel, which will be pruned by windows. We can also completely skip uninstall entry in control panel if this is the main concern. But I still don't see why if user breaks it, it's mpv's fault.

mpv is the only special case I've meet that it could do three jobs by the same single file.

and if it's two files and you remove uninstall.bat what happens? mpv.exe is single binary, we really don't need full installer to handle it. Also mpc-hc, foobar2000, lav filters, 7zip all have in place installation. foobar2000 even does it on every start of application. madvr/lav filters have bat files, that lives along .dll, but it's still calls in the .dll regsvr. So if you remove them, well you no longer can uninstall.

[github-actions]

Download the artifacts for this pull request:

Windows

• mpv-i686-w64-mingw32
• mpv-x86_64-w64-mingw32
• mpv-x86_64-windows-msvc

macOS

• mpv-macos-13-intel
• mpv-macos-14-arm
• mpv-macos-15-arm

[avih]

Docs changes LGTM. Thanks.

I don't feel strongly about any of the open questions.

Moving the mpv binary would indeed make it a normal installer, but it's more work. I'd imagine there's a good reason that usually an installer application is used (inno setup etc), because it looks simple but I imagine there are many details to take care of - which personally I'm not familiar with.

I think registering mpv inplace is enough. Adding an actual installer would be fine too, but I don't think it's required.

Re the option name, I think the fact that it adds an uninstall entry at the control panel (which is a good thing) kind of makes us choose "install", for consistency. But "register" also a valid choice, because it is indeed a better description of the action.

Bottom line, either one would be OK IMO.

Re icon, not necessary IMO but it would be nicer to have one. I don't think mpv icon would be too bad, but also, there are enough free icons out there, and a generic cog icon or some such would do fine IMO. Or like the original PR did, pick an icon from an existing system file. Just ensure/test that it still works (does the registration/whatever) even if the file is missing.

[hooke007]

I vote for --register. Not a serious reason: Making it looks more different with mpv-install.bat.

[kasper93]

I vote for --register.

Ok, we can go with --register and --unregister, while install/uninstall term might be more familiar to regular joe when manipulation software. Also note I won't use --deregister, contrary to what might seem more fighting according to https://english.stackexchange.com/questions/25931/unregister-vs-deregister, but the --unregister feels nicer and is what also Windows itself used for operations like that.

(software like madvr / lav filters, were for years using install, hance why this was my first choice, but no matter)

Moving the mpv binary would indeed make it a normal installer, but it's more work. I'd imagine there's a good reason that usually an installer application is used (inno setup etc), because it looks simple but I imagine there are many details to take care of - which personally I'm not familiar with.

After consideration this is not a job for this command. It looks simple if you forget that normally you have more than single executable to package. Creating installer is still possible and valid on top of this registration command. Note that it can be self-expanding archive, which would serve similar purpose. The point is if you have to handle more files, like additional .dlls, icons, whatever. It makes only sense to have separate packaging solution.

But we need to distinguish what this PR does, which is registration of media plater from packaging the mpv into self-extracting or self-installing single-click solution.

Also like I was hinting on IRC, once you start moving things, you end up looking like malware https://devblogs.microsoft.com/oldnewthing/20230911-00/?p=108749 :) That's of course a joke and not applicable to mpv, but if you want to uninstall the uninstall.exe itself, it's always funny exercise.

Bonus chatter: If we were using cmake, we would have all sort of packaging solutions for free with cpack that integrates with install command. Meson doesn't have this convenience.

Re icon, not necessary IMO but it would be nicer to have one. I don't think mpv icon would be too bad, but also, there are enough free icons out there, and a generic cog icon or some such would do fine IMO. Or like the original PR did, pick an icon from an existing system file. Just ensure/test that it still works (does the registration/whatever) even if the file is missing.

This is in fact detail. I went back and forth few times, changing this install/uninstall helpers from showing command line window and not. And I settled to show it, which means, it won't have manifest or icon. But that's fine... it shows little tiny command line icon.

[kasper93]

I vote for --register. Not a serious reason: Making it looks more different with mpv-install.bat.

Changed everything to register. If feels awkward at places, but I will get used to it.

Perhaps the documentation should be updated to indicate that installation is required to make STMC show the icon and program name.

Added.

Please consider changing the first sentence to something along those lines, if you too think it can make it clearer.

Added.

---

Any more suggestions? I'm not sure what would be useful to add/change here.

[avih]

Please consider changing the first sentence to something along those lines, if you too think it can make it clearer.

Added.

Thanks.

Apologies for wasting both out time due to me not reading the whole section carefully before embarking on a discussion.

[Andarwinux]

Is there any reason not to add it to 0.40.0? We hope to replace the old bat installer in shinchiro builds with this soon.

[kasper93]

Is there any reason not to add it to 0.40.0? We hope to replace the old bat installer in shinchiro builds with this soon.

I don't see the reason to rush this through. Windows users doesn't care about stable releases anyway and even if, they can wait.

[CharlesMengCA]

Can we move these functions to mpv.com?

IMHO, mpv.exe should be a pure player, not installer or uninstaller.

[Andarwinux]

Can we move these functions to mpv.com?

IMHO, mpv.exe should be a pure player, not installer or uninstaller.

Your suggestion is pointless. mpv.com is just a legacy ugly workaround that has been abandoned by win32-subsystem=console.

[CharlesMengCA]

Then maybe we should create another utility exe for install/uninstall or other staff.

Putting install/uninstall in the player is a waste. the install/uninstall function will be rarely used, once a year or never?

But the bytes will be loaded every time when we play a thing.

[kasper93]

Putting install/uninstall in the player is a waste.

Waste of what? Bytes? You have over 100MiB static linked binary and worrying about maybe few hundreds bytes of code? Give me a break.

EDIT:

It's ~10kB, mostly strings, because I don't build them dynamically.

[Andarwinux]

Then maybe we should create another utility exe for install/uninstall or other staff.

Putting install/uninstall in the player is a waste. the install/uninstall function will be rarely used, once a year or never?

But the bytes will be loaded every time when we play a thing.

Typical Windows builds are based on the MinGW toolchain, which has more statically linked bootstrap code than the MSVC toolchain.
The combined size of all those exe then becomes much larger, and we still need to package them all in a zip for distribution. Do you know why embed always use busybox instead of GNU coreutils?

Note that every time one downloads an mpv build, the new exe creates some new waste that is far greater than the waste caused when you launch an registrar-integrated mpv.exe
While these are trivial anyway, I'm still against this, which is tantamount to opening the door for the mpv-to-VLC transition: since you can split the registrar into separate components, why not split gpu-next, stmc, and all? Pretty soon you'll need a shit NSIS to manage your installation.

[kasper93]

Pretty soon you'll need a shit NSIS to manage your installation.

This was one of the proposals, or Inno Setup, that I personally wanted to avoid. The main design decision was to make this portable and lightweight, which is why it is embedded in mpv and can be used whenever needed, not only when you have a separate script or binary at hand.

Of course, a proper installer would address concerns about removing the binary, binary bloat, or similar issues. However, it would no longer be "portable." Currently, we can easily switch between different mpv binaries just by reinstalling. There are registry keys and one shortcut, but no uninstallers or other unnecessary files left behind.

I like the current system, but I'm open to proposals on how to improve it. However, I want to keep it as unobtrusive as possible. If someone wants to install it, they can do so at any time. Otherwise, they can simply choose not to.

EDIT:

Also probably it's not clear. But the extensions can be customized with existing mpv options. So it is handy to have it together. Else we would need to duplicate this logic. And frankly if you want external, just use a script, batch, powershell...

[CharlesMengCA]

After disabled those encoders, my mpv.exe is 51MB although I used libmpv-2.dll most of my time.

I used .NET Framework to write the file association things for both mpv.exe and foobar.exe, hundred lines of code maybe. at lease it is easy to maintain. :)

[verygoodlee]

--register-rpath does not prepend to PATH if mpv launched from terminal.

• mpv --register --register-rpath=D:\bin\
• ~~/scripts/test.lua

print('Path='..os.getenv('PATH'))

• launch mpv via double click mpv.exe and then open console, D:\bin\ is in PATH.
  
• launch mpv from terminal, D:\bin\ is not in PATH.
  

[kasper93]

--register-rpath does not prepend to PATH if mpv launched from terminal.

Yes, it does not. Set you environment correctly. PATH is only prepended when run from Windows shell.

[verygoodlee]

--register-rpath does not prepend to PATH if mpv launched from terminal.

Yes, it does not. Set you environment correctly. PATH is only prepended when run from Windows shell.

mpv may be launched by other applications, such as umpv, the --register-rpath option doesn't work in these cases, so it does not make much sense, different launch modes result in different behaviors, which can be very confusing for users.

[kasper93]

--register-rpath does not prepend to PATH if mpv launched from terminal.

Yes, it does not. Set you environment correctly. PATH is only prepended when run from Windows shell.

mpv may be launched by other applications, such as umpv, the --register-rpath option doesn't work in these cases, so it does not make much sense, different launch modes result in different behaviors, which can be very confusing for users.

User inability to understand the feature doesn't render such feature useless. No one is forcing you to use this, if it doesn't fit your workflow.

I've added workaround to documentation. If you run mpv with Start-Process command it will inject PATH. You can create mpv.ps1 script and other script like umpv will use it.

---

I've changed to using .bat scripts as per requests. The rest of the patch is mostly unchanged from the last time, I will merge it later, because it looks like this is one of the missing features in our CI builds.

[candrapersada]

is there an --unregister-rpath too?

[kasper93]

is there an --unregister-rpath too?

No it's part of register. And cleared on unregister too.

[Obegg]

This could be just a mistake on my part, but I'm having difficulties with migrating from mpv-install.bat to --register.

Basically with the previous method of using mpv-install.bat every video extension such as .mp4 would have mpv icon.
Now (after using mpv-uninstall.bat and using --register) no such icon appears, but when opening the video file (in this case .mp4) it asks me to choose which app to open with, while mpv is the first option and all I have to do is click "Open" in the Open With pop-up window, this still bugs me, why do I need to interact with the Open With pop-up window in the first place? I though --register would perfectly replace the mpv-install.bat.

So to summarize:

1. mpv icon not showing up next to video and audio files.
2. user has to manually choose mpv in the Open With pop-up window when opening a video or audio file.

I'm using Win11 OS Build 26100.6584

[kasper93]

@Obegg --register doesn't forcefully change your default applications. It registers mpv as an application that can open .mp4. Once you open it once and select mpv as default application, both icon and any next open will use mpv by default.

[Obegg]

@kasper93
Thank you for the quick reply.

--register doesn't forcefully change your default applications. It registers mpv as a application that can open .mp4.

Got it.

Once you open it once and select mpv as default application, both icon and any next open will use mpv by default.

That's the part I did not like, I feel it's a "downgrade" from mpv-install.bat since the previous script changed the default application.
I guess that leads me to the following question:
Is there any plan to make --register change the default application the same way mpv-install.bat did?

[hooke007]

mpv install never did that. That's must be done by yourself.

[kasper93]

Is there any plan to make --register change the default application the same way mpv-install.bat did?

Not at this point. I don't think register command should change your system wide settings for default applications. It's single time operation to select application.

[Obegg]

mpv install never did that. That's must be done by yourself.

I'm 90% sure you're mistaken about that.
I don't remember having to change default applications when I used mpv-install.bat.

It's single time operation to select application.

Uhm, I partially agree with that sentence.
Yes - it's a single time for one video file extension that you manually open (for example: .mp4)
But - if you want to open a different extension (for example: .mkv) - now you'll have to do it again.
And again for each and every extension, it's becoming repetitive.

[Andarwinux]

Uhm, I partially agree with that sentence.
Yes - it's a single time for one video file extension that you manually open (for example: .mp4)
But - if you want to open a different extension (for example: .mkv) - now you'll have to do it again.
And again for each and every extension, it's becoming repetitive.

You can batch-associate multiple file extensions at once in Windows Settings.

[kasper93]

And again for each and every extension, it's becoming repetitive.

And if you want to use different application for any given ext, you can do that. Unlikely when it is forcefully changed. Not all exts should be open by mpv by default, for example .rar or something. It's your choice.

[hooke007]

mpv install never did that. That's must be done by yourself.

I'm 90% sure you're mistaken about that. I don't remember having to change default applications when I used mpv-install.bat.

I‘m 1000% sure your memory is not relibale.

https://github.com/shinchiro/mpv-packaging/blob/1c534ce8c21fab0be2a394ad73decc15e015693e/mpv-root/installer/mpv-install.bat#L183-L191

[Obegg]

I‘m 1000% sure your memory is not relibale.

LOL, thank you for a good laugh, you made my day.

https://github.com/shinchiro/mpv-packaging/blob/1c534ce8c21fab0be2a394ad73decc15e015693e/mpv-root/installer/mpv-install.bat#L183-L191

I always used unattended so it never opened control panel.
Just for you - I took the time to test it.
I used --unregister, here's a .mp4 file:

Then I used mpv-install.bat (unattended), then I sign-out of windows, sign-in to windows:

This is the kind of behavior I would expect from --register by replacing mpv-install.bat.

[hooke007]

That's what add_progid had done.