Why

I'll clarify. I just noticed this commit, linked by a friend, but I'm confused why such a popular project, used by a vast amount of windows and Linux users, would make installation so different and foreign to a large amount of its users. I see the rationale behind getting increased speed but this is a user oriented project and I can imagine users having a hard time knowing how to install this. I'm just an outsider, though, so I don't have the authority to make intelligent decisions about a project I haven't contributed to.

because throwing a wrench into Microsoft's clown show is funny

Okay. Valid points. I use mingw64, despise visual studio and use vscode to get as far away from windows build tools, and very nearly only use open source projects designed primarily for linux. I've never touched dotnet either. That said, it's an os that's not going away. Support what you want, but depreciating windows support will likely just lead to someone making a mingw port of mpv and putting it in the archives :) Sorry, this sounds stupid

I'm confused why such a popular project, used by a vast amount of windows and Linux users, would make installation so different and foreign to a large amount of its users

Meanwhile I'm confused as to what we'd have to gain from catering towards a platform that's notoriously difficult to develop for. Money? Fame? Headaches?

BTW

"Direct" Windows support is deprecated, pending complete GL/Vulkan support
by Microsoft's WSL 2. This will enable running Linux binaries under win32,
and, owing to Microsoft's competence, it will be faster than native.

I'll believe it when I see it. WSL 2 is (while a nice development, don't get me wrong) still an intermediate layer/VM and relies on virtualization tech (What's it called again? Hyper-V I think?). And on the other hand, Vulkan is supported just fine on Windows by the GPU drivers.
So, I have my doubts about the faster claim here.
But we shall see, happy to get proven wrong with evidence/benches/etc.

And at least wm4 is very honest here with admitting bias

Why
I'll clarify. I just noticed this commit, linked by a friend, but I'm confused why such a popular project, used by a vast amount of windows and Linux users, would make installation so different and foreign to a large amount of its users. I see the rationale behind getting increased speed but this is a user oriented project and I can imagine users having a hard time knowing how to install this. I'm just an outsider, though, so I don't have the authority to make intelligent decisions about a project I haven't contributed to.

Copy pasta in the making?

Sorry, GH bug...

It's a disgusting company, and their technical incompetence makes it worse.

Saying this as a Windows user for the longest time but, I mean, other than blatant shills, who in their right mind could think otherwise.

Gonna be tacky and leave a fricking quote here, because I always chuckle when I read it:

A Microsoft Certified Systems Engineer is to computing what a
McDonalds Certified Food Specialist is to fine cuisine.

I suppose efficient hardware decoding won't be possible until implemented directly in Vulkan (and it seems Khronos initially only want to support H.264, not VP9...). Maybe CUDA would work , but that doesn't help ultra low power devices (which btw. often have shitty Linux support).

Are there any specific inconsistencies of mingw64 that are annoying enough to explain shifting to WSL 2? I'm intrigued because I have done a lot of mingw64 gui work and have not encountered inconsistencies between Linux and windows. Granted, I have not used opengl.

Impressive reasoning. You are definitely more experienced with the various nuances of mingw64 than me. I suppose if mpv requires WSL 2 from now on, so be it.

For some reason, newer Microsoft runtimes are not available by default, need to be installed as extra redistribution (this is why you sometimes get missing runtime DLL errors when trying to run exes built on another computer), and (not sure) are probably bound to the Visual Studio license. So MinGW uses the old one.

@wm4 for what it's worth, this is not exactly true anymore: windows 10 now comes with a Brand New Universal C Runtime (wow such innovation) that can be installed on older versions of windows as well, and mingw64 can use it. The LLVM-based toolchain I'm using to build for windows uses it by default. You don't have to redistribute it unless you really care about supporting users of old windows versions, but there's a good chance those users already have it installed because some other random program required it.

Windows is still fucking awful though of course.

Yeah, everything else you outlined still applies. Chances are you aren't going to notice much difference between mingw on the ancient CRT and this one, though I did not investigate this much. I just felt like correcting this bit since you explicitly pointed out mingw's use of the old CRT. This is more of a win for windows VC++ developers so they finally don't have to deal with the redistributable runtime nonsense, I suppose.

there will be no more MPV build support windows in the future?

https://devblogs.microsoft.com/directx/directx-heart-linux/

As a developer I can relate to dropping windows support if it is such a big hassle to provide.
However I do find some of the comments here strange.
Nobody is choosing an OS because of a video player.
This won't effect markets share or harm Microsoft in any way.
This will just harm a big chunk of your users because the can't use mpv anymore...

Nobody is choosing an OS because of a video player.

I think this statement is demonstrably wrong. I, for example, choose an OS because of the sum of all important software that runs on it (or doesn't). So collectively, every piece of software that runs on a platform (or doesn't) contributes towards my decision of which OS to choose.

Maybe mpv is not the deciding factor for anybody. (What would that even mean? Is the 1000th drop in a bucket the reason for it overflowing?) But it would certainly contribute towards hurting Microsoft's market share. Heck, if mpv (or back then, mplayer2) didn't exist, I may still be using windows; the opportunity cost of not having a good Linux video player alone would have been enough reason to prevent me from switching.

This will just harm a big chunk of your users because the can't use mpv anymore...

That, on the other hand, is true. But the most important question is, what good does it do us to have so many users? Given as mpv is FOSS and therefore terms like "market share" don't apply, it becomes primarily a balancing act of "average contribution quality" versus "effort needed to maintain compatibility". Are windows users providing enough helpful bug reports, feature requests and contributions for us to be able to improve mpv for other platforms as well?

For what it's worth, I think my answer is yes, so I'm against blacklisting Windows just to spite Microsoft - the few (if any) we'd convince to switch are almost surely not worth the many we'd lose. But I'm also not the one writing Windows compatibility code. At the end of the day, it's the people actually writing the code that get to make the decisions.

Anyway, if mpv ends up crippled in functionality on Windows, there are definitely more than enough Windows developers out there who would be willing to continue maintaining whatever code is necessary to make sure mpv keeps working on Windows. (And if there aren't any devs left, then.. well, no loss there)

I think this statement is demonstrably wrong. I, for example, choose an OS because of the sum of all important software that runs on it (or doesn't). So collectively, every piece of software that runs on a platform (or doesn't) contributes towards my decision of which OS to choose.

Yes you right my statement was wrong. Like basically every absolute statement about what "all the people" are going to do in the internet.
I just wanted to state that the majority of users are not going the change their os because of an video player even if it is such an amazing one like mpv.

I hope that if you decide to go that route you will explain you decision to you users where they can see it. Like on your webpage.

Btw have you ever thought about providing windows build on patreon or something similar for money instead of dropping windows support?
Then there would be an actual benefit for mpv to do all this necessary work to support windows.

Making it paid would require us to "get rid" of shinchiro, and to do builds ourselves, which is even more work. Not a good idea.

Side note, I don't subscribe to this all-or-nothing interpretation. My hypothesis is that if you have the official, 'buy mpv here and support the developers' button, and the 'download unofficial builds for free from here' buttons next to each other, a nonzero amount of people will choose to buy the "official" builds just to support the project, even if they can get it for $0 by clicking "no thanks". An analog to the "enter the price you want to pay (p.s you can enter $0)" model, which does generate nonzero income.

Anyway I think the biggest issue is that having an explicit funding source with no clear rules on how to distribute or manage them is probably not a good idea due to the tensions it may cause. We also discussed this before, and it boils down to us not really knowing what we'd spend the money on. Maybe wm4 could turn mpv into a corporate entity and hire individual developers with wages based on amounts he deems appropriate. But that would probably remove some liberties we currently have (e.g. being able to fly under the radar of anybody that might try patent trolling us)

You start declaring things depreciated before there are any alternative solutions that you know for sure is good enough, while at the same ranting about how much of a mess Windows is? This just seems very naive to assume that microsoft will hold their promise.

Why

I'll clarify. I just noticed this commit, linked by a friend, but I'm confused why such a popular project, used by a vast amount of windows and Linux users, would make installation so different and foreign to a large amount of its users. I see the rationale behind getting increased speed but this is a user oriented project and I can imagine users having a hard time knowing how to install this. I'm just an outsider, though, so I don't have the authority to make intelligent decisions about a project I haven't contributed to.

@roberth1990 the point is that it'll be funny when they don't

Please don't mix up Mingw and the later and altogether more promising Mingw-w64 (fork) - for starters the latter does directly support 64-bit processors - and they play nicely with other projects, e.g. Cygwin, WINE and work with upstream projects e.g. GCC .

If you don't have the resources, motivation, or manpower to maintain a Windows port and would rather focus on Unix-like platforms, just say so and be done with it. There are all sorts of open source projects that don't bother to support Windows and that's that. But by doing all this grandstanding around how dreadful Windows is, calling Windows users and developers “minions”, laughing about how funny it would be if things don't pan out and MPV doesn't work on the WSL, and saying (in WM4's own words) that you don't care about users, you're doing nothing but making an ass out of free software and Unix users. All you're doing is dropping support for a port, not bringing the plagues of Exodus raining down on Microsoft. Have some perspective.

To add to the point of whether a video player is a deciding factor on the OS you choose... If mpv drops support for Windows and nobody else is gonna pick it up themselves.

So? What... What holds one back from using the latest version that did support Windows? While it may matter in a young project where bugs and such could be abound, mpv is mature. For anyone that just wants a video player other than the defaults on Windows, that's enough. Anyone that cares more but has enough else in the ecosystem keeping them on Windows/away from Linux will just choose to do that too (because I can't get WSL I'll just stay with my version, and if I got a new system one day without active mpv support anymore, I'll just copy the old system's version and that'll be that).

