1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Le nouveau Media Player de Windows 11 suscite une controverse, entre la transition vers l’application multimédia par défaut, une consommation mémoire plus élevée et la facturation de codecs
  • D’après les tests de Windows Latest, la consommation de RAM au repos est d’environ 377 Mo pour le nouveau lecteur, contre environ 103 Mo pour l’ancien Windows Media Player, soit un écart d’environ 3,5 fois
  • Le temps de lancement des fichiers vidéo locaux passe lui aussi d’environ 2 secondes avec l’ancien lecteur à environ 3 secondes avec le nouveau, soit une hausse d’environ 50 %
  • Microsoft propose la lecture HEVC(H.265) via l’extension payante « HEVC Video Extensions », et supprime aussi le codec AC-3 (Dolby Digital) intégré dans Windows 11 24H2
  • Les lecteurs tiers comme VLC, qui intègrent leurs propres codecs, peuvent constituer une alternative moins dépendante des extensions payantes de Microsoft

La charge de performance du nouveau Media Player

  • Le nouveau Media Player de Windows 11 joue le rôle d’application par défaut en remplacement de Groove Music et du Windows Media Player classique
  • Dans les tests de Windows Latest, une forte différence de consommation mémoire apparaît même au repos, sans aucune activité
    • Nouveau Media Player : environ 377 Mo de RAM
    • Ancien Windows Media Player : environ 103 Mo de RAM
    • Soit une différence d’environ 3,5 fois

Baisse de la vitesse de lancement des vidéos locales

  • Le temps d’ouverture des fichiers vidéo locaux est lui aussi plus long avec le nouveau Media Player
    • Ancien lecteur : environ 2 secondes
    • Nouveau lecteur : environ 3 secondes
    • Soit un temps de démarrage en hausse d’environ 50 %

Prise en charge des codecs et extensions payantes

  • Microsoft propose la lecture HEVC(H.265) via l’application payante « HEVC Video Extensions » sur le Microsoft Store
  • Dans la version 24H2 de Windows 11, le codec AC-3(Dolby Digital) intégré est supprimé
    • Sur ces systèmes, le nouveau Media Player ne peut pas lire par défaut les pistes audio AC-3

Changement d’application par défaut et options restantes

  • Le nouveau Media Player remplace Groove Music et le Windows Media Player classique sur tous les PC Windows 11
  • Le Windows Media Player classique reste disponible comme composant facultatif, mais le choix par défaut bascule vers le nouveau Media Player
  • Si l’utilisation d’un lecteur tiers ne pose pas de problème, des alternatives comme VLC existent aussi
    • VLC intègre ses propres codecs et ne dépend pas des extensions payantes de Microsoft

