Convert MKV to MP4 on Mac (and What You Lose)

Tested on a 143,328-byte MKV built for the purpose: H.264 video, one AAC track named “Stereo mix”, two SubRip subtitle tracks (English and German, both named), and three chapters.

Two rows in there contradict what most pages on this subject claim. Chapters do survive — all three came back with their titles intact through every route we tried. Track names do not, which is the loss nobody mentions: if your MKV had “English (forced)” and “English (full)”, the MP4 has two tracks both labelled eng and you get to guess.

Three commands, three different outcomes. Only the third is the one you want.

1. The command everyone posts. Exit code 0, no warning, 150,075 bytes out:

ffmpeg -i input.mkv -c copy output.mp4

Read its own stream mapping and the problem is visible. It printed Stream #0:0 -> #0:0 (copy) and Stream #0:1 -> #0:1 (copy), and then subtitle:0KiB. Streams 2 and 3 were never mapped. ffmpeg’s default selection picks one video and one audio track and discards the rest, which is a reasonable default and a terrible surprise.

2. Mapping everything. This fails outright, which is at least honest:

$ ffmpeg -i input.mkv -map 0 -c copy output.mp4
[mp4 @ 0x…] Could not find tag for codec subrip in stream #2,
            codec not currently supported in container
[out#0/mp4 @ 0x…] Could not write header (incorrect codec parameters ?):
            Invalid argument

MP4 cannot store SubRip. It has its own timed-text format, tx3g, which ffmpeg calls mov_text.

3. The command that works. Map everything, copy the audio and video, convert only the subtitles:

ffmpeg -i input.mkv -map 0 -c copy -c:s mov_text output.mp4

That took 0.06 seconds, produced 151,402 bytes, and kept both subtitle tracks with their language tags and all three chapters. The video and audio were never decoded.

SubRip converts cleanly because it is plain text with timings. ASS and SSA do not. An ASS track carries a Style: header defining font, size, colour and screen position; ours read Style: Default,Arial,16,&Hffffff,&Hffffff,&H0,&H0,0,0,0,0,100,100,…. Copying it into MP4 failed the same way SubRip did — Could not find tag for codec ass in stream #2 — and converting it to mov_text succeeded but threw the styling away. Extracting the result gave back bare text with the timings nudged from 00:00:00,500 to 00:00:00,523, quantised to the nearest frame.

Bitmap subtitles are worse, and this is where honesty beats a workaround. PGS tracks from Blu-ray and VobSub from DVD are pictures of words, not words. ffmpeg will not turn them into text; ask it to cross that line and it says so:

Subtitle encoding currently only possible from text to text
or bitmap to bitmap

There is no -c:s mov_text route for a PGS track. Your options are to keep the MKV, to burn the subtitles permanently into the picture (which does require a full re-encode and is irreversible), or to run OCR over them with a tool such as Subtitle Edit and accept the error rate. None of those is a conversion.

This is the failure mode that costs people an evening, because the conversion reports success. We put a DTS track in an MKV and copied it into MP4. ffmpeg exited 0 and wrote a 1,436,791-byte file. Then macOS looked at it:

$ avmediainfo dts.mp4
Error in Track ID 2 'soun' Error when generating format descriptions.
  Found stream descriptor for unsupported MPEG-4 object type 0xA9.
Error in Track ID 2 'soun' Omitting a track that encountered an error
  during atom parsing.
Movie analyzed with 2 errors.

The file plays. It has no sound. ffmpeg wrote a legal MP4 that AVFoundation refuses to decode, so QuickTime Player, Photos and Final Cut all see a silent video. If a converted file is mysteriously mute, this is why.

TrueHD at least stops you:

truehd in MP4 support is experimental, add '-strict -2' if you want to use it.

One widely repeated claim is simply out of date. MP4 can hold FLAC. Our 434,826-byte FLAC-in-MKV copied straight through to a 439,082-byte MP4, tagged fLaC, and avmediainfo reported “System support for decoding this track: Yes” with zero errors on macOS 27. If a page tells you to re-encode FLAC to AAC purely to satisfy the container, it is working from a decade-old rule.

For DTS or TrueHD the fix is to re-encode that one stream and leave the video alone: -c:v copy -c:a aac -b:a 192k. The picture stays byte-identical.

Fewer things than the internet suggests, but the ones that remain are the ones people care about.

• Attachments. Matroska can embed arbitrary files, which is how a fansub release ships the exact fonts its ASS subtitles need. MP4 has no equivalent box. Mapping one across failed with Could not find tag for codec none in stream #2, and the default command dropped it without a word.
• Per-track names. “Director’s commentary”, “Forced”, “SDH” — all gone. You keep the three-letter language code and nothing else.
• Styled and bitmap subtitles. Covered above. This is the single biggest reason to leave a rip alone.
• Any codec at all. Matroska is codec-agnostic by design. MP4 has a registry, and anything not in it either fails loudly or, as with DTS, fails quietly on playback.

What is not on that list, despite being repeated everywhere: chapters and multiple subtitle tracks. MP4 handles both. Our output carried two tx3g tracks and three named chapters.

Often, no. If the only problem is that QuickTime Player will not open it, install IINA or VLC. Both are free, both play MKV natively with every subtitle track and every chapter intact, and neither asks you to give anything up. Converting to satisfy a player is throwing away tracks to work around a fifteen-megabyte download.

Convert when the destination genuinely cannot read MKV:

• An upload form, a web player, or a CMS that rejects the extension.
• Photos, iMovie or Final Cut, none of which import MKV.
• A TV, console or older iOS device with a fixed container list.
• AirPlay to an Apple TV.

And keep the original until the MP4 has been checked. A remux costs a second; recovering a deleted subtitle track costs the whole download again.

For any MKV with subtitle tracks you care about. Smol’s video conversion path always re-encodes and it drops subtitle tracks, exactly as ffmpeg’s default mapping does. On our test file it produced 139,478 bytes from 143,328 in 1,985 ms, kept all three chapters and the file title, and left both subtitle tracks behind. If those tracks matter, -map 0 -c copy -c:s mov_text is the correct tool and it is free.

Where an app is the better call is the case ffmpeg handles badly: a folder of forty mixed files, some MKV, some MOV, some already MP4, that all need to come out as one consistent format. One drop, one setting, no per-file codec triage, and a Finder Quick Action so it happens on right-click. Video output is limited to mp4, mov, webm and mkv — Smol reads AVI but cannot write it — and it is $29 once.

If the goal is a smaller file rather than a different container, that is a separate job: four Mac compression routes, measured, and the MOV case where a rewrap really is all you need.

MacBook Pro (Mac14,9), Apple M2 Pro, 10 cores, 16 GB, macOS 26A428. ffmpeg and ffprobe 8.1.1 from Homebrew, Smol 1.0.34. avmediainfo ships with macOS at /usr/bin/avmediainfo and reads files through AVFoundation, which is why it is a fair proxy for “will QuickTime play this”.

Every fixture was generated on the machine: an 8-second 1280×720 H.264 clip from ffmpeg’s lavfi sources, two hand-written SRT files, a hand-written ffmetadata chapter file, and a plain text file used as the MKV attachment. Nothing was downloaded and no ripped media was involved. The DTS, TrueHD and FLAC variants were made by re-encoding that clip’s audio track. Everything was deleted after measurement.