Shrink a video's file size
Shrinks a video's file size with libx264's CRF quality setting, trading a small, controllable amount of quality for a much smaller file.
Last updated
ffmpeg -i input.mp4 -c:v libx264 -crf 28 -preset slow -c:a aac -b:a 128k output.mp4
How it works
-crf 28 is the main lever: libx264's Constant Rate Factor scale runs roughly 0 (lossless, huge) to 51 (unwatchable), with 23 as the encoder's own default and 28 landing noticeably smaller with only mild, hard-to-spot quality loss on most content — lower the number for a closer-to-source result, raise it for a smaller file. -preset slow tells the encoder to spend more time searching for a more efficient encoding at that same CRF, which shrinks the file further without changing the quality target — it trades encode time for compression efficiency, not quality for size directly.
-c:a aac -b:a 128k re-encodes the audio track to a fixed 128kbps AAC stream instead of leaving it untouched — video re-encodes typically re-encode the audio too by default at whatever bitrate ffmpeg happens to choose, so stating it explicitly keeps the audio size predictable alongside the video savings.
Watch out for
- →The CRF number is codec-specific and doesn't transfer directly: 28 on libx264 is roughly comparable to 32–33 on libx265 for similar perceived quality — don't reuse the same value if you switch -c:v to libx265.
- →-preset only trades encode SPEED for compression efficiency at a given CRF, it doesn't change the target quality — ultrafast finishes almost instantly with a somewhat larger file at the same CRF; veryslow squeezes out the smallest file but can take many times longer.
- →This always re-encodes, so it's inherently lossy — re-running it on an already-compressed file compounds the quality loss each time; keep the original if you might need to re-derive it later.
Part by part
- -c:v libx264
- The H.264 encoder, chosen because it plays on essentially everything. Newer codecs compress better but are not universally supported.
- -crf 28
- Constant Rate Factor — the quality target. Lower is better quality and larger; the scale runs 0 to 51 and 18 to 28 is the useful band.
- -preset slow
- How much time the encoder spends looking for savings. Slower presets produce smaller files at identical quality, costing only your time.
- -c:a aac -b:a 128k
- Re-encode the audio to AAC at 128 kbps, which is transparent enough for speech and most music while being a fraction of the original.
Common mistakes
ffmpeg -i input.mp4 -b:v 1000k output.mp4Targeting a fixed bitrate spends the same bits on a still frame as on a fast pan, so quality swings wildly. CRF varies the bitrate to hold quality steady, which is what you actually want.
ffmpeg -i input.mp4 -c:v libx264 -crf 28 -preset slow -c:a aac -b:a 128k output.mp4ffmpeg -i input.mp4 -c:v libx264 -crf 51 output.mp4The top of the scale is not a compression setting, it is a destruction setting. Anything above about 30 shows obvious blocking, and 51 produces a file nobody will watch.
ffmpeg -i input.mp4 -c:v libx264 -crf 28 -preset ultrafast output.mp4The fastest preset produces a noticeably larger file at the same CRF. If the point of the command is a smaller file, choosing the preset that compresses worst defeats it.
Questions
What CRF should I use?
Start at 23 for general use, 28 when size matters more than fidelity. A change of about six roughly doubles or halves the file size, so adjust in small steps and compare rather than guessing at extremes.
Does a slower preset lose quality?
No, the opposite. Preset controls how hard the encoder searches for savings, so slower means a smaller file at the same visual quality. It only costs encoding time.
Should I use H.265 or AV1 instead?
They compress substantially better, and support is the catch — H.265 has patent and browser complications, AV1 encodes slowly. For a file you are sending to someone else, H.264 remains the one that just plays.
Why re-encode the audio at all?
You often need not; add -c:a copy to keep it untouched. This recipe re-encodes because source audio is frequently at a much higher bitrate than the compressed video needs, and 128k AAC removes that mismatch.