ffmpeg -i in.mp4 -c:v libx264 -crf 23 out.mp4

ffmpeg Command Builder

ffmpeg can do almost anything and its flag order matters. Pick a task and get a command with the arguments in the right places.

Lower is better. 18 near-lossless, 28 small.
Height calculated to keep aspect.

CRF, and why -ss goes before -i

CRF is constant quality rather than constant bitrate: the encoder spends whatever bits each scene needs to hit the target quality. 18 is visually near-lossless, 23 is a sensible default, 28 is noticeably compressed. Prefer it to a bitrate for anything not being streamed. Separately, argument order is not cosmetic. Putting -ss before -i seeks to that point before decoding, which is nearly instant; putting it after decodes everything up to that point first, which on a long file takes minutes. Combine -ss with -c copy and you get a trim with no re-encode at all.

Build ffmpeg commands for common video tasks

This ffmpeg command builder covers the operations people actually reach for: converting between containers and codecs, compressing with CRF and a slower preset, extracting audio, trimming with fast keyframe seeking, scaling while preserving aspect ratio, and two-pass GIF generation with a proper palette. It also handles VAAPI and NVENC hardware encoding and adds +faststart so files begin playing before they finish downloading.

ffmpeg FAQ

H.264, H.265, or AV1?

H.264 plays on everything and encodes quickly, which makes it the safe default. H.265 gives roughly the same quality at a smaller size but has patchier hardware and browser support. AV1 compresses best and is royalty free, but software encoding is slow and older devices cannot decode it. Choose by where the file needs to play.

Why is hardware encoding faster but worse looking?

Hardware encoders are fixed-function silicon optimised for speed and power, not compression efficiency, so at the same file size the result is visually worse than libx264 with a slow preset. Use hardware for realtime work like streaming or bulk transcoding; use software when quality per byte matters.

What does -c:a copy do and when can I use it?

It passes the audio stream through untouched instead of re-encoding, which is faster and avoids a second generation of lossy loss. It only works when the target container supports that audio codec. If muxing fails, re-encode with -c:a aac.

How do I cut a clip without re-encoding?

Put -ss before -i, add -t for the duration, and use -c copy. The catch is that stream copying can only cut on keyframes, so the start may land up to a few seconds off. Re-encode if you need frame-accurate cuts.