The box and the codec are two different decisions

The box and the thing inside it

A video file is two separate decisions wearing one filename.

The codec is how the pictures and the sound were compressed: H.264, H.265, AV1, VP9, ProRes, DNxHR for picture; AAC, PCM, Opus, MP3 for sound. The container is the box that holds those compressed streams side by side, along with the timecode, the track names, the subtitle tracks and the metadata: MP4, MOV, MKV, MXF, WebM.

holiday.mp4 tells you the box. It tells you nothing about what is inside, which is why "it's an MP4" is not an answer to "what codec is it?" and why one MP4 plays on a phone and another does not.

The confusion is worth clearing up now, because almost every delivery problem in this block is really a container-and-codec problem wearing a different hat.

What each box is for

MP4 is the ISO standard box. It is the safest thing to hand anybody. Browsers play it, phones play it, every platform accepts it. It legally holds H.264, H.265 and AAC, and that is most of what it is used for.

MOV is Apple's QuickTime box, and structurally it is MP4's older sibling — the two share a file format lineage, which is why so many tools treat them interchangeably. MOV is where ProRes lives, and it holds timecode tracks more comfortably than MP4.

MKV (Matroska) is the open box that holds anything: any codec, unlimited subtitle and audio tracks, chapters. It is excellent for archiving and for anything you will watch yourself. Upload one to a client's review system and it may well be rejected, because MKV support outside VLC and media players is patchy.

MXF is the broadcast box. If a spec sheet asks for MXF OP1a, that is a delivery requirement from a system that is older and stricter than you are, and you follow it exactly.

WebM is the browser box for VP9 and AV1. You will mostly meet it as a download from a website rather than as something you make.

Renaming does nothing

The single most common misunderstanding: changing .mkv to .mp4 in Finder or Explorer does not convert anything. The bytes are unchanged. You have put an MP4 label on a Matroska box, and the player either sees through the lie and works, or refuses.

What you actually want is a remux: unpack the streams from one box and repack them into another without touching the compression.

ffmpeg -i clip.mkv -c copy clip.mp4

-c copy means "copy the streams, do not re-encode". A two-gigabyte file remuxes in a couple of seconds and loses nothing, because nothing was decoded. Compare that with a re-encode, which takes minutes and always loses a little.

The catch is legality. Not every codec is allowed in every container. H.264 and AAC go into MP4 happily. ProRes in MP4 is not a standard combination and many players will refuse it. FLAC in MP4 is unusual. If a remux fails, ffmpeg will normally say which stream it could not place, and the fix is to re-encode that one stream and copy the rest:

ffmpeg -i clip.mkv -c:v copy -c:a aac -b:a 192k clip.mp4

Picture copied untouched, audio converted. This is the cheapest repair in the whole delivery chain.

The one MP4 flag worth knowing

An MP4 has an index — the moov atom — that says where every frame lives. Encoders often write it at the end of the file, because they only know the final layout once they finish.

A file with the index at the end cannot start playing until it has fully downloaded. Uploaded to a web page, it appears broken: a long spinner, then it plays. The fix takes seconds and no quality loss:

ffmpeg -i in.mp4 -c copy -movflags +faststart out.mp4

Most editors have a "web optimised" or "fast start" checkbox that does exactly this. Tick it for anything going on a website. It does not matter for YouTube or Instagram, which re-encode the file anyway.

Why a colleague cannot open your ProRes

ProRes is a Apple codec, and macOS decodes it everywhere by default. On Windows the situation is better than it used to be and still not universal: recent Windows versions decode ProRes in some applications, VLC and DaVinci Resolve read it regardless, and a random corporate media player may not.

DNxHR is Avid's equivalent and behaves symmetrically — solid everywhere in professional tools, less certain in consumer ones. Both are intra-frame codecs, meaning every frame is compressed on its own, which is why they scrub instantly and why the files are enormous.

If you do not know what the other end can open, send H.264 in MP4. It is the format nobody has trouble with.

Honest limits

Container and codec support is not a fixed fact you can memorise once. It shifts with operating system versions, browser versions and hardware. AV1 decoding, for instance, is hardware-accelerated on recent phones and chips and software-only on older ones, where a 4K AV1 file will stutter on a machine that plays 4K H.264 without effort.

The working habit is not to know the compatibility matrix. It is to check the file before you send it, with ffprobe or MediaInfo — both free — and to ask the receiving end what they open things in.

Today

Take any file on your drive and run ffprobe -hide_banner file.mp4. Read the two lines that say Stream #0:0 and Stream #0:1. You now know its codec, its resolution, its frame rate and its audio format, which is more than the filename ever told you.