Video Codecs Explained for People Who Just Want It to Play

Somebody sends you an MP4 and it will not open. Somebody else says the file is "the wrong format", so you export another MP4 and it still will not open. Nothing about the extension is going to explain what happened, because the extension is not the part that matters.

A codec is the method used to compress the pictures. A container — MP4, MOV, MKV — is the box that holds the compressed video, the audio and the metadata together. The box is nearly always fine. This guide covers the four codecs you will actually meet, what each is optimised for, why editing codecs and delivery codecs are opposites, and how to choose without guessing.

The Four You Will Meet

The first three are delivery codecs and they sit on one line: as efficiency improves, compatibility and encoding cost get worse. The fourth is a different category entirely, and confusing it with the others is the source of a specific and expensive mistake covered further down.

H.264 Is Still the Safe Answer

H.264 has been the default for long enough that it is decoded in dedicated hardware on essentially anything with a screen — phones, laptops, televisions, set-top boxes, cheap tablets, and browsers on all of them. Hardware decoding matters more than it sounds: it means playback is smooth and does not drain a battery.

Its efficiency is the worst of the three delivery codecs, which in practice means a larger file for the same visual quality. That is a real cost if you are paying for bandwidth at scale and an irrelevant one if you are uploading to a platform that will re-encode your file anyway.

The decision rule is simple. If you do not control what the video will be played on, use H.264. If you are handing a file to a client, posting it publicly, or attaching it to an email, use H.264. Certainty is worth more than the megabytes.

HEVC and AV1: Efficiency With Conditions

HEVC produces noticeably smaller files than H.264 at the same perceived quality, and it handles higher resolutions and wider colour ranges more gracefully. It also has a complicated licensing history, which is why browser support is inconsistent in a way that surprises people who have only tested on their own devices.

AV1 is the most efficient of the three and is royalty-free, which is why the large streaming platforms adopted it. Two things temper that. Encoding is computationally expensive, so a long export can take substantially more time than the equivalent H.264 one. And hardware decoding is present only on relatively recent devices, meaning older hardware falls back to software decoding, which is slow and hot.

There is a subtlety that changes the calculation for most people. If your video is going to a platform that transcodes everything on upload, the codec you deliver in is not the codec anyone watches. What matters there is that your upload carries enough quality for the platform's encoder to work from — which is a bitrate question rather than a codec one, and it is set out in how bitrate, resolution and quality actually relate.

Why Editing Codecs Are the Opposite

Delivery codecs achieve their small sizes largely by not storing most frames completely. A keyframe holds a full picture; the frames after it store only what changed. That is why the files are small, and it is exactly why they are painful to edit.

When you drop the playhead onto an arbitrary frame in an inter-frame file, the software cannot simply read that frame. It has to find the preceding keyframe and reconstruct forward. Do that continuously while scrubbing, on high-resolution footage, and the timeline becomes sluggish regardless of how fast the machine is.

Editing codecs — ProRes, DNxHR and their relatives — store every frame completely. The files are many times larger and every frame is instantly available, which is the whole point. They also survive repeated re-encoding, so a clip that passes through several stages of a workflow does not accumulate visible damage.

The practical consequence is a rule with two halves: transcode difficult source footage to an editing codec on the way in, and never deliver in one on the way out. A ProRes file sent to a client is a file most of them cannot open, and the ones who can will find it is twenty times larger than it needed to be.

Two Settings That Matter More Than the Codec Name

Bit depth. Most consumer footage is 8-bit, which gives 256 levels per colour channel. That is enough for viewing and thin for grading — push it hard and smooth gradients break into visible bands. Footage captured at 10-bit has substantially more room to be pushed, which is why it matters for anything that will be graded rather than simply corrected. The consequences for the grading pass itself are in colour correction versus grading.

Chroma subsampling. Almost all delivery video is 4:2:0, meaning colour is stored at a quarter of the resolution of brightness. Human vision tolerates that well for ordinary footage and badly for two specific cases: fine coloured text, and green-screen edges. If you are keying or delivering screen recordings with coloured type, 4:2:2 is worth the file size.

Both of these are decided at capture and cannot be recovered afterwards. No export setting adds information that was never recorded.

Frame Rate Rides Along With the Codec

One thing that gets bundled into a codec conversation and does not belong to the codec at all is frame rate. An export preset carries it, so changing codec by changing preset silently changes the rate as well, and the result is footage that plays at the right speed and moves wrong.

The rule is that the export should carry the rate the project was finished at. Where a preset disagrees, the preset is wrong. This matters most on material that mixes sources, because a conversion that was handled correctly in the timeline can be undone by an export that conforms everything again — the failure modes are set out in what happens when frame rates are mixed.

There is a related interaction with compression. Every frame per second is another picture the encoder has to describe within the same allowance, so doubling the rate roughly halves what each frame gets. On content without much movement, that is a straight loss: the same bitrate at half the rate would have produced visibly better frames.

Choosing Without Guessing

Storage is the constraint that decides how much of this you can actually do, and the arithmetic is worth running before a project starts rather than when a drive fills — planning storage for video projects covers the per-minute figures.

Next Steps

Take a file you were sent that would not play and check what codec is actually inside it, using your editor's clip properties or any media inspector. In nearly every case the answer is HEVC in an MP4, and the fix is a re-export rather than a different extension.

Then pick your two defaults and write them down: one delivery codec for anything public, one editing codec for anything that scrubs badly. Deciding this once removes the question from every future project. The per-destination settings that sit on top of it are in export settings for each major platform, with the rest under formats, specs and delivery.