I honestly struggle to see any benefit to this decision except to cut down on time spent/needed coding.

I just wonder why send it all to waste after already having implemented such a great D3D11 renderer etc.?

hello reddit

@KingTerrytheTerrible please do

@KingTerrytheTerrible what I mean is nobody cares if you use VLC. You're acting like the "WELL I'LL TAKE MY BUSINESS ELSEWHERE" type of person but there is no business at all.

you'll lose most of your Windows userbase

oh no, the horror!

Well, if Vulkan works fine. AND supports adaptive sync. AND supports 10 bit+ output. AND supports HDR.
(The last point barely works on Windows right now though.)

Right now native Windows Vulkan does not support 10 bit+ as mpv does not request it, much less fancy color spaces. It'd be interesting if WSL2 version does. I definitely volunteer as a tester for that.

vlc is great!

Well, you can do also other things with it than to just use mpv and WSL2 starting time is ~instant. Though I suppose it remains to be seen how well the integration actually will be. It would be really sucky if you couldn't assign file types in Windows to applications inside WSL like mpv.

@wm4 The virtualization and paravirtualization technologies used are part of the OS. Installing an entire Linux distribution inside of those technologies is much less so.

If you're trying to imply that WSL2 would count towards the mpv install size, you're wrong. WSL2 is part of the OS, and the OS you apparently want to use is already hopelessly bloated.

