Windows 11の新Media Player、RAMを3.5倍多く使用し人気動画コーデックは有料化

 (extremetech.com)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • Windows 11の新しいMedia Playerは、既定のメディアアプリへの移行過程で、メモリ使用量とコーデック課金の両面で議論を呼んでいる
  • Windows Latestのテストでは、アイドル時のRAM使用量は新プレーヤーが約377MB、従来のWindows Media Playerが約103MBで、約3.5倍の差があった
  • ローカル動画ファイルの起動時間も、従来の約2秒から新プレーヤーでは約3秒へと伸び、約50%増加した
  • Microsoftは**HEVC(H.265)**再生を有料の「HEVC Video Extensions」として提供しており、Windows 11 24H2では内蔵のAC-3(Dolby Digital)コーデックも削除した
  • VLCのように独自コーデックを含むサードパーティ製プレーヤーは、Microsoftの有料拡張機能への依存が少ない代替手段になりうる

新Media Playerの性能負荷

  • Windows 11の新しいMedia Playerは、Groove MusicとクラシックWindows Media Playerを置き換える既定アプリの役割を担っている
  • Windows Latestのテストでは、何もしていないアイドル状態でもメモリ使用量の差が大きく現れた
    • 新Media Player: 約377MB RAM
    • 従来のWindows Media Player: 約103MB RAM
    • 差は約3.5倍

ローカル動画の起動速度低下

  • ローカル動画ファイルを開く時間も、新Media Playerの方が長くなっている
    • 従来プレーヤー: 約2秒
    • 新プレーヤー: 約3秒
    • 起動時間は約50%増加

コーデック対応と有料拡張

  • Microsoftは**HEVC(H.265)**再生を、Microsoft Storeの有料「HEVC Video Extensions」アプリとして提供している
  • Windows 11バージョン24H2では、内蔵**AC-3(Dolby Digital)**コーデックが削除された
    • このシステムの新Media Playerは、AC-3オーディオトラックを標準では再生できない

