1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Media Player mới trên Windows 11 đang gây tranh cãi cùng lúc về mức sử dụng bộ nhớ và việc tính phí codec trong quá trình trở thành ứng dụng media mặc định
  • Theo thử nghiệm của Windows Latest, mức sử dụng RAM khi nhàn rỗi của trình phát mới là khoảng 377MB, trong khi Windows Media Player cũ là khoảng 103MB, chênh lệch khoảng 3,5 lần
  • Thời gian khởi chạy tệp video cục bộ cũng tăng từ khoảng 2 giây ở bản cũ lên khoảng 3 giây ở trình phát mới, tức tăng khoảng 50%
  • Microsoft cung cấp phát lại HEVC(H.265) dưới dạng ứng dụng trả phí “HEVC Video Extensions”, và trong Windows 11 24H2 cũng đã loại bỏ codec AC-3 (Dolby Digital) tích hợp sẵn
  • Các trình phát bên thứ ba có kèm codec riêng như VLC có thể là lựa chọn thay thế ít phụ thuộc hơn vào các tiện ích mở rộng trả phí của Microsoft

Gánh nặng hiệu năng của Media Player mới

  • Media Player mới trên Windows 11 đảm nhận vai trò ứng dụng mặc định thay thế Groove Music và Windows Media Player cổ điển
  • Trong thử nghiệm của Windows Latest, chênh lệch về mức dùng bộ nhớ xuất hiện rất rõ ngay cả khi ở trạng thái nhàn rỗi không làm gì
    • Media Player mới: khoảng 377MB RAM
    • Windows Media Player cũ: khoảng 103MB RAM
    • Chênh lệch khoảng 3,5 lần

Tốc độ mở video cục bộ chậm hơn

  • Thời gian mở tệp video cục bộ cũng dài hơn trên Media Player mới
    • Trình phát cũ: khoảng 2 giây
    • Trình phát mới: khoảng 3 giây
    • Thời gian khởi chạy tăng khoảng 50%

Hỗ trợ codec và tiện ích mở rộng trả phí

  • Microsoft cung cấp phát lại HEVC(H.265) thông qua ứng dụng trả phí “HEVC Video Extensions” trên Microsoft Store
  • Ở Windows 11 phiên bản 24H2, codec AC-3(Dolby Digital) tích hợp sẵn đã bị loại bỏ
    • Media Player mới trên hệ thống đó không thể phát mặc định các track âm thanh AC-3

Chuyển đổi ứng dụng mặc định và những lựa chọn còn lại

  • Media Player mới thay thế Groove Music và Windows Media Player cổ điển trên mọi PC Windows 11
  • Windows Media Player cổ điển vẫn tiếp tục được cung cấp dưới dạng thành phần tùy chọn, nhưng lựa chọn mặc định đang chuyển sang Media Player mới
  • Nếu chấp nhận dùng trình phát bên thứ ba, vẫn có các lựa chọn thay thế như VLC
    • VLC đi kèm codec riêng nên không phụ thuộc vào các tiện ích bổ sung trả phí của Microsoft

