Windows media player probably sees very little usage nowadays and probably even less for HEVC, when most content playback happens via streaming and browsers today.
As for the RAM increase, well that's probably a consequence of the general trend of doing frontend engineering via JS/TS instead of using OS native frontend APIs. The advantages are more on the development side of those apps, i.e. you can hire JS UI devs way more easily, and probably LLMs know way better how to deal with a react app than an UML one.
[1]: https://arstechnica.com/gadgets/2026/04/lawsuits-licensing-a...
What's easiest for both users and developers is royalty-free video formats.
AV1 is solution to these video format licensing problems. Microsoft is part of the Alliance for Open Media: https://aomedia.org/about/members/
Dolby has made direct threats to the royalty-free status of AV1: https://arstechnica.com/gadgets/2026/03/av1s-open-royalty-fr...
So Microsoft and all the AOMedia members will need to defend AV1 if they want it to remain royalty-free.
That's how a lot of software gets done these days. More bloat, less features, lots of inconsistencies.
Using 400 MB of RAM vs 100 MB of RAM is close to unnoticeable in a world of a GB+ for a single Chrome tab... And if "easier for our developers" means the end user is getting more regular updates with fewer critical issues, then it's not an uncomplicated tradeoff at all, parts of it are actually synergistic.
Last year I paid money to upgrade my laptop's RAM from 16 to 32 GB. I didn't pay it so apps could just be more bloated without offering any significant benefit.
Developers should respect and be efficient using hardware resources. There are no excuses for that.
Microsoft thinks they have all the money in the world when it comes to wasting huge sums on mergers and acquisitions that go nowhere. Spend some on maintaining the user experience.
Also, with Dell and others releasing new Windows laptops with 8 Gigs of RAM, needless memory bloat is unacceptable.
Can someone explain to me why these multi operating system app building tools don’t compile down to native code and leverage native APIs? Is there nothing like that available?
* (at least within the Windows organization; maybe not so much in other parts of Microsoft)
Xbox Music in Windows 8.x was actually web tech based, but was rewritten into C# and XAML when it was turned into Groove Music in Windows 10
How do we live in a world where simultaneously "human coding is dead" and also "we need to trade performance for developer efficiency"? I thought code is free now?
Also--this is Microsoft! It's their OS!
Microsoft should just come out and say that the whole of Win32 is deprecated and kept around for legacy compatibility only, and all new software should be written in Electron. They're already acting that way, why not make it official?
Is this just for a purely software implementation of it?
Ah yes, we don't want Microsoft to run out of JavaScript developers to keep improving their desktop operating system in this manner. More webdevs, that's what's going to fix what ails Windows!
I mean, I agree, but Microsoft of all companies really should be invested in building Windows native applications. If they can't be fucked to build Windows-native applications, why would anyone else?
Microsoft should be setting the example, and the high bar of what Windows-native quality software should be. It's frankly embarrassing for them that they can't or won't do it.
ms-windows-store://pdp?productId=9N4WGH0Z6VHQ
It's a wide know workaround, been there for years, obviously Microsoft pretends they don't know about it.
https://www.howtogeek.com/680690/how-to-install-free-hevc-co...
That is why some distributions (RHEL derivatives, for example) do not ship support for many codecs out of the box and they make you jump to (admittedly simple) hoops to get it working.
/clutches pearls
Won't somebody think of the trillion-dollar companies!
Mostly because everything is H.264, H.265, VP9, AV1, MP3 or AAC.
Running MS Windows these days is like having a "kick me, hard" sign on your back. Or, you're treated like a money and data piñata.
Some software is invasive in that it actively scans for VM's and does bad stuff.
(I don't know if this can be sarcasm anymore.)
What is Windows's moat among the business crowd? Is it the "can't get fired if they buy Windows" mantra?
(Well, now they can get laid off anyway.)
> What is Windows's moat among the business crowd?
The moat is that it just works[1] will all of their software developed over the past 30 years, and support contracts/staff[2] is incredibly easy to obtain.
1. Contrarians will say that wine has better backwards compatibility than windows, but that's just cope and limited to a handful of games (and even then it's only because people made elaborate compatibility profiles for those specific games, those won't exist for internal apps).
2. Linux sysadmins are easy to obtain, but dedicated staff to support a desktop linux fleet is still fairly niche. There is some overlap in skillset and sysadmins can learn, of course.
Don't get me wrong, I totally understand the barrier of friction that native presents compared to html/js, but that barrier has lowered so much with the advent of agentic development. It just feels like things weren't thought out.
2. it's not "after"; Groove Music was largely written in 2014-2017 in the early Windows 10 days, and even its rebrand as Media Player in Windows 11 happened in 2022, and it's barely been touched since then.
It can count as native. You can turn on Native AOT compilation:
https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
Windows core apps used to be pure C++.
Cry long enough about "safe" languages and expect to take the RAM hit.
That is the whole joke about it, Windows division tried to kill .NET with their updated COM based on Vista victory over Longhorn, and the whole AddRef/Release makes it slower than WPF applications.
https://arstechnica.com/features/2012/10/windows-8-and-winrt...
See WinUi and WinAppSDK repos on Github.
You talk as if language choice dictates performance but even C# allows active stack allocation for optimization. Conversely C++ becomes a bloated mess if poorly implemented. In fact terrible C++ code has caused issues for decades.
Ultimately the root cause is that as users' available memory expanded, developers (or rather, management) stopped caring about memory usage. This approach is finally hitting its limit and alternatives are emerging.
A joke can be "funny because it's true"
EDIT: Also, what do they mean by "new" Media Player? It shipped in 2022 [1]. This article is garbage. The source article [2] is fine.
[0]: https://www.windowscentral.com/microsoft-now-charging-hevc-v...
[1]: https://en.wikipedia.org/wiki/Windows_Media_Player_(2022)
[2]: https://www.windowslatest.com/2026/06/16/microsoft-reveals-w...
I am not sure exactly what happened to it, it's maintainer moved on to other projects I imagine, it's current equivalent is probably mpv
Otherwise looks a bit deceptively like new findings just because the date at the top of the page says June 18, 2026 :\
even 103MB sound like a lot for doing nothing
We might expect newer players to cache less because SSDs are fast, but perhaps this is offset by the increasing use of network storage, whether it’s internet-based or a local HDD NAS.
Reccomendations for other lower ram solutions?
I understand that project might have started way before the public statement but it really doesn't look good from a PR standpoint.
As a part of the user-mode half of the GPU driver, GPU vendors ship media foundation transform DLLs to use HEVC hardware codecs. Don’t AMD, Intel and nVidia already pay patent royalties? I expect them to include into price of the GPUs with hardware support i.e. all of them made in the last decade.
Dropping AC3 does seem unnecessary.
Last update seems to be from 2022 at mplayerhq.hu.
Used to be the go-to that played basically anything years ago.
The suffering will continue until there are good alternatives.
https://www.majorgeeks.com/files/details/dolby_ac_3ac_4_inst...
and then you recieve the latest update from windows store.