regardless, you need to install a distro and asking common joe to use WSL2 to run their video player is not gonna be a winning strategy

@fr500 The thing is that they've already said they don't care. There is no winning when no one is paying money for this.

Well, if this works both ways and Wine is now an acceptable solution for ports to Linux, then that saves a lot of effort.

Well yes, a huge proportion of Microsoft's revenue these days comes from Azure, which in most cases is running Linux workloads. Given that, it's only natural that they would want Linux development to be easy on Windows, their own operating system.

Well, if this works both ways and Wine is now an acceptable solution for ports to Linux, then that saves a lot of effort.

Indeed it is. I wouldn't trust windows developers to make a decent linux "port" in most cases. Hell, many games that have been ported to linux still run better under wine than their "native" version.

Yeah, and Linux->Windows ports are often just as bad. A lot of stuff can't be installed to Program Files because when developing on Linux, they never considered there might be a space in the installation path, because it was always in /usr or something like that. That's more of an issue with conventions than a technical one. To be honest, I'm fine with Windows->Linux ports depending on Winelib or something like that since it's easily pulled in by the package manager as a dependency and doesn't really directly affect the end user. Same with Cygwin on Windows. Requiring the WSL seems a bit more extreme from the perspective of the user than just depending on a dynamic library that translates between APIs, though.

@Serentty just for the record with regard to wine: AAA studies have released games on macOS as Windows exe + wine bundle in the past and most people never noticed. CrossOver is essentially a commercial Wine-version with business support and the possibility to commission patches to wine for compatibility with the software you want/need. So, this exists and is not unheard of.

