Resize / scale video with FFmpeg: lanczos, bicubic, and the algorithm that matters

When to use this

You resize video for adaptive bitrate ladders (one master, many output resolutions), mobile-specific delivery (smaller resolutions reduce bandwidth), proxy generation for editing workflows (low-res working copies), or thumbnail extraction. The scaler choice matters more than most teams realize: bilinear (default) is fast but blurry; bicubic is the standard production choice; lanczos is sharper at the cost of compute. Picking wrong = downgraded perceived quality across your entire ladder.

Command variants

ffmpeg -i input.mp4 \
  -vf "scale=1280:720:flags=lanczos" \
  -c:v libx264 -preset medium -crf 22 \
  -c:a copy \
  output_720p.mp4

ffmpeg -i input.mp4 \
  -vf "scale=-2:720:flags=lanczos" \
  -c:v libx264 -preset medium -crf 22 \
  -c:a copy \
  output_720p.mp4

ffmpeg -i input.mp4 \
  -vf "scale=1280:720:flags=lanczos,format=yuv420p10le" \
  -c:v libx265 -preset medium -crf 22 \
  -c:a copy \
  output_720p_hdr.mp4

What each parameter does

• scale=W:H

  Output width × height. Use -2 for auto-aspect-preserving (rounded to even); use -1 for auto without rounding (can break codecs).

• flags=lanczos

  Scaling algorithm. Options: bilinear (fast, blurry), bicubic (good default), lanczos (sharper, slightly slower), spline (similar to lanczos).

• format=yuv420p

  Force pixel format after scaling. Important when scaling 10-bit HDR sources where default scaling can drop precision.

What this outputs

A resized video file at the dimensions you specified. Quality varies dramatically by scaler choice — lanczos for sharpness, bicubic for balanced default, bilinear only when speed dominates.

Pitfalls

1. Default scaler (bilinear) is fast but blurry. Always specify flags=lanczos or flags=bicubic for production output.
2. Width/height not divisible by 2 breaks H.264/HEVC encoders requiring even dimensions. Use -2 for auto-aspect-preserving rounded scaling.
3. Scaling 10-bit sources with default flags drops to 8-bit silently. Force format=yuv420p10le after scaling to preserve precision.
4. Upscaling (scaling up to higher resolution) doesn't add real detail — the result looks sharper than naive scaling but isn't magic. Use only when delivery requires a specific target resolution.
5. Per-rendition scaling in ABR ladders should use the same scaler across all renditions for consistency. Mixing scalers produces visible quality differences between renditions.

At production scale

Scaling is libx264-bound but cheap relative to encoding. lanczos adds ~5-10% encode time over bicubic; minimal impact at scale. For ABR ladder generation across 5 renditions, the per-rendition scale is a small fraction of total compute. Where scaling cost matters: high-volume thumbnail extraction (one source → 100 thumbnails), where the scaling itself dominates.

MpegFlow uses lanczos by default for production renditions and exposes the scaler choice as a per-rendition parameter. The audit log records the scaler used per encode, so quality regressions from accidental scaler changes are catchable.

• FFmpeg
• Scale
• resize
• video-operations
• ABR ladder

• Recipe
  Abr Ladder Generation
• Recipe
  Crop Video