Resolution & aspect ratio

Why the rounding matters

Every delivery codec stores colour at half resolution in each direction (4:2:0 chroma subsampling), so a frame needs an even width and height for the chroma plane to line up; libx264 refuses odd dimensions outright with "height not divisible by 2". Scaling 1920×1080 to a width of 1280 gives a height of exactly 720, but a width of 1000 gives 562.5, and the naive scale=1000:-1 rounds that to 563 and fails. In a hand-written command the -2 idiom (scale=1000:-2) tells FFmpeg to derive the side from the aspect ratio and round it to a multiple of two, which is the right spelling when the same command has to work on sources of different sizes. The filter under the result states both numbers instead, because the calculator has already snapped the side you asked for to the alignment you chose, and -16 would round the other side from the unsnapped value and land one step away from the frame shown.

Some hardware encoders want multiples of 4 or 8, and H.264 encodes in 16×16 macroblocks: a frame that is not a multiple of 16 is padded internally and cropped on output, which costs a little efficiency and occasionally confuses old players. 1920×1080 is the famous case (1080 is not a multiple of 16; the encoder works on 1088 lines and crops). For delivery, even dimensions are enough; pick 16 when you are choosing a master size from scratch.

Aspect drift

Rounding the derived side moves the aspect ratio a hair. The drift line says by how much: 0.1% is invisible, 1% is a slightly wrong shape that nobody will notice until it is next to the original, and a source with a stated display aspect ratio that differs from its pixel shape (anamorphic DVD rips, some camera formats) will drift far more than the number here, because the scaler works on pixels and the player on DAR. Add setsar=1 after the scale when you want the output to be taken at face value.