既定アプリの移行と残る選択肢

  • 新Media Playerは、すべてのWindows 11 PCでGroove MusicとクラシックWindows Media Playerを置き換える
  • クラシックWindows Media Playerはオプション機能として引き続き提供されるが、既定の選択肢は新Media Playerへ移りつつある
  • サードパーティ製プレーヤーを使ってもよければ、VLCのような代替手段もある
    • VLCは独自コーデックを含むため、Microsoftの有料追加機能に依存しない

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsの意見

  • HEVCサポートの削除は、Microsoftの選択というよりライセンスプールの値上げが原因である可能性が高い
    最近ではWindows Media Player自体の利用は少なく、HEVC再生はさらに少ないはず。ほとんどのコンテンツ再生はストリーミングとブラウザで行われる。RAM増加も、OSネイティブのフロントエンドAPIではなくJS/TSでフロントエンドを作る流れの結果に見える。アプリ開発の観点では、JS UI開発者の採用ははるかに容易で、LLMもUMLよりReactアプリのほうをはるかにうまく扱える可能性が高い
    [1]: https://arstechnica.com/gadgets/2026/04/lawsuits-licensing-a...

    • ユーザーにとって悪化し、開発者にとって楽になるという折衷は受け入れられず、批判されて当然だ
    • GoogleやAppleも、少し上がったライセンス費用を払う代わりによく使われる動画形式のサポートを削除していたなら、多少は理解できたかもしれない
      Microsoftは成果のないM&Aに大金を使うときには世界中の金を持っているかのように振る舞う。その金の一部はユーザー体験の維持に使うべきだ。Dellのような企業がRAM 8GBの新しいWindowsノートPCを出している状況で、不必要なメモリ肥大化は容認しがたい
    • 今ならAIに、2010年以降に書かれたすべてのUIコードをWin32とMFCでざっくり書き直させても、最近押し付けられているゴミよりずっと良い結果になりそうだ
    • RAM増加がOSネイティブのフロントエンドAPIではなくJS/TSでフロントエンドを実装する流れのせいなら、なぜこうしたマルチOS向けアプリビルドツールはネイティブコードにコンパイルしてネイティブAPIを活用しないのか気になる
      そういうツールは存在しないのだろうか？
    • このアプリはJS/TSを使っていない。見た目を変えたGroove Musicで、全部C++かC#だと思われ、おそらくC# + UWP/WinUI2 XAMLベースだ
      Windows 8.xのXbox Musicは実際にはWeb技術ベースだったが、Windows 10でGroove Musicに変わる際にC#とXAMLで書き直された

  • MicrosoftがCopilotでバイブコーディングをこのレベルまで社内適用しているのは認めるべきかもしれない
    顧客には悪い解決策を使えと勧めながら、社内では別のものを使っているとは言えなくなる

    • このアプリは見た目を変えたGroove Musicで、その大半はWindows 10初期の2014〜2017年に書かれており、Copilotよりはるか以前のコードだ
      Windows 11でMedia Playerにリブランドされたのも2022年ごろなのでその流れ以前であり、その後もほとんど手が入っていない

  • 興味深いのは、これがWeb版もないネイティブアプリなのにHTML/JSで書くことにした点だ
    MicrosoftがWinUIで作り直すと言った後のことなのでなおさら奇妙だ。ネイティブのほうがHTML/JSより摩擦が大きいのは理解できるが、エージェント型開発の登場でその障壁はかなり下がった。きちんと考えて作ったようには見えない

    • HTML/JSは使っていない。少なくともC#をネイティブと見なすなら完全なネイティブアプリで、C#とUWP/WinUI2 XAMLで書かれている
      Windows 8.xのXbox MusicはWeb技術ベースのUIだったが、Windows 10でGroove Musicにリブランドされる際にUIレイヤーが書き直された。Xbox Music自体もZuneのUIレイヤーをスキン変更・再実装したもので、ZuneはC++だったため、すでにネイティブ→Web→ネイティブと一周していることになる。"新しい" Media Playerも、パッケージメタデータでは今なお"ZuneMusic"として識別される。またGroove Musicは主に2014〜2017年のWindows 10初期に書かれ、Windows 11でのMedia Playerへのリブランドも2022年に行われ、その後はほとんど変わっていない
    • 実際のところ、障壁と呼べるものはほとんどない。WinFormsやWPFでUIを作るのは実際には難しくなく、WinUIも同様だと思う
      問題は難しさではなく、多くの人がHTML/JSという快適圏から出ようと試すことすら面倒がっている点にある

  • クラシック版以降、Microsoftのひどいメディアプレーヤーを自発的に使ったことはない気がする
    主にMPC-BEを使い、一部のコーデックで相性が悪いときはVLCを予備として使う。どちらもnVidiaの超解像機能を使える

  • 今でもプレーヤーにすべてのコーデックを入れるためにK-Lite Codec Packを使う人はいるのだろうか？ それとも単にVLCを使うのだろうか？

    • XP時代にはK-Lite Codec PackとCCCP(Combined Community Codec Pack)が好きだった。特にMKVやアニメファイルをいろいろ見ていたころには便利だった
      でも今では、VLCやMPC-HCがデフォルトで再生できないメディアファイルにはほとんど出会わない。入れればそのまま再生される
    • 今ではSMPlayerをインストールするだけで、プレーヤー内にコーデックがすべて含まれている
    • そういうやり方は約10年前に事実上消えた
      ほとんどがH.264、H.265、VP9、AV1、MP3、AACだからだ
    • mpv

  • 最新のMedia Playerがアイドル時に約377MBのRAMを使い、旧プレーヤーは約103MBだったという話だが、何もしないのに103MBでも多く見える

    • メディアプレーヤーなら、アルバムカバー画像や短い音声断片を即座に再生できるようメモリに多めに載せておくのは不自然ではない
      ライブラリ全体のメタデータや複数のインデックスもあるだろう。SSDが高速化したので新しいプレーヤーはキャッシュを減らすはずと期待することもできるが、インターネットベースであれローカルHDD NASであれ、ネットワークストレージ利用の増加がそれを相殺している可能性がある
    • 同じファイルで測ってみたところ、mpvも144MB、VLCも144MBだった
      RAM使用量がもっと少ない別の選択肢はあるのだろうか？

  • HEVC が有料化されたという記事は、2018年の時点ですでに見つかる。
    それに、ここでいう「新しい」Media Player が何を指すのかも曖昧だ。2022年に配布されたアプリなのだから。この記事はひどいが、元ソースの記事はまともだ。
    [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...

  • ほぼ10年前からイマイチだったという意味なので、自分の経験とも一致する

  • 「悪い設計のフラクタル」という表現を PHP に使ってしまったのが惜しいと思えるくらい、Microsoft の出す多くのものによく当てはまる。
    ここ数週間 PowerBI を使っているが、壊れ方が毎回新鮮で、たまに感心してしまう

  • 筋金入りの Microsoft アンチファンだが、比較するなら Apple の Music.app も RAM をだいたい 580MiB ほど使う

    • Windows 版 iTunes はいまだにホースのようにメモリを垂れ流し、オンラインラジオを聴いていると 4GB まで増えることがある

  • 管理コードで書かれているのだから、何を期待するというのか。昔の Windows の中核アプリは純粋な C++ だった。
    「安全な」言語を十分長く求めてきたなら、RAM コストも受け入れるしかない

    • WinUI と WinAppSDK は、ほぼ C++ でできている WinRT の上に作られている。
      ここで皮肉なのは、Windows 部門が Vista が Longhorn に勝ったあと、COM を更新した形で .NET を殺そうとして、AddRef/Release のせいで WPF アプリより遅くなったことだ。
      https://arstechnica.com/features/2012/10/windows-8-and-winrt...