Containers vs Codecs: Why Your Video Won’t Play

MP4, MOV, MKV, WebM — the file extension describes the box, not the video inside. Understanding the difference explains almost every playback problem.

The single most useful thing to understand about video

Almost every confusing video problem — the file that plays on your laptop but not your phone, the MP4 your editor refuses to import, the conversion that finishes in two seconds and the one that takes twenty minutes — comes down to one distinction. A video file has two separate identities: the container and the codec. The file extension only tells you about the first one.

The container is the box. MP4, MOV, MKV, and WebM are containers, and their job is organisational: interleaving video and audio so they stay in sync, storing an index so a player can seek to the middle without reading everything before it, and holding metadata like duration, chapters, and subtitles. The container knows almost nothing about the pictures themselves.

The codec is what actually compresses the video. H.264, HEVC, VP9, AV1, ProRes — these are the algorithms that turn a sequence of images into a manageable number of bytes, and they are the ones that determine whether a given device can play your file. A device that lacks an HEVC decoder cannot play HEVC video, no matter what the file is called or which container it arrives in.

Why the same extension can behave completely differently

Two files can both be MP4s and have nothing meaningful in common. One might contain H.264 video with AAC audio — the combination every device made in the last fifteen years can play. The other might contain HEVC video, which will play on a recent iPhone and fail on a smart TV from 2016, despite both files ending in .mp4 and looking identical in a file listing.

This is why "just convert it to MP4" sometimes fixes the problem instantly and sometimes accomplishes nothing at all. If the video will not play because the container is unfamiliar — an MKV on a TV, a MOV on an upload form — then moving the same streams into an MP4 box genuinely solves it. If the video will not play because the device cannot decode HEVC, rewrapping that same HEVC stream into an MP4 changes the filename and nothing else.

The reverse trips people up too. A file that will not open in your video editor is often perfectly playable in VLC, because VLC bundles decoders for nearly everything while editors support a deliberately narrow list. The video is fine; the software is picky.

Rewrapping versus re-encoding

Because the container and the compressed streams are independent, there are two fundamentally different operations that both get called "converting". Understanding which one you are doing explains the wildly different times and outcomes you will see.

Rewrapping — also called remuxing — reads the compressed video and audio streams out of one container and writes them into another without touching them. Nothing is decoded, nothing is recompressed, and the resulting video is bit-for-bit identical to the source. It takes seconds even for a large file, because the work is essentially copying bytes and building a new index. This is what happens when you convert a MOV holding H.264 into an MP4: the streams were already exactly what MP4 wants.

Re-encoding decodes every frame back to pixels and compresses them again with a different codec. It takes real time, proportional to the length and resolution of the video, and it costs a generation of quality because lossy compression is being applied to material that has already been through it once. This is unavoidable when the codecs do not line up — converting VP9 in a WebM to an MP4, or any ProRes source to a delivery format.

A good converter tells you which one it did. Convertmaxxing takes the rewrap path whenever the source codec fits the target container and labels the result, so a conversion that finishes suspiciously fast is not a bug — it is the best possible outcome.

A field guide to the four containers you will actually meet

MP4 is the universal delivery container. It plays essentially everywhere, streams well, and is what upload forms expect. It is comparatively strict about what it will carry, which is precisely why it is so reliable. If you are sending a video to someone whose device you do not control, this is the answer.

MOV is Apple’s QuickTime container, and MP4 was built directly on its architecture — they are close cousins that typically carry identical codecs. Every iPhone recording and Final Cut export starts here. Because of that shared ancestry, MOV to MP4 is usually a pure rewrap. The only real difference is that the world recognises the .mp4 extension and often refuses .mov.

MKV, or Matroska, is the maximalist option: it will hold almost any codec, multiple audio tracks, soft subtitles, and chapters. This makes it excellent for archiving and for crash-resilient recording, which is why OBS defaults to it. It also makes it nearly unplayable on phones, TVs, and consoles, so the standard workflow is to record MKV and rewrap to MP4 afterwards.

WebM is the open web container, holding only royalty-free codecs — VP8, VP9, and AV1. Every browser plays it and compresses well, but iPhones, TVs, and consoles largely do not. Because its codecs never overlap with MP4’s, conversion in either direction always requires a full re-encode.

Diagnosing a video that will not play

Start by finding out what is actually inside the file rather than guessing from the extension. VLC will tell you under Tools → Codec Information, and most operating systems expose some of it in file properties. You are looking for two things: the container format and the video codec.

If the codec is H.264 and something still refuses the file, the container is the likely culprit — rewrapping to MP4 will probably fix it in seconds without touching quality. If the codec is HEVC, VP9, AV1, or ProRes and the target device is older or non-technical, you need a genuine re-encode to H.264, which is slower and costs a little quality but produces something that plays essentially anywhere.