主体铺满竖屏，但左右都被裁掉。
只把布局改回配方中的 pad，重跑左右色条检查；裁切属于另一种交付选择。
实操配方
横版视频保全画面转竖版留边交付
制作竖版审片文件，同时保全横版构图。本例选用 160×90 内容区，左右各留 10 像素，上下各留 115 像素。
附实际运行过的本地样例、脚本和回执；不代表已调用视频生成服务。
01准备环境与输入
- 准备 Node.js 与支持 libx264、scale、pad 的 FFmpeg，必要时设置 FFMPEG_BIN。记录环境为 Node v24.18.0 与 FFmpeg 6.0。
- 使用配套原创 landscape-source.mp4，时长一秒、十帧，左边为红色标记，右边为黄色标记；本素材刻意不含音轨。
- 明确各层尺寸：源片 320×180、缩放内容 160×90、输出 180×320，位置 x=10、y=115。本例使用 yuv444p 做小型无损比较。
02执行配方
运行命令
node run-recipe.mjs --out ./my-run
为完整构图设置可测标记
脚本在横版两侧制作可辨识色条。它们是验收目标：即使输出文件宽高已经竖版，任何一侧色条丢失仍代表源构图被裁掉。
等比缩小，再增加画布
实际应用 scale=160:90:flags=neighbor,pad=180:320:10:115:color=black,setsar=1。内部 160×90 准确保持 16:9，外层为 9:16；保留少量侧边，避免把内容硬凑成 180 像素宽而出现比例舍入变形。
解码并比较内部矩形
完整解码竖版输出为 RGB，将内部 160×90 与单独缩放的源帧逐通道比较，容许最大差值四。本次实际测得零。这个容差和小型 yuv444p 夹具不代表完整色彩管理验收。
同时核对边框与帧数
验收十帧输出、上下黑边、左侧红标与右侧黄标。负向案例只是本地比例算式守卫：刻意不相等的交叉乘积触发拒绝，并没有另行编码拉伸坏文件或测试产品通用校验器。回执保留实际位置与最大 RGB 差值。
03检查结果
- 输出文件实际完整解码出十帧 180×320 RGB。
- 外层准确为 9:16，内部 160×90 仍为 16:9。
- 内部画面相对独立缩放源帧的最大通道差不超过四，本次实测为零。
- 上、下留边抽样像素各通道不超过三，符合黑色。
- 交付画面内部仍能测到左红、右黄两条构图标记。
- 本地比例算式守卫拒绝不相等的交叉乘积；它不是对 FFmpeg 拉伸坏文件的检测，八项检查全部通过。
04排错与交付
画面似乎被轻微挤压。
先把内部尺寸恢复为 160×90，再增加留边，用交叉相乘核对准确 16:9。
导出后像素比较产生差值。
先比较 FFmpeg 版本与像素格式，重跑配套 yuv444p 夹具，再为另一种交付编码确定容差。
本回执只证明原创小型夹具的这次布局转换。正式上传前，仍应另行核对目标平台的编码与分辨率要求。