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.
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.
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…
> 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!
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.
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.
> 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.
I kinda have to hand it to Microsoft for dogfooding vibecoding with Copilot to such an extent. You can't say they encourage their customers to use a bad solution while doing something different in-house.
I don't think I've ever voluntarily used their shitty media player since the classic version. MPC-BE (some folks use MPC-HC) is my goto with VLC as a backup if certain codecs don't play nice with it. I'm able to use nVidia super resolution with them as well.
I loved the K-Lite Codec Pack and CCCP (Combined Community Codec Pack) back in the XP days, especially while exploring MKVs and anime, but I virtually never run into a media file that VLC or MPC-HC can't play by default these days. Just drop it in and it plays.
Windows media player always sort of sucked. I remember when I discovered mplayer. What a breath of fresh air by comparison. ostensibly worse, with it's barely there user interface. But... all it did was play video, it would play anything, no more faffing about with installing codecs or different programs for different formats. No annoying ui that tried too hard to look like a piece of hi-fi gear.
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
The article mentions W11 24H2 but that might have been the only update the article had if it was first published much earlier. Might have even been an advance warning about AC-3 even before 24H2 was released.
Otherwise looks a bit deceptively like new findings just because the date at the top of the page says June 18, 2026 :\
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...