FFmpeg height not divisible by 2: why and how to fix it

"Height not divisible by 2" means the video you are encoding in yuv420p has an odd height; an odd width gives the matching width error. yuv420p stores color at half the picture's width and half its height, so both sides have to be even. Make the size even: give the computed side as -2 in the scale filter (scale=1280:-2), or round an odd frame down with scale=trunc(iw/2)*2:trunc(ih/2)*2.

The FFmpeg facts come from its filters, ffmpeg, and utilities documentation and its pixfmt.h reference, and Sume's from the Video filter, Video trim, and Timeline 1.0 docs and the Sume API reference, read on 2026-09-28. Anything described as current behavior is read from Sume's code.

Why does yuv420p need even dimensions?

In a 4:2:0 format such as yuv420p, each 2×2 block of pixels shares one set of color samples, so the color planes are half as wide and half as tall as the picture. FFmpeg calls these factors the chroma subsample values, hsub and vsub. One of its scale examples rounds a size to multiples of them, and another makes the resolution even, which it notes is required by some codecs. An odd side leaves a half block that the encoder won't take.

The odd number comes from whatever set the size: a scale that computed one side, a crop, or a source that was already odd. Fix it at the step that sets the size.

How do I fix it with the scale filter?

Pick the form that matches how you set the size. What each one does comes from FFmpeg's scale filter documentation:

# Width 1280, height from the aspect ratio, rounded to even
ffmpeg -i input.mp4 -vf scale=1280:-2 -c:v libx264 -pix_fmt yuv420p -c:a copy output.mp4

# Keep the size, but round an odd width or height down to even
ffmpeg -i input.mp4 -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" -c:v libx264 -pix_fmt yuv420p -c:a copy output.mp4

What about the crop filter?

FFmpeg's crop filter rounds for you by default, but only on a subsampled video. Its exact option defaults to 0, and while it's off, a subsampled video's crop width, height, and position are rounded down to the nearest smaller value instead of being used exactly as given. A source without chroma subsampling, such as yuv444p, gets no such rounding, so an odd crop there reaches the yuv420p encode still odd. In that case, and whenever you set exact=1, keep the numbers even yourself, for example with trunc(iw/2)*2-style expressions.

How does Sume handle odd sizes?

Sume's trim, filter, and Timeline tools read your workspace's media.sume.com files, such as an earlier Sume job's output. An exact trim writes H.264 in yuv420p, per its docs, and in current code so do video filter and Timeline, so their output sizes have to be even too. Here is how each one handles it:

• Video filter's crop op takes the rectangle as fractions of the source frame, and the compiler even-rounds it for yuv420p. How to crop a video without losing quality shows the op.
• Video trim's output takes a width and height from 256 to 2160. In current code, each is rounded down to an even number, and if you set only one side, the other is computed with -2 to keep the aspect ratio. Without output, an exact trim keeps the source's size as it is, so send output if the source itself is odd.
• Timeline 1.0's output.width and output.height must be even integers from 256 to 2160, and in current code Timeline compose's output size must be even too. Change a video's frame rate or resolution covers both.
• A raw filtergraph on video filter is yours to keep even. scale is on the filter allowlist, and the free POST /v1/video-filter/check runs the schema and allowlist checks without touching the encoder, so a program that passes it can still fail when it runs. Use -2 or trunc(iw/2)*2 in any size you compute.