FFmpeg: Fix "height not divisible by 2" / "width not divisible by 2"

Q: Why does my crop cause this error?

With a yuv420p source, crop rounds an odd size down to an even one, so crop=641:480 gives 640x480 and encodes. The odd size reaches the encoder when you crop RGB frames, such as PNG images, and the output is yuv420p (for example with -pix_fmt yuv420p), or when you add exact=1. Use even numbers, or calculate them with crop=trunc(iw/2)*2:trunc(ih/2)*2.

Q: Can I just change the pixel format instead?

Yes. -pix_fmt yuv444p (no chroma subsampling) has no even-size requirement. With 4:2:2 (yuv422p) the width must still be even. But many players and devices only decode yuv420p reliably, so the file may not play everywhere. Fixing the size is the more compatible solution.

Q: The error mentions width, but I only changed the height — why?

scale and crop can change both sides at once, and the encoder reports the first odd side it finds. If you round both dimensions to even with trunc or ceil, you do not need to work out which one is odd.

You encode a video with libx264 and FFmpeg stops with height not divisible by 2 (or width not divisible by 2). No output file is written. This is one of the most common FFmpeg errors, and it has one cause. In the yuv420p pixel format, libx264 needs an even width and an even height, and your video ended up with an odd one, usually after a scale or crop.

The message comes from the encoder, but you fix it earlier in the command: make sure the frames that reach the encoder have an even width and an even height. Each variant of this error then comes down to a one-line filter change.

Why yuv420p Needs Even Dimensions in H.264

FFmpeg keeps the source’s pixel format when libx264 supports it, so a yuv420p source gives yuv420p output. The 420 stands for chroma subsampling 4:2:0: the color (chroma) information is stored at half the width and half the height of the brightness (luma). One chroma sample covers a 2×2 block of luma pixels.

If the width or height is odd, the 2×2 blocks do not fit the frame exactly, and one row or column is left with half a block. libx264 does not accept that with 4:2:0, so it refuses the frame and reports width not divisible by 2 or height not divisible by 2.

# This is what the failure looks like
[libx264 @ ...] height not divisible by 2 (1280x721)
[vost#0:0/libx264 ...] Error while opening encoder - maybe incorrect
parameters such as bit_rate, rate, width or height.
Conversion failed!

The size in parentheses (1280x721 above) shows which side is the problem. Here the height, 721, is odd.

The most common way to get an odd size is scaling by a ratio. For example, halving a 1280x722 source gives 640x361, and the encoder rejects the odd height. Cropping an RGB source, such as PNG images, to an odd size (crop=641:480) does the same when the output is yuv420p.

Fix 1: Round Down to Even with trunc

This fix works for any input size. It rounds both dimensions down to an even number with trunc. trunc(iw/2)*2 divides the width by 2, drops the fraction and multiplies by 2 again. The result is always an even number, equal to the original or just below it.

ffmpeg -i input.mp4 -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" -c:a copy output.mp4

iw / ih — the input width and height
trunc(iw/2)*2 — round the width down to an even number
trunc(ih/2)*2 — round the height down to an even number
-c:a copy — leave the audio untouched (no re-encode)

This makes each odd side one pixel smaller. scale resizes the whole picture to the new size; it does not cut off a row or column. It never makes the frame larger, so it is the safe default when you only need the encode to succeed and do not need an exact target resolution.

Fix 2: Keep the Aspect Ratio with scale=-2

When you resize on purpose (for example, “make it 720p tall and keep the proportions”), let FFmpeg calculate the other side and make it land on an even number. That is what -2 means in the scale filter: calculate this side from the aspect ratio, then round it to a multiple of 2.

ffmpeg -i input.mp4 -vf "scale=-2:720" output.mp4

The height is fixed at 720, and the width is calculated from the source aspect ratio and rounded to an even value. Use -2, not -1: -1 can give an odd width and cause the same error again. It also works the other way round, with a fixed width:

ffmpeg -i input.mp4 -vf "scale=1280:-2" output.mp4

Use this fix when you downscale to a target such as 720p or 1080p. You set one side, and -2 makes the other side proportional and even.

Fix 3: Pad Up to the Next Even Size

If you cannot lose a single pixel, make the canvas larger instead of shrinking the picture. The pad filter adds a thin border so both dimensions become even, and the original frame stays intact.

ffmpeg -i input.mp4 -vf "pad=ceil(iw/2)*2:ceil(ih/2)*2" output.mp4

ceil(iw/2)*2 — round the width up to the next even number
ceil(ih/2)*2 — round the height up to the next even number

Each odd side gets exactly one row or column of padding (black by default). The whole original image is kept, with a one-pixel border added on the sides that were odd. Use this when every pixel matters, for example archival footage or screen recordings.

Which Fix Should You Use?

Fix	Filter	Effect on size	Best for
Round down	`scale=trunc(iw/2)2:trunc(ih/2)2`	Shrinks by ≤1px per odd side	Generic “just make it encode”
Keep aspect	`scale=-2:720` (or `scale=1280:-2`)	Resizes to target, even	Downscaling to 720p/1080p
Pad up	`pad=ceil(iw/2)2:ceil(ih/2)2`	Grows by ≤1px per odd side	Preserving every pixel

All three give an even width and an even height, which is all the encoder needs.

FAQ

What is the difference between -1 and -2 in scale?

Both make FFmpeg calculate that side from the aspect ratio. -1 gives the exact value, which can be odd and cause height not divisible by 2 again. -2 does the same calculation and then rounds to a multiple of 2, so it is always safe with yuv420p. For H.264 output, use -2.

Why does my crop cause this error?

With a yuv420p source, crop rounds an odd size down to an even one, so crop=641:480 gives 640x480 and encodes. The odd size reaches the encoder when you crop RGB frames, such as PNG images, and the output is yuv420p (for example with -pix_fmt yuv420p), or when you add exact=1. Use even numbers, or calculate them with crop=trunc(iw/2)*2:trunc(ih/2)*2.

Can I just change the pixel format instead?

Yes. -pix_fmt yuv444p (no chroma subsampling) has no even-size requirement. With 4:2:2 (yuv422p) the width must still be even. But many players and devices only decode yuv420p reliably, so the file may not play everywhere. Fixing the size is the more compatible solution.

The error mentions width, but I only changed the height — why?

scale and crop can change both sides at once, and the encoder reports the first odd side it finds. If you round both dimensions to even with trunc or ceil, you do not need to work out which one is odd.

Does this happen with codecs other than libx264?

With H.265/HEVC, yes: libx265 also refuses an odd width or height in yuv420p. The VP8, VP9 and AV1 encoders (libvpx, libvpx-vp9, libaom-av1, libsvtav1) and mpeg4 accept odd sizes, so the limit comes from libx264 and libx265, not from yuv420p itself. For libx265, the same scale and pad fixes apply.