MKV container support notes outdated + feature request: surface MSE vs native playback distinction

[Indie-Siggi]

Hi NoFear0411,

First off, thanks for maintaining CodecProbe — we're using it as the probe engine in a media server project for device capability detection, and it's been very helpful.

While integrating CodecProbe results into our playback decision engine, we noticed two things — one documentation issue and one feature idea.

---

1. MKV container notes are outdated

In codec-database-v2.js, the MKV notes at lines 474 and 598 say:

"Browser support for video/x-matroska is limited — desktop browsers typically reject the MIME type. Android Chrome may accept it via OS-level MediaCodec."

This was probably accurate a few years ago, but Chrome 90+ (April 2021) and Edge now return 'maybe' for canPlayType('video/x-matroska') on desktop. We've confirmed that Chrome on macOS can play MKV files natively via <video src> with H.264/HEVC video and AAC/Opus audio — no MSE or remuxing needed.

Suggested updated text:

"Chrome 90+ and Edge return 'maybe' for video/x-matroska and can play MKV natively with common codecs (H.264, HEVC + AAC, Opus). Firefox and Safari still do not support MKV. Note: 'maybe' (not 'probably') means the browser recognizes the container but can't guarantee all codec combinations will work."

---

2. Feature idea: make MSE vs native file playback easier to extract

CodecProbe already tests codecs with both type: 'file' and type: 'media-source' and stores the mode field on each container result — this is great. However, for media server integration, it would be very useful to surface this distinction more prominently.

Our use case: A media server needs to decide between direct play (serving the file as-is) and HLS transcoding. Codecs like AC3/EAC3 (Dolby Digital) are a perfect example:

• decodingInfo({ type: 'media-source' }) → not supported (Chrome MSE can't handle AC3/EAC3)
• decodingInfo({ type: 'file' }) → supported on macOS/Windows via platform decoders
• Result: the server unnecessarily transcodes AC3→AAC for HLS when it could just serve the MKV file directly

A possible approach could be adding something like a summary field per codec, e.g.:

{
  "codec": "ac-3",
  "mse_supported": false,
  "native_supported": true,
  "note": "Supported via platform decoder in native playback, not available in MSE"
}

This would make it much easier for media servers to make optimal transcoding decisions without parsing the full per-container results.

---

Side note: Chrome console warnings

When testing codecs like ac-3, ec-3, mp4v.20.8, and dvh1.05.06, Chrome logs "Failed to parse video/audio contentType" warnings to the console. These are browser-internal messages that can't be caught or suppressed. Not a CodecProbe issue at all — just mentioning it in case others report it as a bug. Might be worth a small note in the docs or FAQ.

---

Thanks again for the great tool! Happy to discuss or contribute if any of this would be useful.