Open HEVC Video
Back to home

HEVC Compatibility: Browser, Container, Audio, and MVP Limits

The current compatibility boundary for OpenHEVCVideo, including browser targets, preferred containers, and non-guaranteed formats.

Last updated: 2026-07-24

Why this page exists

Compatibility pages are useful only when they are explicit about what is supported today and what is still outside the guaranteed path. This page describes the current MVP boundary for OpenHEVCVideo.

Browser target

The MVP target is Windows on Chrome and Edge first. Other platforms and browsers may work for some files, but they are not the primary compatibility promise for the first release.

Preferred file shapes for MVP

The practical target is:

  • MP4 or MOV containers,
  • HEVC Main or Main10 SDR video,
  • local file playback through the homepage tool.

These combinations are the clearest fit for native probe plus compatibility fallback behavior.

Audio expectations

Audio must be treated separately from video.

  • AAC may work, but the result should still be confirmed by actual file probe.
  • Opus may work in some cases, but it should also be treated as probe-dependent.
  • AC-3 and E-AC-3 are not guaranteed in the MVP.

If a video plays without sound, that does not automatically mean the HEVC video track failed. The issue may be limited to the audio stream.

Formats and workflows that are not guaranteed

The MVP should not promise:

  • 4K playback on all devices,
  • HDR correctness,
  • DRM playback,
  • every MKV workflow,
  • every raw .hevc or .h265 stream,
  • every frame rate or chroma layout,
  • every hardware-acceleration path.

These cases may work for some users, but they must remain outside the guaranteed support statement until verified by dedicated fixtures and browser testing.

Native playback versus compatibility mode

Two users can open the same nominal format and still land on different paths:

  • one may get browser-native playback,
  • another may fall back to compatibility mode,
  • a third may fail because of memory limits, audio, or metadata.

That is why the product should surface the observed playback path rather than relying on a static support table alone.

How to interpret support claims

OpenHEVCVideo support claims should be read in this order:

  1. Can the actual file be opened natively in the current browser?
  2. If not, can the local compatibility path decode and present it?
  3. If not, is the blocker the container, audio codec, profile, resolution, HDR, DRM, or memory budget?

Related pages

To test the current behavior directly, return to the homepage.