Quality target or size target

Two different questions, two different controls

“How big should this file be?” and “how good should this look?” are different questions, and encoders have separate modes for them. Choosing the wrong mode is the most common cause of a file that is either enormous or unnecessarily ugly.

Constant quality (CRF, or constant rate factor). You state a quality target and the encoder spends whatever bits that takes: more on the complicated shots, fewer on the simple ones. The output size is not known in advance.

Target bitrate (ABR, VBR, two-pass). You state a size or a rate and the encoder hits it, distributing the bits as well as it can. Quality varies with the content.

Constant bitrate (CBR). Every second uses the same number of bits, whatever is happening. Wasteful on easy content, poor on hard content, and required for broadcast transport streams and some live-streaming ingests because the downstream system has a fixed pipe.

CRF, which is what you usually want

ffmpeg -i in.mov -c:v libx264 -crf 20 -preset slow -c:a aac -b:a 192k out.mp4

The scale for x264 and x265 runs 0 to 51, lower being better. The numbers worth knowing:

• CRF 18: visually near-transparent for most content. Large files.
• CRF 20 to 23: the practical range for good delivery. 23 is x264’s default.
• CRF 26 to 28: visibly soft on detail and motion; acceptable for small previews.

A change of about 6 in CRF roughly halves or doubles the bitrate. CRF 26 is about a quarter the size of CRF 20 on the same source. That relationship is the useful one to carry around, because it lets you estimate without trial encodes.

x265 and AV1 use the same scale with different meanings. x265’s CRF 28 is approximately x264’s CRF 23 in quality, and produces a smaller file. Do not carry a number between encoders.

The preset is not quality

-preset veryslow   # slowest, most efficient
-preset slow
-preset medium     # default
-preset veryfast
-preset ultrafast  # fastest, least efficient

With CRF fixed, the preset does not change the target quality: it changes how much search effort the encoder spends finding a cheap way to reach it. A slower preset at the same CRF produces a smaller file of the same quality. Going from medium to slow typically saves 5 to 10 per cent of the size for roughly double the encode time; veryslow saves a little more for a lot more time.

The practical rule: use the slowest preset you can tolerate for anything that will be downloaded many times, and veryfast for a preview you are going to look at once.

When you need a size

Two-pass, which is what “fit this into 8MB” means:

# target bitrate = (target size in bits) / duration, minus audio
ffmpeg -y -i in.mov -c:v libx264 -b:v 1400k -pass 1 -an -f mp4 /dev/null
ffmpeg    -i in.mov -c:v libx264 -b:v 1400k -pass 2 -c:a aac -b:a 128k out.mp4

The first pass analyses the whole file and writes a log of how complex each part is. The second pass uses it to distribute the bits. This is meaningfully better than a single-pass attempt at the same bitrate, because the encoder in pass one does not yet know that a difficult scene is coming.

The arithmetic: for an 8MB target over 30 seconds, that is 64 megabits over 30 seconds, about 2.1 Mbit/s total. Subtract 128 kbit/s for audio and a few per cent for container overhead, and you have roughly 1.9 Mbit/s for video.

The one flag people forget

-movflags +faststart

An MP4 contains a moov atom holding the index of the whole file. By default ffmpeg writes it at the end, because it does not know the final sizes until it has finished. A browser streaming that file has to download to the end before it can play a single frame.

+faststart runs a second pass over the finished file to move the index to the front. Without it, your web video does not start until it has fully downloaded, which people then diagnose as a slow server. It costs a file rewrite and it is not optional for anything served over HTTP.

Hardware encoders and what they cost

h264_nvenc, h264_qsv, h264_videotoolbox and h264_vaapi encode on the GPU or a dedicated block, often ten to twenty times faster than x264.

They are less efficient. At the same file size, a hardware H.264 encode is noticeably worse than x264 -preset slow: the gap is usually described as one to two CRF points, and it is larger on difficult content. The silicon implements a smaller search.

Use them for live streaming, for screen recording, for anything where encode time is the constraint. Use software for anything that will be distributed.

Choosing the codec

• H.264: universal. Every browser, every device, every player. Still the correct default for general delivery.
• H.265 / HEVC: roughly 30 to 50 per cent smaller at the same quality. Patent licensing is complicated and browser support is uneven, which is why it is common in apps and rare on the open web.
• VP9: comparable to HEVC, royalty-free, supported in Chrome, Firefox and Edge, and by Safari in WebM.
• AV1: another 20 to 30 per cent over VP9, royalty-free, and slow to encode. libaom is the reference and is very slow; SVT-AV1 is far faster and is what most people should use now.

The free path

Everything above is ffmpeg and the open-source encoders it wraps: x264, x265, libvpx, SVT-AV1. These are not budget alternatives: x264 is the encoder against which commercial products are benchmarked, and it is what most of the industry ships. HandBrake is a free graphical front end for the same encoders if the command line is not for you.

The limitation

CRF is a quality target only in the sense that the encoder’s internal model says so. That model is tuned on typical camera footage, and it misjudges content that is not: screen recordings with large flat areas and sharp text, animation with hard edges, and anything with heavy grain. For those, the CRF that looks right is often three or four points from the usual one, and there is no way to know except to look.

And every quality number here (CRF values, “30 per cent smaller”, the PSNR and VMAF scores behind them) is an average over test material chosen by the people quoting it. On your footage the numbers will differ, sometimes substantially, which is why a thirty-second test encode remains the only honest method.