Inquiry Regarding Native H.266 (VVC) Support and Media Playback in Windows 11

Question

Inquiry Regarding Native H.266 (VVC) Support and Media Playback in Windows 11

Jennie 20

I recently purchased a new PC equipped with the latest hardware designed to support H.266 (VVC) video decoding. However, I discovered that the default Windows Media Player is completely unable to play H.266 video files.

I would like to know:

1. Is the current inability to play H.266 (VVC) files due to an inherent OS limitation within Windows 11 and its default Media Player?

2. Is there an official, downloadable codec extension available that would enable Windows Media Player to process H.266 files?

3. __I__s there a way for the PC manufacturer or the end-user to manually activate this capability?

4. Does Microsoft have a roadmap or an estimated timeline for introducing native H.266/VVC support to Windows 11 and its default media applications?

5. What is Microsoft's official recommendation or solution for consumers to achieve hardware-accelerated H.266 playback on the current operating system?

0 个注释

问题作者接受的答案

0 个其他答案

你的答案

Answer 1

Taki Ly (WICLOUD CORPORATION) 5,055 Microsoft 外部员工审查方

Hello @Jennie ,

Based on the Microsoft documentation I was able to find, Windows Media Player and the Windows media stack document support for codecs referenced in Microsoft’s file types supported by Windows Media Player documentation. However, I could not find any official Microsoft documentation confirming native H.266/VVC (vvc1) playback support in Windows Media Player or the default Windows 11 media experience.

Because of that, I can’t confirm that H.266/VVC is supported natively in the built-in app, and the behavior you’re seeing appears consistent with a codec support limitation in the Windows media stack rather than a hardware issue.

As a result, there seems to be no official Microsoft roadmap or timeline for VVC support, any documented Microsoft recommendation for hardware-accelerated VVC playback on the current operating system, or any information about manually enabling this capability.

Hope this information clarifies your questions. If you found my answer helpful, please follow this guide to provide feedback.

Thank you.

Taki Ly (WICLOUD CORPORATION) 5,055 信誉分 Microsoft 外部员工审查方

2026-04-06T02:24:35.44+00:00

Hi @Jennie ,

I’ve shared an answer. Did you get a chance to look at it? If you have any questions, just drop a comment and I’ll try my best to help.
Jennie 20 信誉分

2026-04-07T02:11:34.6066667+00:00

Hi Taki Ly,

Thank you very much for your answers to my questions.

During recent testing on my laptop equipped with an Intel Core Ultra 7 processor—hardware that explicitly supports H.266 decoding—I observed a significant functional divergence. While the default Windows media player fails to utilize the hardware decoding capabilities for VVC playback, executing the playback via FFmpeg successfully calls the underlying chip's hardware acceleration.

I would appreciate your official insights on the following questions:

1. Mechanism of Underlying Hardware Calls: Why is FFmpeg able to successfully bypass or succeed in interfacing with the underlying chip's hardware acceleration for VVC playback, whereas the native Windows media player fails to do so under the exact same system environment?

2. OS-Level Support and Authorization: Does the Windows operating system natively support and authorize third-party tools like FFmpeg to implement these direct, low-level underlying hardware calls?

3. API Routing: Which specific Windows APIs (e.g., D3D11VA, D3D12 Video, or DXVA) are facilitating this VVC hardware decoding path for FFmpeg, and why are these same pathways seemingly unavailable or restricted for native Windows playback tools?

Understanding the precise architectural mechanisms of how Windows routes and authorizes these hardware calls for VVC is essential. I look forward to your detailed and technically specific response.
Taki Ly (WICLOUD CORPORATION) 5,055 信誉分 Microsoft 外部员工审查方

2026-04-08T10:39:11.4766667+00:00

Hi @Jennie ,

What you observed with FFmpeg does not necessarily mean the built-in Windows player has the same level of support. A third-party application can use its own playback pipeline and may be able to work with hardware acceleration differently from the native Windows media experience. Microsoft’s documentation for Supporting Direct3D 11 Video Decoding in Media Foundation shows that hardware decoding can involve the graphics driver and Media Foundation components, so hardware capability may exist at the platform level even when native playback support is not documented in the built-in player.

In general, Windows does provide public media and graphics interfaces that applications can use, depending on hardware and driver support. Microsoft also documents hardware codec support in AVStream, which helps explain how hardware-based codec functionality can be exposed to user-mode applications. However, I’m not able to officially confirm the exact API path used by FFmpeg in your specific test environment.

Hope this helps clarify your questions.

Thank you.