1 bình luận

 
Ý kiến trên Hacker News
  • Việc loại bỏ hỗ trợ HEVC có lẽ không hẳn là lựa chọn của Microsoft mà là do giá của nhóm cấp phép tăng lên
    Ngày nay bản thân mức sử dụng Windows Media Player đã thấp, và việc phát HEVC có lẽ còn ít hơn nữa. Phần lớn việc phát nội dung diễn ra qua streaming và trình duyệt. Việc RAM tăng cũng có vẻ là hệ quả của xu hướng làm frontend bằng JS/TS thay vì dùng API frontend native của hệ điều hành. Từ góc độ phát triển ứng dụng, việc tuyển lập trình viên UI dùng JS dễ hơn nhiều, và LLM cũng có khả năng xử lý ứng dụng React tốt hơn UML rất nhiều
    [1]: https://arstechnica.com/gadgets/2026/04/lawsuits-licensing-a...

    • Không thể chấp nhận kiểu đánh đổi tệ hơn cho người dùng nhưng dễ hơn cho nhà phát triển, và nó hoàn toàn đáng bị chỉ trích
    • Có lẽ còn hiểu được phần nào nếu Google và Apple cũng bỏ hỗ trợ các định dạng video phổ biến thay vì trả chi phí cấp phép tăng nhẹ
      Microsoft hành xử như thể có vô hạn tiền khi chi mạnh cho các thương vụ M&A không mang lại kết quả. Họ nên dùng một phần số tiền đó để duy trì trải nghiệm người dùng. Trong bối cảnh các hãng như Dell vẫn tung ra laptop Windows mới chỉ có 8GB RAM, việc phình bộ nhớ không cần thiết rất khó chấp nhận
    • Đến lúc này, có khi cứ để AI viết lại đại khái toàn bộ mã UI được viết từ sau năm 2010 sang Win32 và MFC thì kết quả vẫn sẽ tốt hơn nhiều so với đống rác đang bị nhồi ép hiện nay
    • Nếu việc tăng RAM là do xu hướng làm frontend bằng JS/TS thay vì API frontend native của OS, thì tôi thắc mắc vì sao các công cụ build ứng dụng đa nền tảng này không biên dịch sang mã native và tận dụng API native
      Chẳng lẽ không hề có công cụ nào như vậy?
    • Ứng dụng này không dùng JS/TS. Nó là Groove Music đổi skin, có lẽ toàn bộ là C++ hoặc C#, và nhiều khả năng dựa trên C# + UWP/WinUI2 XAML
      Xbox Music trên Windows 8.x thực ra dùng công nghệ web, nhưng khi đổi sang Groove Music trên Windows 10 thì đã được viết lại bằng C# và XAML
  • Phải công nhận Microsoft áp dụng vibe coding với Copilot vào nội bộ đến mức này
    Họ không thể vừa khuyên khách hàng dùng giải pháp tệ vừa tự dùng thứ khác trong nội bộ được nữa

    • Ứng dụng này là Groove Music đổi skin, và phần lớn được viết trong giai đoạn đầu Windows 10 từ 2014~2017, tức là ra đời từ rất lâu trước Copilot
      Việc đổi thương hiệu thành Media Player trên Windows 11 cũng vào khoảng năm 2022 nên còn sớm hơn làn sóng đó, và từ sau đó gần như không đụng đến nữa
  • Điều thú vị là đây là ứng dụng native, thậm chí không có cả bản web, mà họ vẫn quyết định viết bằng HTML/JS
    Điều đó càng lạ hơn vì việc này xảy ra sau khi Microsoft nói sẽ làm lại bằng WinUI. Tôi hiểu native có nhiều ma sát hơn HTML/JS, nhưng với sự xuất hiện của phát triển kiểu agent, rào cản đó đã giảm đi rất nhiều. Có vẻ như họ không suy nghĩ nghiêm túc về chuyện này

    • Không dùng HTML/JS. Ít nhất nếu xem C# là native thì đây là một ứng dụng native hoàn chỉnh, được viết bằng C# và UWP/WinUI2 XAML
      UI của Xbox Music trên Windows 8.x dùng công nghệ web, nhưng khi đổi thương hiệu thành Groove Music trên Windows 10 thì lớp UI đã được viết lại. Bản thân Xbox Music cũng là lớp UI của Zune được thay skin/viết lại, còn Zune là C++, nên thực chất đã đi một vòng native → web → native. Ngay cả Media Player “mới” trong metadata gói ứng dụng vẫn được định danh là “ZuneMusic”. Ngoài ra, Groove Music chủ yếu được viết trong giai đoạn đầu Windows 10 khoảng 2014~2017, và việc đổi thương hiệu thành Media Player trên Windows 11 diễn ra vào năm 2022, sau đó gần như không thay đổi gì
    • Thực ra gần như chẳng có rào cản gì đáng kể. Làm UI bằng WinForms hay WPF thực sự không khó, và tôi nghĩ WinUI cũng vậy
      Vấn đề không phải là khó, mà là nhiều người lười đến mức không muốn thử bước ra khỏi vùng an toàn HTML/JS
  • Có lẽ tôi chưa từng tự nguyện dùng trình phát media tệ hại của Microsoft kể từ sau bản classic
    Tôi chủ yếu dùng MPC-BE, và nếu có codec nào đó không tương thích tốt thì dùng VLC làm phương án dự phòng. Cả hai đều có thể dùng tính năng siêu phân giải của nVidia

  • Bây giờ còn ai cài K-Lite Codec Pack để có đủ mọi codec cho trình phát không? Hay mọi người cứ dùng VLC thôi?

    • Thời XP tôi rất thích K-Lite Codec Pack và CCCP (Combined Community Codec Pack). Đặc biệt hữu ích hồi còn xem đủ loại file MKV và anime
      Nhưng giờ tôi hầu như không gặp file media nào mà VLC hay MPC-HC không phát được mặc định. Chỉ cần thả vào là chạy
    • Giờ chỉ cần cài SMPlayer là toàn bộ codec đã đi kèm ngay trong trình phát
    • Kiểu đó thực chất đã biến mất từ khoảng 10 năm trước
      Vì hầu hết đều là H.264, H.265, VP9, AV1, MP3, AAC
    • mpv
  • Media Player mới dùng khoảng 377MB RAM khi để idle, còn trình phát cũ là khoảng 103MB, nhưng với một ứng dụng không làm gì thì 103MB cũng đã có vẻ nhiều rồi

    • Với một trình phát media, việc giữ sẵn nhiều ảnh bìa album và các đoạn âm thanh ngắn trong bộ nhớ để phát ngay lập tức cũng không có gì lạ
      Ngoài ra còn có metadata của toàn bộ thư viện và nhiều chỉ mục khác nhau. SSD đã nhanh hơn nên có thể kỳ vọng trình phát mới sẽ cache ít hơn, nhưng việc tăng sử dụng lưu trữ qua mạng — dù là dịch vụ trên internet hay NAS HDD nội bộ — có thể bù trừ điều đó
    • Tôi đo lại với cùng một file thì mpv cũng là 144MB, VLC cũng 144MB
      Có lựa chọn nào khác dùng ít RAM hơn không?
  • Có thể tìm thấy các bài viết nói rằng HEVC đã bị tính phí từ tận năm 2018
    Và ở đây cũng khá mơ hồ không rõ Media Player “mới” mà họ nói đến là gì. Đây là ứng dụng đã được phát hành vào năm 2022. Bài này viết cẩu thả, còn bài từ nguồn gốc thì ổn
    [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...

    • Vậy tức là nó đã tệ từ gần 10 năm trước rồi, khá khớp với trải nghiệm của tôi
  • Cụm từ “fractal của thiết kế tồi” dùng cho PHP thì hơi phí, vì nó lại hợp với rất nhiều thứ do Microsoft làm ra
    Tôi đã dùng PowerBI suốt vài tuần nay, và đôi khi phải trầm trồ vì những kiểu hỏng hóc mới lạ của nó

  • Dù là một anti-fan Microsoft chính hiệu, nhưng để so sánh thì Music.app của Apple cũng ngốn khoảng 580MiB RAM

    • iTunes trên Windows đến giờ vẫn rò rỉ bộ nhớ như vòi nước, và nếu nghe radio online thì có thể tăng lên tới 4GB
  • Được viết bằng managed code thì còn mong đợi gì nữa? Các ứng dụng cốt lõi của Windows ngày xưa đều là C++ thuần
    Nếu đã đòi hỏi ngôn ngữ “an toàn” đủ lâu thì cũng phải chấp nhận chi phí RAM

    • WinUI và WinAppSDK phần lớn được xây trên WinRT, vốn chủ yếu là C++
      Điều buồn cười ở đây là bộ phận Windows từng muốn dùng phiên bản COM được làm mới sau khi Vista thắng Longhorn để khai tử .NET, và rốt cuộc nó lại chậm hơn cả ứng dụng WPF vì AddRef/Release
      https://arstechnica.com/features/2012/10/windows-8-and-winrt...