Matroska Video
MKV and WebM share their first four bytes — only 'matroska' or 'webm' inside the header tells them apart. iPhones and Apple TVs refuse MKV, which is why 'MKV to MP4' is the most common MKV search. FileDex converts in your browser — seconds when codecs match, minutes when they don't.
أسئلة شائعة
How do I convert MKV to MP4?
FileDex converts MKV to MP4 directly in your browser — drop your file into the converter above. When your MKV's video and audio codecs are already MP4-compatible (usually H.264 and AAC), the conversion is a stream copy that finishes in seconds with no quality loss. Otherwise FileDex transcodes to H.264 plus AAC automatically.
What is an MKV file?
MKV — short for Matroska Video — is an open container format that can hold video, audio, subtitles, chapters, and even embedded fonts in one file. It shares its first four bytes with WebM; a short word ('matroska') inside the header distinguishes them. Matroska became an IETF standard — RFC 9559 — in October 2024.
Why won't my iPhone play MKV files?
iOS Safari, Apple TV, and most Chromecast scenarios refuse MKV containers regardless of what's inside — Apple and Google built their mobile video pipelines around MP4 with H.264 or HEVC plus AAC, not around Matroska. VLC for iOS works as a workaround. The permanent fix is converting to MP4 — drop your file into the FileDex converter above.
What's the difference between MKV and MP4?
MP4 plays everywhere — iPhone, Apple TV, smart TVs, every browser. MKV plays on desktop media players like VLC, mpv, and Kodi, and refuses to play almost anywhere mobile. The trade-off: MKV can hold multiple audio and subtitle tracks plus embedded fonts in one file. MP4 is the target for cross-device playback.
How do I extract audio from an MKV file?
Drop your MKV into the FileDex converter above and pick an audio target — MP3, AAC, WAV, or FLAC. When the MKV's audio track is already in a format you want (often AAC), FileDex does a stream copy that extracts the encoded audio without any re-encoding, preserving the exact original bytes.
ما يميز .MKV
Open an MKV and a WebM file side by side in a hex editor. The first four bytes are identical: 1A 45 DF A3. Scroll forward about twenty bytes. That is where they start to disagree — the MKV spells matroska in eight ASCII letters; the WebM spells webm in four. That string is the only thing telling a file-detection tool which format it is reading.
اكتشف التفاصيل التقنية
The identical four bytes aren't random. They are the EBML Header element ID, specified in RFC 8794 (August 2020). EBML — Extensible Binary Meta Language — is a binary version of XML; Matroska is one format built on it, WebM is another, and anything else using EBML's framework would share the same signature. FFmpeg handles both with the same piece of code: ffprobe on an MKV reports its format_name as matroska,webm, and the same string comes back for a WebM. Inside that one demuxer, the code branches on the DocType string — one path for Matroska's full codec range, another for WebM's allowlist. The bytes-on-disk framework is the same; the policy is in a UTF-8 value.
Only Matroska actually uses the freedom EBML offers
Run mkvmerge -i on a typical anime release and the terminal scrolls tracks you didn't know were in a video file: one HEVC video at 1080p, Japanese audio in 5.1 FLAC, a stereo English dub, a director's commentary track, then — one by one — subtitle tracks for Japanese, English, Korean, Chinese, French, German, Spanish, Portuguese. Often a dozen of them. Then the Attachments list: SourceHanSans.otf, KaoriGothic.ttf, Meiryo.ttf. Finally forty-seven chapter markers with translated episode titles.
MP4 can technically hold some of that, but MP4 authoring tools don't. FFmpeg's MP4 muxer defaults to one video and one audio, subtitles burned in. MKVToolNix defaults to preserving every track separately and embedding the fonts your subtitle renderer will need when someone plays the file on a computer without Japanese typefaces installed. RFC 9559 §20 formally specifies the Attachment element; §27 registers over thirty codec IDs the container can carry. That flexibility is the product decision you can feel the moment a file drops into VLC and suddenly offers a menu of audio and subtitle tracks.
Twenty-two years from community spec to IETF standard
This flexibility existed for twenty-two years before the IETF finished ratifying it. Matroska started as a community project on December 6, 2002 — PRONOM's registered release date — and lived on matroska.org as an open but unofficial specification. The IETF CELLAR Working Group began the formal standardization process in the mid-2010s, progressing through drafts as draft-ietf-cellar-matroska over most of the decade. EBML — the foundation layer — got its own RFC (8794) in August 2020. Matroska itself became RFC 9559 in October 2024, authored by Steve Lhomme, Moritz Bunkus, and Dave Rice.
The twenty-two-year gap looks embarrassing from a standards-process angle, but everything visible from user space ran on the community spec fine. Every major open-source desktop media player spoke Matroska fluently by 2010; anime fansub distribution at scale was a Matroska phenomenon from roughly 2005 onward; Plex and Kodi were built against the community spec, not the RFC. When the IETF finally shipped RFC 9559 it was ratifying reality, not creating it.
Why 'MKV to MP4' is the #1 MKV search query on Google
The fluent-speaker list has always been a desktop list. Try to AirDrop an MKV from a MacBook to an iPhone — the file lands, Files app shows it, and tapping produces a 'The file format is not supported' dialog. iOS Safari won't play MKV either. tvOS refuses. Most smart TVs accept the container but fail on specific codec combinations like DTS audio or HEVC video. Chromecast is codec-conditional. Chromium desktop works for some combinations and not others. This is why 'convert MKV to MP4' is the single highest-volume MKV-related query on Google — the cliff is the user's actual problem, not the format.
A whole category of software exists to bridge that cliff. Plex, Jellyfin, and Infuse sit between a household's MKV catalog (typically on a NAS or a desktop) and the Apple TVs, Chromecasts, or phones elsewhere in the house. Their core job is live transcoding: read the MKV, decide what the target device can play, and deliver an HLS stream of MP4 chunks when the codec or container isn't directly supported. The user mostly doesn't notice — they open an app and watch a video. A whole category of home-media software exists downstream of this mobile-refusal pattern.
The conversion itself is sometimes instant and sometimes slow. When an MKV's codecs are already MP4-compatible — typically H.264 video plus AAC audio — a stream copy rewrites the container without touching a single video or audio byte. Locally, on a laptop, a three-second test file converts at 865 times realtime speed; a two-hour movie finishes in seconds. When codecs aren't compatible — MKV carrying HEVC video plus FLAC audio, for instance — the same command falls back to a re-encode and takes minutes to hours. FileDex runs the same branching logic in WebAssembly: stream copy when it works, transcode when it doesn't, all inside the browser tab.
حوّل .MKV إلى...
المرجع التقني
- نوع MIME
video/x-matroska- Magic Bytes
1A 45 DF A3EBML header signature shared with WebM.- المطوّر
- Matroska.org
- سنة التقديم
- 2002
- معيار مفتوح
- نعم — عرض المواصفات
EBML header signature shared with WebM.
البنية الثنائية
MKV files are built on EBML — Extensible Binary Meta Language, a binary derivative of XML defined by RFC 8794. Every MKV file begins with the same four bytes (`1A 45 DF A3`) — the EBML Header element ID. That header contains child elements (EBMLVersion, EBMLReadVersion, EBMLMaxIDLength, EBMLMaxSizeLength, DocType, DocTypeVersion, DocTypeReadVersion) encoded as VINT-sized type-length-value triples. The DocType element carries the UTF-8 string `matroska` in an MKV, `webm` in a WebM — that string is the only byte-level disambiguator between the two formats. Following the EBML Header, the Segment element (`18 53 80 67`) contains the actual media: Info, Tracks, Cluster (encoded media data), Cues (seek index), Chapters, Attachments (fonts, cover art), and Tags. RFC 9559 §4 defines the Segment structure; §20 specifies Attachments; §27 registers more than thirty codec IDs the container can carry.
| Offset | Length | Field | Example | Description |
|---|---|---|---|---|
0x00 | 4 bytes | EBML Header ID | 1A 45 DF A3 | EBML Header element ID per RFC 8794 §11.2.1. Identical in ALL EBML-derived formats (Matroska, WebM). |
0x04 | 1 byte | EBML Header size (VINT) | A3 | VINT-encoded length of the EBML Header element payload. 0xA3 decodes to 0x23 (35 bytes follow). |
0x05 | 4 bytes | EBMLVersion element | 42 86 81 01 | Element ID (42 86) + size (81 = 1 byte) + value (01). EBMLVersion = 1. |
0x15 | 3 bytes | DocType element header | 42 82 88 | DocType element ID (42 82) + VINT size (88 = 8 bytes follow). The DocType value is the format disambiguator. |
0x18 | 8 bytes | DocType value | 6D 61 74 72 6F 73 6B 61 | UTF-8 ASCII string 'matroska'. In a WebM file, this slot holds 'webm' (4 bytes). The only byte-level difference between MKV and WebM starts here. |
0x20 | 4 bytes | DocTypeVersion | 42 87 81 04 | DocTypeVersion element. Value 04 = Matroska v4 per RFC 9559. |
0x24 | 4 bytes | DocTypeReadVersion | 42 85 81 02 | DocTypeReadVersion element. Value 02 = minimum reader version required for backward compatibility. |
نقاط الضعف
- Crafted EBML VINT-decoded element sizes in the Matroska demuxer have triggered heap corruption in native FFmpeg libavformat (CVE-2016-10190 integer overflow, CVE-2017-17081 out-of-bounds write, CVE-2021-38171 NULL-pointer dereference).
- libmatroska and libebml — the C++ reference implementations bundled by MKVToolNix and downstream tools — have carried their own CVE history including integer-underflow bugs (CVE-2018-12930 and related).
- MKV's multi-subtitle-track model amplifies exposure to ASS/SSA renderer CVEs. Check Point's 2017 'Hacked In Translation' demonstrated remote code execution via crafted subtitles across VLC, Kodi, and PopcornTime.
- MKV's Attachment elements (intended for fonts and cover art) could carry a malicious executable disguised as a font. Players do not auto-execute; risk requires user to extract then run.
الحماية: FileDex decodes MKV via FFmpeg compiled to WebAssembly inside the browser sandbox. Subtitles are not rendered during convert or extract — libass is never invoked, cutting off the largest historical MKV attack surface. Attachment payloads appear as metadata but are never extracted. A malformed demuxer crashes the worker, contained to the browser tab. No file uploads.