FAQ

Why does -ss behave differently depending on where I put it?

Placing -ss before -i tells the demuxer to seek directly to the nearest keyframe at or before that timestamp, which is fast but can be up to a couple of seconds off. Placing it after -i decodes from the very start and discards frames until the exact timestamp, which is precise but much slower on long files. For most trimming, seek-before-input plus a small re-encode at the cut point gives a good speed/accuracy balance.

Should I use -crf or -b:v?

Use -crf (constant quality) for most cases — you tell the encoder how much quality loss is acceptable and file size follows naturally, which generally looks better per byte than a fixed bitrate. Use an explicit -b:v target bitrate only when you have a hard size or bandwidth constraint to hit, such as fitting a file under a strict upload limit or matching a fixed streaming bitrate.

Why did -c copy fail or produce a broken file?

-c copy repackages existing streams without touching their encoding, so it only works when the target container actually supports those codecs — for example, some containers don't support certain subtitle or audio codec combinations. If a "copy" remux fails or plays back oddly, drop -c copy and let FFmpeg re-encode with the output container's default codecs instead.

Why does my output look blocky or low-quality?

Almost always the CRF value is too high (too much compression) or an explicit bitrate is too low for the resolution and motion in the source. Lower the -crf value (e.g. from 28 to 20) or raise -b:v, and consider a slower -preset, which spends more encoding time finding better compression at the same quality target.

Does FFmpeg support hardware-accelerated encoding?

Yes, if your build was compiled with support for it and your GPU/driver provides it: NVENC (NVIDIA), QSV (Intel Quick Sync), VAAPI (Linux/Intel/AMD), and VideoToolbox (macOS) are common options, selected via codec names like -c:v h264_nvenc or -c:v h264_vaapi in place of the software encoder. Hardware encoding is much faster but generally produces slightly larger files than a software encoder at the same visual quality.

How do I avoid quality loss when editing a video multiple times?

Every re-encode of a lossy codec (H.264, H.265, most audio codecs) loses some quality, so repeated edit-and-export cycles compound that loss. Where possible, do -c copy operations (trimming at keyframes, remuxing) that don't touch the encoded data, or work from a lossless or high-bitrate intermediate and only export the lossy final version once, at the end of your edit chain.