Comment by est31
4 hours ago
Removing HEVC support wasn't their choice but probably stems from the licensing pools increasing their prices [1].
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...
'It's worse for our users, but easier for our developers' is an unacceptable tradeoff, they deserve the backlash.
Very few users care about how much RAM their media player uses. The practical difference between 370MB and 100MB is basically nil for any normal workload. It affects nothing but how many unlikely-to-be-used files fit in the page cache.
Now multiply that opinion by every application on your computer. Including the start bar and notepad.exe.
I mean... Yes, but there's nuance here.
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.
No, no and no.
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.
4 replies →
There are 100s of processes running on my Windows without starting anything explicitly. They are using more than 10 gb of RAM. I am already feeling the consequences of this sloppiness. Especially that my IDE/compiler/emulator easily use 20+ GB. My 32 GB of memory is not enough somehow…
It does not matter how well or poorly Chrome mismanages memory, 400MB is still 400MB. If that 400MB is 10% of the free RAM after the share the OS takes, then that is a hefty toll. And the regular updates Windows 11 users are getting are famously not providing value, but taking value away. Case in point right here is the new media player.
1 reply →
IME, there is a negative correlation “justifies increased memory consumption by citing DX” and “ships code with fewer critical issues.”
A single Chrome tab does not use gigabytes. In fact, this app IS a Chrome tab! It's web based, so it's using Edge, which is just Chrome in a trenchcoat.
There is no nuance in 400%...
2 replies →
How come I have never seen this tradeoff work in practice?
1 reply →
The problem is that it does not. At all.
If Google and Apple also decided to remove support for common video formats instead of just paying the slightly higher licensing fee, I might have some sympathy.
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.
It doesn't use JS/TS, it's a reskinned Groove Music and is all either C++ or C# (I think C#) + UWP/WinUI2 XAML
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
The modern native frontend APIs aren’t exactly lightweight themselves…
Wouldn't HEVC licences already be paid by the hardware/gpu vendors on most devices? And Microsoft just exposes api for that hardware?
Is this just for a purely software implementation of it?
Nah. Search for "Nokia h264" and see for yourself how they've sued like every single vendor in recent years, because they want to double dip.
>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
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?
Microsoft has written more application development frameworks than you can shake a stick at. They've also failed to gain traction with virtually all of them, even internally.
I believe, at this point they could direct AI to vibe rewrite every UI code written after 2010 in Win32 and MFC and the result would still be vastly better than crap they push us nowadays.
The HEVC support is free is you know the "secret" link:
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...
> The advantages are more on the development side of those apps
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.
> The advantages are more on the development side of those apps, i.e. you can hire JS UI devs way more easily
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!
It must be possible these days to allow designers to prototype UIs in WebTech and then convert it to native code.
HEVC is provided by the official, licensed h265 standard. The open source ~HEVC-compliant codec library is x265 created by VideoLAN but was apparently not an option for Microsoft.
It's not about the code. The open source implementations are also subject to patent laws, they just ignore them and put the responsibility on the user. And users don't know/care about it so in the end they get playback for free.
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.
x265 is an encoder, not a decoder. Also, being open source doesn't matter here: an open source library, even with a patent grant, doesn't give you a license to someone else's patents.
VideoLAN wants you to pay the royalty for x265 and you'll get sued by patent pools if you use it in a company (and are big enough).
Windows 11 is not free software. Apple macOS, iOS, ipadOS all support HEVC and Dolby because Apple pays licensing costs, likewise Microsoft should do the same for Windows users, it is not free OS.
I don’t recall ever having a good time using a native Mac OS video player.
QuickTime is fine. It does the basics, is intuitive, and fast.