Oh sure, depending on Wine is common. It's even possible to just recompile a Windows program as a Linux ELF that links to Winelib. I'm just saying I think that depending on Wine or Cygwin is a lower barrier to entry for users than depending on the WSL, in my opinion. You can't ship the WSL as a DLL with your program, for example. Of course it's possible that this could change in the future, but given that Microsoft is emphasizing the WSL as a feature for developers (especially Azure developers), I don't see it becoming easy for programs to transparently depend on it without user intervention anytime soon.

So wait, let me get this straight: You're now saying that commercial projects with the money and resources to make native ports choosing to depend on wine to run on Linux is considered fine, but free software driven entirely by volunteer efforts depending on WSL to run on Windows is not?

The difference is that wine is fixable if there is a problem or missing feature, and WSL is not.
It does not support multiple things you would want from a media player, such as multiple monitors, at all. GL/Vulkan support in new and immature. Feature set is unknown.
It's not exactly designed for desktop applications either, unlike wine.

The difference is that wine is fixable if there is a problem or missing feature, and WSL is not.

That sounds like more of a complaint valid for the closed-source platform you choose to run mpv on, not something that should be of mpv's concern?

If you're suggesting that mpv has an obligation to its users to avoid depending on potentially buggy closed source software, we should remove Windows support altogether.

@haasn I said above that I have the same opinion about Cygwin as I have about Wine. That's the parallel to be drawn here, since they can both be depended upon fairly transparently without being noticeable to the user. The WSL cannot be, and it's not likely that it will be. Also, when I say it's “fine” for a program to do something, I mean that in terms of how satisfied I would be using that program. It's not some sort of moral judgement on the developers like you seem to think.

I think what Microsoft is trying to do is almost literally making the WSL2 feel as native as possible, so while the technology under the hood is objective different from Cygwin, the end result should still be reasonably similar.

@Serentty I'm not an mpv dev and you should take my opinion with a grain of salt, but if Microsoft delivers on their promises and mpv under WSL2 actually works alright then it'll be up to the devs whether or not they want to deprecate the native support. To be more specific up to the ones writing the Windows-specific code like the D3D11 renderer (@rossy ?).

It's probably a little bit to early to be worried about things like size right now.

I don't mean to imply that it isn't up to them. I'm mostly a Linux user myself and I'm not really personally affected by this move. I'm just pointing out that I think there's a large difference in user experience between using a compatibility layer in a library, and requiring the user to set up something like the WSL. If the goal with the WSL2 is to make it feel “more native”, then perhaps there will be an easier way to prompt users to install it without having to take as many steps. We'll have to see.

It's probably a little bit to early to be worried about things like size right now.

This is sort of my position as well. We simply don't know what things will be like yet. But I would argue that that means that it would be hasty to make a decision on this before anyone has actually seen what this new WSL functionality will be like.

448a964

we did it leddit

Please don't make me use VLC. I shall stamp my feet...and cry. I'm sure many of us would donate, if that's the issue.

I find it hilarious how this issue is still going strong

I'm just pointing out that I think there's a large difference in user experience between using a compatibility layer in a library, and requiring the user to set up something like the WSL.

The absolute horror of needing a few more clicks to install a program, on an OS that already requires many clicks to install typical programs! (I actually wouldn't be surprised if this is something that could actually be invisibly automated by some batch script, either)

I find it kinda funny that so many Windows users in this thread seem to be arguing from the implicit assumption that this will somehow spell the 'end' of mpv on windows, or that they will be driven to use VLC or other players by this change, when the reality of the matter is probably going to be more benign, and probably even beneficial for windows users. Having good vulkan/opengl support on windows would most likely have prevented those bugs exclusive to ra_d3d11 / SPIRV-Cross, for example. If I was a windows user, I would want my system to be as close as possible to the system that the program's developers are using, to maximize my chances of getting the experience they worked so hard on polishing.. for their environments.

It seems like there's a big implicit assumption of "WSL2 will be terrible and clunky and unusable", sometimes with the addendum "(because Microsoft made it)", which I never quite understand. You trust Microsoft to develop an operating system from scratch (which includes writing the kernel, designing the user experience, implementing a compositor, developing and implementing a multitude of APIs, etc.), but not integrate a new, existing API into that kernel / compositor / user experience? The latter should be vastly easier than the former. If I don't even trust Microsoft to get this right I have to wonder why I'd even use Windows to begin with.

I think it won't be terrible, but WSL2 desktop support is not really that big of a concern for Microsoft. They want developers to move and use Azure, not users to run Linux applications on Windows. (It's not the opposite of Wine.) So while it will exist in some form to just run some custom development environments, it will not necessarily be any great at being a desktop.

