# FFmpeg yuv420p vs yuv444p

Canonical: https://rendobar.com/blog/yuv420p-chroma-subsampling-cost/
Author: Abdelrahman Essawy
Published: 2026-08-20
Updated: 2026-08-20

---

## Key takeaways

- yuv420p was both the smallest at 433 KB and the fastest at 899 ms. It wins on every axis measured, before compatibility is even considered.
- yuv444p cost 65% more encode time (1,487 ms) for 5% more bytes, and is unplayable on a lot of hardware decoders.
- yuv422p produced MORE bytes than yuv444p, 475 KB against 457 KB, which is not the ordering anyone expects.
- 10-bit yuv420p10le cost 40% more time and 8% more bytes, and breaks the same hardware decoders 444 does.
- Missing format=yuv420p is the single most common cause of a video that plays in Chrome and not in Safari or QuickTime.

If a video plays everywhere except Safari and QuickTime, this is almost always
why. The fix is one filter, and it turns out to be the cheap option too.

Short version. **yuv420p was the smallest AND the fastest** of the four formats
measured. The higher-chroma formats cost real encode time, produce more bytes,
and are rejected by a large amount of hardware. There is no tradeoff to weigh
for delivery: 420 wins outright.

## 420 wins on every axis

| Format | Encode | Size |
|---|---:|---:|
| yuv420p | **899 ms** | **433 KB** |
| yuv422p | 1,152 ms | 475 KB |
| yuv420p10le | 1,257 ms | 468 KB |
| yuv444p | 1,487 ms | 457 KB |

yuv444p costs **65% more encode time** than 420 and produces **5% more bytes**.
For delivery that is a straight loss. There is no column where it wins.

The reason is what subsampling does. `yuv420p` stores full-resolution luma and
quarter-resolution chroma, on the basis that human vision is far more sensitive
to brightness detail than colour detail. `yuv444p` stores chroma at full
resolution, so there is more data to encode and more work to do it.

## 422 produced more bytes than 444

**475 KB** against **457 KB**. The format with *less* chroma data made the
*larger* file.

That looks wrong and it is worth not hand-waving. The most likely cause is that
x264's rate control and its available prediction modes differ per pixel format,
and 444 has encoder paths that 422 does not, so at a fixed CRF the two are not
walking the same curve. Chroma data volume is one input to output size, not a
proxy for it.

The practical reading: **do not reason about output size from subsampling
arithmetic.** Measure it, because the ordering is not what the theory predicts.

## The compatibility argument is the decisive one

Even setting the numbers aside, 420 is what plays.

Safari, QuickTime, most smart TVs, most set-top boxes and most phone hardware
decoders handle H.264 High profile at yuv420p 8-bit and refuse a lot of what sits
above it. 444 and 10-bit are studio and intermediate formats. They exist for
grading and mastering, not for the last mile.

That is why the symptom is so specific: the file plays in Chrome on a desktop,
which decodes in software and is permissive, and fails on the device the user
actually has.

## When your chain silently changes format

The trap is that you often do not choose 444. A filter chooses it for you.

Several filters output higher-chroma or RGB formats, and if nothing converts
back before the encoder, that is what gets encoded. Overlaying a transparent PNG,
using some colour filters, or feeding RGB frames in are all common paths to an
accidental 444 output.

Which is why the recommendation is to end delivery chains with it explicitly:

```
-vf "...your filters...,format=yuv420p"
```

It costs nothing when the format is already 420, and it prevents the bug when
something upstream changed it. Put it last in the chain, after every filter that
might have altered the format.

## Where this stops

One 5-second 1280x720 clip, libx264 at CRF 23 preset medium, audio stripped. The
422-versus-444 inversion is the kind of result that could move with content or
with an x264 version, so treat that specific ordering as one data point rather
than a rule.

The parts that will not move: 420 is the fastest, 420 is what hardware decodes,
and the higher formats are not buying you anything on a delivery path.

Pixel format is one of seven settings measured on this same source. The rest are in [FFmpeg encoding settings compared](/blog/ffmpeg-encoding-settings/).