FFmpeg yuv420p vs yuv444p

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.

Variant	Encode	Size	Cost
yuv420p	899 ms fastest	433.0 KB	$0.0024
yuv422p	1152 ms	475.0 KB	$0.0026
yuv444p	1487 ms	456.7 KB	$0.0031
yuv420p10le	1257 ms	467.9 KB	$0.0029

Measured 2026-08-20 on the Rendobar API. Encode time is the FFmpeg step alone, separated from download and upload. 4 of 4 runs succeeded. Sizes are exact and repeatable. Timings are a single sample and vary up to 2x run to run, so treat small differences as noise. Why.

420 wins on every axis#

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.