Convert M4V to MKV

The registry records H.264, HEVC and AAC as the codecs an M4V carries, and the MKV written here holds H.264 video with AAC audio. For the very common case — an unprotected M4V that is H.264 and AAC — the codecs on both sides of this conversion are identical, and the only thing genuinely changing is the container.

That makes this the pair where the operation and the intention diverge most sharply. What is wanted is a different wrapper. What happens is that every frame is decoded back to pixels and compressed again from scratch, spending minutes of processor time and one generation of quality to produce a file with the same codecs it started with.

MKVToolNix is free, it runs on Windows, macOS and Linux, and `mkvmerge` reads MPEG-4 files — which is what an unprotected M4V is. It lifts the compressed streams out and writes them into a Matroska file without a decoder ever running. The result is bit-identical picture and sound, it takes about as long as copying the file, and it keeps the chapter marks and subtitle tracks that this conversion cannot.

That is worth stating at the top of the page rather than at the bottom of it. If your only problem is that a server, a naming convention or a scraper expects `.mkv`, the remux is the correct tool and this one is not, and selling five minutes of your own CPU for a worse result would be a poor way to run a page.

The first is HEVC. Apple hardware has recorded and exported HEVC by default for years, and a media client that cannot decode it in hardware forces the server to transcode on the fly, which on a small box is the difference between smooth playback and a buffering spinner. Converting to H.264 once, in advance, retires that cost for good — and a remux cannot do it, because a remux by definition does not change the codec.

The second is size. The resolution control offers 2160p down to 360p with the width following automatically, and a 4K file playing on a 1080p television is spending storage and network on detail nobody sees. Asking for more than the source has is ignored on purpose, so the control only ever reduces. Both of these are real reasons; neither of them is "my server wants MKV".

Matroska’s reputation rests on holding everything: any number of audio tracks, embedded subtitle tracks in several formats, chapters, attachments and cover art. Apple-delivered video is one of the few sources that actually arrives with those — a film with a commentary, a series episode with a subtitle track, an audiobook-length recording split into chapters.

None of the chapters or subtitles survive here. The conversion writes picture and sound, and everything that made both containers interesting is left in the M4V. The repair is the same tool as before: build the MKV, then use MKVToolNix to add the subtitle files and a chapter list to the finished file, which it does in seconds without re-encoding anything.

Anything bought or rented from the iTunes Store or the Apple TV app carries FairPlay encryption. The browser has no key, so the tracks cannot be decoded and the conversion stops with a message reporting that nothing in the file could be converted. Nothing on this site removes protection, and neither does mkvmerge.

If a shelf of files converts and a handful refuse, the handful were purchases. The M4V to MP4 page explains how to sort one group from the other by where the files came from, which is quicker than testing them one at a time.

The motivation is usually leaving rather than arriving. A collection built inside iTunes over a decade sits in Apple’s naming, Apple’s metadata and Apple’s extension, and a self-hosted server built on Plex or Jellyfin has its own conventions that assume MKV. Matching the convention makes scrapers, renamers and library tools behave predictably instead of nearly.

It is a filing decision more than a technical one, and it is worth being clear about that, because filing decisions are exactly where a lossless remux beats a re-encode. Nothing about the picture improves by being in a Matroska container. What improves is that the rest of your tooling stops treating the file as an exception.

There is no reliable direction. The quality band is a target the encoder aims at rather than a copy of the source’s bitrate, so a generously encoded M4V converted at the balanced setting usually comes out smaller and slightly worse, while a heavily compressed one converted at the high setting can come out larger without being better.

That asymmetry is the argument for the high band on anything going into a collection you intend to keep. This is already a second generation of compression; making it a lean one saves storage that is cheap and spends quality that cannot be recovered. Use the small band only for files that exist to be watched once on a phone.

Up to a hundred files can be dropped in one pass, each converting independently with its own progress, and the finished MKV files download together as a ZIP. Nothing queues behind anybody else, because there is no shared machine to queue on.

The constraint that bites on this pair is the 100 MB free-tier limit per file. A library of features and episodes is mostly above it, which is another way of saying that a browser is the right tool for clips, segments and short recordings and the wrong one for a thousand-hour collection. For the collection, MKVToolNix in batch mode is the answer and it was always going to be.

Decoding, encoding and muxing all happen inside the browser tab on your own processor. Nothing carrying the video is transmitted, there is no account, and there is no daily count to run out of halfway through an evening’s filing.

For a personal media library that is the arrangement that makes sense. These files are home video, recorded events, purchased material and things ripped from discs somebody owns, and pushing them through an unfamiliar server to change a container would be a great deal of exposure for a rename that a local tool performs for free.