(Yes, it is currently lacking some advanced features for 3D and desktop. Whether these features will appear, we'll see.)

As for Vulkan support, mpv has no option for colorspace and surface format for Vulkan. (Separate from fbo-format.) Which is somewhat funny. If that's given and HDR is enabled in Windows, I see many HDR10_ST2084/BT2020_LINEAR colorspaces supported, and Windows engages HDR in these. And for 10-bit without HDR, there's A2R10G10B10 with SRGB_NONLINEAR and R16G16B16A16 with EXTENDED_SRGB_LINEAR.
Nvidia's Vulkan used to be lacking in everything but basics, it probably still is, someone would have to check it.

Game developers don't care about hacks and driver devs do not need to implement it because games use hacks. Vicious circle.
The hack used for HDR is WGL_NV_DX_Interop2. So using D3D11 to create the window to run Vulkan inside. :(

I'm just pointing out that I think there's a large difference in user experience between using a compatibility layer in a library, and requiring the user to set up something like the WSL.

The absolute horror of needing a few more clicks to install a program, on an OS that already requires many clicks to install typical programs! (I actually wouldn't be surprised if this is something that could actually be invisibly automated by some batch script, either)

I find it kinda funny that so many Windows users in this thread seem to be arguing from the implicit assumption that this will somehow spell the 'end' of mpv on windows, or that they will be driven to use VLC or other players by this change, when the reality of the matter is probably going to be more benign, and probably even beneficial for windows users. Having good vulkan/opengl support on windows would most likely have prevented those bugs exclusive to ra_d3d11 / SPIRV-Cross, for example. If I was a windows user, I would want my system to be as close as possible to the system that the program's developers are using, to maximize my chances of getting the experience they worked so hard on polishing.. for their environments.

It seems like there's a big implicit assumption of "WSL2 will be terrible and clunky and unusable", sometimes with the addendum "(because Microsoft made it)", which I never quite understand. You trust Microsoft to develop an operating system from scratch (which includes writing the kernel, designing the user experience, implementing a compositor, developing and implementing a multitude of APIs, etc.), but not integrate a new, existing API into that kernel / compositor / user experience? The latter should be vastly easier than the former. If I don't even trust Microsoft to get this right I have to wonder why I'd even use Windows to begin with.

There is hope for a decent package manager now at least
https://www.howtogeek.com/674470/how-to-use-windows-10s-package-manager-winget/

Ok I take that back... I didn't want SMPlayer

The winget packagers?

For real, they should include mpv proper, and not deliver SMPlayer when searching for "mpv" .
SMPlayer is just a front-end for mpv basically, for a while already (it used MPlayer before).

The absolute horror of needing a few more clicks to install a program, on an OS that already requires many clicks to install typical programs!

The level of sarcasm here is really not necessary, by the way. Anyway, I think you're thinking strongly from a developer's perspective here. Yes, installing the WSL is not very hard if you have some background knowledge. For the majority of users, being asked to go into the settings and enable a “Windows component”, potentially having to go into their BIOS to make sure virtualization is enabled, downloading a Linux distribution from the Windows Store, and finally having to create a Linux user account, is not trivial. For a lot of people I know, and these people are not bumbling idiots who can't figure out basic computer skills, that would be too high of a barrier to entry. I think the very fact that we're having a discussion on GitHub on the thread for a commit shows that starting from the assumption that we are like the average user is fairly flawed.

Installing WSL is not just clicks. You need to enable Hyper-V, which involves enabling virtualization, sometimes still a manual step in system firmware. (New ones that are fully Windows 10 certified should have that enabled by default... But still often don't.) And for obvious reasons Hyper-V breaks Virtualbox and other hardware accelerated VMs.

And I wouldn't be able to use mpv at work altogether then because we're not allowed to use virtual machines due to some stupidity regarding automated document encryption and bypassing it.

These are all Microsoft's problems, not ours.

The fact that you seem to see breaking things for Windows users as being “Microsoft's problem” instead of a problem for users is incredibly petty. If this is your attitude towards your users who use Windows, why did you even write such a port in the first place?

If I'm petty, then you're entitled.

I'm on Linux, not Windows. I don't have anything to gain personally from this.

If they make users to jump through hoops to use WSL2, it's Microsoft's problem.

You're acting like the WSL2 is some core OS feature that Microsoft is breaking here. Rather, you're choosing to depend on a developer-oriented feature that came out only this year. If the WSL2 were some well-established thing and suddenly Microsoft made it hard, then I would see your point. But you're dropping a Win32 port in favour of something which you yourself seem to think is an unready, unreliable, and incomplete technology. This is like pushing someone into a pool which you can clearly see is full of piranhas and then saying “Well, I didn't put the piranhas in there. The owner of the pool did, and it's their problem.”

I wasn't the one to claim that Windows users are stupid enough that they couldn't even install and use WSL2.

I stand by that claim, but it's not a matter of stupidity. It's a matter that people are all knowledgeable about different things, and most people are not technical enough to go and enable virtualization in their firmware, turn on Hyper-V, and all that jazz. Most of those people probably know about all sorts of subjects that you and I know nothing about and are no less intelligent than we are. As I've said, we're on GitHub here. A fair amount of computer knowledge is a given. We are not representative of users as a whole.

So let me ask a relatively 'naive' question. How much of threat is this to the development of mpv for the Windows platform?

Anyway, why don't you go and ask the mpc-hc project why they don't have a Linux port?

Did they ever have one to begin with? Did they drop it as soon as a half-baked solution for running the Windows version on Linux came out?

From my point of a user I am using mpv on both windows and linux and would be sad to see windows compatibility go. I find it much easier to configure and to use, and it does not have a distraction of a "GUI" which almost always useless for a video playback.
I would not argue that windows is ... bad by design, however mpv is one of the tools that make life there somewhat bearable.
I am not sure how good WSL2 implementation would be and would not trust Windows not to change it again to something like wls3 which would break all compatibility.

I would not argue that windows is ... bad by design [...]

Now, to begin our class on "Poorly Designed Software 101", let's talk about MS-DOS...

Now, to begin our class on "Poorly Designed Software 101", let's talk about MS-DOS...

There hasn't been a version of Windows that included MS-DOS as an important component in 21 years.

Did they ever have one to begin with? Did they drop it as soon as a half-baked solution for running the Windows version on Linux came out?

Thought provoking rebuttal. Wow, this really fires up my electric pulse that travels down the axon until it reaches the synapses, where it then causes the release of neurotransmitters. The synapses are extremely close to the dendrites of the target neuron. This allows the neurotransmitters to diffuse across the intervening space and fit into the receptors that are located on the target neuron. This causes some action to take place in that neuron that will either decrease or increase the membrane potential of the neuron. If it increases the membrane potential (makes it more positive, or depolarizes it.) then it is exciting the neuron, and if it decreases the membrane potential (makes it more negative, or hyper-polarizes it.) then it is inhibiting the neuron. If it causes the membrane potential to pass the firing threshold then it will activate an action potential in the target neuron and send it down its axon.

Thank you for clarifying that you have a brain.

Okay, trying to steer this a bit back to topic:
ICYMI, HLSL and Vulkan:
https://www.khronos.org/blog/hlsl-first-class-vulkan-shading-language

I would not argue that windows is ... bad by design,

Well, you're obviously wrong.

Not sure I worded myself correctly or understood the reply. I detest windows as a tool and tolerate it only because of games. I am not doing any development for windows and plan to never do. I am extremely biased and should not be holding any serious conversation about it. I understand the desire to drop anything windows related, even if it is based only on pure spite.

I just wanted to express that I really enjoy using using mpv on all my systems, linux and windows and just worried that may come to an end. Who knows how wsl2 will work down the road, say, in 2 or 4 years?