1 commentaires

 
GN⁺ 4 시간 전
Avis Hacker News
  • La suppression de la prise en charge HEVC est probablement moins un choix de Microsoft qu’une conséquence de la hausse des tarifs des pools de licences
    De nos jours, très peu de gens utilisent Windows Media Player, et encore moins pour lire du HEVC. La plupart de la lecture de contenu se fait en streaming et dans le navigateur. La hausse de l’usage RAM semble aussi être le résultat de la tendance à construire les frontends en JS/TS plutôt qu’avec les API frontend natives du système d’exploitation. Côté développement d’apps, il est bien plus facile de recruter des développeurs UI JS, et les LLM sont probablement bien meilleurs avec des apps React qu’avec UML
    [1]: https://arstechnica.com/gadgets/2026/04/lawsuits-licensing-a...

    • Ce compromis qui dégrade l’expérience pour les utilisateurs tout en facilitant la vie des développeurs est inacceptable et mérite d’être critiqué
    • J’aurais peut-être un peu compris si Google et Apple avaient eux aussi supprimé la prise en charge de formats vidéo courants au lieu de payer des frais de licence légèrement plus élevés
      Microsoft agit comme s’il avait tout l’argent du monde quand il s’agit de dépenser des fortunes dans des acquisitions sans résultat. Une partie de cet argent devrait servir à préserver l’expérience utilisateur. Quand des entreprises comme Dell vendent encore de nouveaux PC portables Windows avec 8 Go de RAM, un gonflement mémoire inutile est difficilement acceptable
    • À ce stade, on pourrait demander à une IA de réécrire grossièrement tout le code UI écrit depuis 2010 en Win32 et MFC, et le résultat serait sans doute bien meilleur que les horreurs qu’on nous impose aujourd’hui
    • Si l’augmentation de la RAM vient de cette tendance à faire l’ingénierie frontend en JS/TS au lieu d’utiliser les API frontend natives de l’OS, je me demande pourquoi ces outils de build d’apps multiplateformes ne compilent pas en code natif et n’exploitent pas les API natives
      Est-ce que ce genre d’outil n’existe tout simplement pas ?
    • Cette app n’utilise pas JS/TS. C’est Groove Music avec un autre habillage, probablement entièrement en C++ ou en C#, sans doute basé sur C# + UWP/WinUI2 XAML
      Xbox Music sous Windows 8.x était effectivement basé sur des technologies web, mais il a été réécrit en C# et XAML lorsqu’il est devenu Groove Music sous Windows 10
  • Il faut reconnaître que Microsoft pousse l’adoption interne du vibe coding avec Copilot assez loin
    On ne peut pas vraiment recommander à ses clients de faire de mauvaises solutions tout en utilisant autre chose en interne

    • Cette app est Groove Music avec un autre habillage, et l’essentiel a été écrit au début de Windows 10, entre 2014 et 2017, donc bien avant Copilot
      Le rebranding en Media Player sous Windows 11 date aussi d’environ 2022, donc cela précède cette vague, et depuis, l’app a à peine été modifiée
  • Ce qui est intéressant, c’est qu’ils aient décidé de l’écrire en HTML/JS alors que c’est une app native sans même de version web
    C’est d’autant plus étrange après que Microsoft a annoncé vouloir tout refaire en WinUI. Je comprends que le natif impose plus de friction que HTML/JS, mais avec l’arrivée du développement agentique, cette barrière a beaucoup baissé. On n’a pas l’impression que cela a été vraiment réfléchi

    • Elle n’utilise pas HTML/JS. Si on considère C# comme natif, c’est une app entièrement native, écrite en C# et UWP/WinUI2 XAML au minimum
      L’UI de Xbox Music sous Windows 8.x était basée sur des technologies web, mais la couche UI a été réécrite lors du rebranding en Groove Music sous Windows 10. Xbox Music lui-même était déjà un reskin / une réécriture de la couche UI de Zune, et Zune était en C++, donc l’app a déjà fait un cycle complet natif → web → natif. Même le « nouveau » Media Player est encore identifié comme « ZuneMusic » dans les métadonnées du paquet. De plus, Groove Music a été écrit principalement au début de Windows 10 entre 2014 et 2017, et le rebranding en Media Player sous Windows 11 a eu lieu en 2022, avec très peu de changements depuis
    • En réalité, il n’y a presque pas de barrière. Construire une UI en WinForms ou en WPF n’est pas vraiment difficile, et je suppose que WinUI n’est pas différent
      Le problème n’est pas la difficulté, mais le fait que beaucoup de gens sont trop paresseux pour essayer de sortir de leur zone de confort HTML/JS
  • Je ne crois pas avoir utilisé volontairement le piètre lecteur multimédia de Microsoft depuis la version classique
    J’utilise surtout MPC-BE, avec VLC en solution de secours si certains codecs passent mal. Les deux peuvent aussi exploiter la super-résolution de nVidia

  • Est-ce qu’il y a encore des gens qui utilisent K-Lite Codec Pack pour installer tous les codecs sur leur lecteur, ou est-ce que tout le monde utilise simplement VLC maintenant ?

    • À l’époque de XP, j’aimais bien K-Lite Codec Pack et CCCP (Combined Community Codec Pack). C’était particulièrement utile quand je regardais toutes sortes de fichiers MKV et d’animés
      Mais aujourd’hui, je tombe presque jamais sur un fichier multimédia que VLC ou MPC-HC ne peut pas lire par défaut. On le lance, et ça marche
    • De nos jours, il suffit d’installer SMPlayer pour avoir tous les codecs intégrés au lecteur
    • Cette approche a pratiquement disparu il y a une dizaine d’années
      Parce que tout le monde est passé à H.264, H.265, VP9, AV1, MP3 et AAC
    • mpv
  • Le fait que le Media Player récent consomme environ 377 Mo de RAM au repos, contre environ 103 Mo pour l’ancien lecteur, fait déjà paraître 103 Mo élevé pour ne rien faire

    • Pour un lecteur multimédia, il n’est pas étrange de garder beaucoup de choses en mémoire afin d’afficher immédiatement les pochettes d’album et de lire de courts extraits audio
      Il y a probablement aussi les métadonnées de toute la bibliothèque et divers index. Les SSD étant plus rapides, on pourrait s’attendre à ce que le nouveau lecteur mette moins en cache, mais la hausse de l’usage de stockage réseau — qu’il s’agisse d’Internet ou d’un NAS HDD local — peut compenser cela
    • En testant avec le même fichier, j’obtiens aussi 144 Mo pour mpv et 144 Mo pour VLC
      Existe-t-il une autre alternative qui utilise moins de RAM ?
  • On peut déjà trouver des articles de 2018 disant que le HEVC est devenu payant
    Et ici, ce que signifie le « nouveau » Media Player reste flou. C’est une application distribuée en 2022. Cet article est bâclé, alors que l’article source d’origine est correct
    [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...

    • Si ça veut dire que c’était déjà médiocre depuis presque 10 ans, alors ça correspond aussi à mon expérience
  • Je regrette presque d’avoir utilisé l’expression « fractale de mauvaise conception » pour PHP, tellement elle convient bien à beaucoup de choses produites par Microsoft
    J’utilise PowerBI depuis quelques semaines, et je suis parfois presque admiratif devant l’originalité de ses façons de casser

  • Je suis un anti-fan certifié de Microsoft, mais à titre de comparaison, Music.app d’Apple consomme aussi environ 580 MiB de RAM

    • iTunes pour Windows a toujours des fuites mémoire dignes d’un tuyau percé, et en écoutant la radio en ligne, ça peut monter jusqu’à 4 GB
  • C’est écrit en code managé, alors à quoi s’attendre ? Les applications système essentielles de Windows étaient autrefois en pur C++
    Si on a réclamé assez longtemps des langages « sûrs », il faut aussi accepter le coût en RAM

    • WinUI et WinAppSDK sont construits au-dessus de WinRT, qui est majoritairement en C++
      Ce qui est amusant ici, c’est que l’équipe Windows a essayé de tuer .NET avec une version modernisée de COM après que Vista a vaincu Longhorn, et que c’est devenu plus lent que les applications WPF à cause de AddRef/Release
      https://arstechnica.com/features/2012/10/windows-8-and-winrt...