宽度必须取偶：转码失败 width not divisible by 2
报错栏里蹦出“width not divisible by 2”，很多人第一反应是文件坏了。其实文件没坏，是你要的输出尺寸是个奇数，而视频编码的世界里奇数寸步难行。
为什么编码器要求偶数
主流视频编码（H.264/HEVC）的像素格式是 YUV 4:2:0：色度分量的分辨率只有亮度的一半，编码器按 2×2 的像素块（宏块）处理画面。一个 2×2 的亮度块对应 1×1 的色度块，两边都必须是整数——宽度或高度一旦是奇数，最后一行（列）的色度像素凑不齐块，编码器直接拒绝工作。
所以这不是工具的刁难，而是编码格式的硬性约束。853×480、1081×607 这类奇数尺寸，在任何一个严谨的编码器那里都通不过。
奇数尺寸是怎么造出来的
最常见的手工事故是按比例手算：说“16:9 缩到 853×480”，可 853 是奇数——比例没错，尺寸非法。第二类是旋转 90 度：1920×1080 转成 1080×1920 没问题，但 1081×607 这类本来就奇的尺寸旋转后奇偶互换，另一边炸了。第三类是按像素裁剪：四边各裁 27 像素，偶数宽度立刻变奇数。
源文件本身是奇数的情况也存在——个别录屏工具与老设备会产出 1367×768 这种尺寸，这类源文件转码时天然踩线。
修复路径：缩到偶数或裁到偶数
修复永远不复杂。要改尺寸的，用缩放工具指定一个偶数高度（480/720/1080），宽度会自动等比换算并取偶——这是最推荐的路径，工具替你处理了奇偶问题。要保持原分辨率的，用画面裁剪把多出来的那一像素裁掉（比如 1921 裁成 1920），代价是损失一列像素，肉眼不可见。
两边都是奇数就各裁一像素。永远不要试图“改一下报错再试”——奇数在任何重编码场景下都通不过，报错会原样回来。
预防：把取偶交给工具
预防只有一条：需要精确控制输出尺寸时，先确认目标是偶数；不确定就用带自动取偶的缩放工具，把宽高比的对齐交给它。批量场景尤其如此——几十个源文件里混进一个奇数尺寸，整批任务在它这里卡壳，事前取偶比事后救火便宜得多。
顺带一提，取偶不只为了报错不出现：部分平台的转码系统对奇数尺寸的处理是“静默拉伸”，画面轻微变形且不易察觉——偶数尺寸同时也是防变形的保险。