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

You try to encode a video with libx264, and FFmpeg stops with height not divisible by 2 (or the matching width not divisible by 2). The encode never produces an output file. This is one of the most common FFmpeg errors, and it has a single root cause: the default yuv420p pixel format requires both the width and the height to be even numbers, and your video — usually after a scale or crop — ended up with an odd dimension. This article explains why the constraint exists and gives you three fixes you can paste in as-is.

Tested with: FFmpeg 8.1 (verified against real FFmpeg)

What You’ll Learn

• Why libx264 with yuv420p rejects odd width or height, in plain terms
• How an innocent-looking scale or crop produces an odd dimension
• Three runnable fixes: scale=trunc(...), scale=-2:..., and pad=ceil(...)
• Which fix to choose: silently round down, keep the aspect ratio, or letterbox

The error message points at the encoder, but the real fix is upstream: make sure the frame handed to the encoder has even width and even height. Once you internalize that, every variant of this error becomes a one-line filter change.

Why yuv420p Needs Even Dimensions

The default pixel format for H.264 output is yuv420p. The 420 is the key. It means chroma subsampling 4:2:0: the color (chroma) information is stored at half the horizontal and half the vertical resolution of the brightness (luma). In other words, one chroma sample covers a 2×2 block of luma pixels.

If the width or height is odd, that 2×2 grid does not tile the frame cleanly — there is a leftover row or column of luma pixels with no matching chroma sample. Rather than guess, the encoder refuses 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 dimensions in the parentheses (1280x721 above) tell you exactly which side is the problem — here the height, 721, is odd.

The most common way to get an odd dimension is scaling by ratio. For example, halving a 1280x721 source gives 640x360.5, which FFmpeg floors to 640x360 — but if the math lands on an odd integer like 721, the encoder rejects it. Cropping to a hand-typed odd number (crop=641:480) does the same thing.

Fix 1: Round Down to Even with trunc

The most general fix works no matter what the input size is: force both dimensions to the nearest even number with trunc. trunc(iw/2)*2 divides the width by 2, throws away the fraction, then multiplies back by 2 — which always yields an even number at or just below the original.

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 drops at most one pixel from each odd side, which is visually invisible. Because it never grows the frame, it’s the safe default when you just want the encode to succeed and you don’t care about preserving an exact target resolution.

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

When you are deliberately resizing — say, “make it 720p tall and keep the proportions” — let FFmpeg compute the other dimension for you, but tell it to land on an even number. That is exactly what -2 means in the scale filter: “calculate this side to preserve the aspect ratio, then round to a multiple of 2.”

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

Here the height is fixed at 720 and the width is derived from the source aspect ratio, automatically snapped to an even value. Use -2 (not -1) precisely because -1 can produce an odd width and re-trigger the same error. The same idea works when you want to fix the width instead:

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

This is the fix to reach for whenever you’re downscaling for a target like 720p or 1080p. You set one dimension; -2 guarantees the other is both proportional and even.

Fix 3: Pad Up to the Next Even Size

If you must not lose a single pixel of picture, don’t shrink — grow the canvas instead. The pad filter adds a thin border so the dimensions become even, leaving the original frame fully 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

For an odd side this adds exactly one row or column of padding (black by default). The full original image survives; you only gain a one-pixel border on the sides that were odd. Choose this when the source is precious — for example archival footage or screen recordings where cropping a pixel could clip important content.

Which Fix Should You Use?

All three end with even width and even height, which is all the encoder needs. The choice comes down to whether you’d rather lose a sliver, resize cleanly, or add a sliver of border.

FAQ

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

Both ask FFmpeg to compute that dimension from the aspect ratio. -1 produces the mathematically exact value, which can be odd and re-trigger height not divisible by 2. -2 does the same calculation but rounds the result to a multiple of 2, so it is always safe with yuv420p. For H.264 output, prefer -2.

Why does my crop cause this error?

crop outputs exactly the size you specify, so if you typed an odd number — for example crop=641:480 — the cropped frame has an odd width and the encoder rejects it. Use even target numbers, or compute them automatically with crop=trunc(iw/2)*2:trunc(ih/2)*2.

Can I just change the pixel format instead?

You can switch to a format without 4:2:0 subsampling, such as -pix_fmt yuv444p, which has no even-dimension requirement. But many players and devices only decode yuv420p reliably, so the resulting file may not play everywhere. Fixing the dimensions 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 whichever side it hits first. Rounding both dimensions to even with trunc or ceil covers every case, so you don’t have to figure out which one is actually odd.

Does this happen with codecs other than libx264?

Yes. Any encoder writing yuv420p (H.264, H.265/HEVC, and others) inherits the same even-dimension requirement because it comes from the pixel format, not the codec. The same scale/pad fixes apply.

Related Articles

• How to Scale and Resize Video
• How to Make Vertical Video
• Fixing Common FFmpeg Errors
• FFmpeg Codec Errors and Fixes

Tested with FFmpeg 8.1 — verified with our command-check script
Primary sources: ffmpeg.org/ffmpeg.html / ffmpeg.org/ffmpeg-filters.html#scale / trac.ffmpeg.org/wiki/Scaling