为什么大家搜「视频改尺寸在线」时一半在救兼容一半在救审美？
微信发不出、企业微信附件红字、旧投影仪只认一百九十二零乘一千零八零、剪映模板写死画布，本质都是同一句话：像素矩阵与容器预期不一致。用户常搜「mp4 改分辨率」「视频缩放 在线」「四 K 压成 一百零八零 p」「竖屏 九比十六」「H 二六四 偶数宽高」「上传体积太大怎么办」——核心诉求是把可播放性、可剪辑性与文件体积放在同一天平上。Ai2Done 在浏览器里用 FFmpeg.wasm 走 `scale=宽:高,setsar=1`：把画面统一缩到你输入的偶数宽高（常见编码对四二比零更友好），并用 `setsar=1` 固定像素宽高比，减少「外面显示的分辨率」和真实像素矩阵对不上号的坑；视频侧用 `libx264` 预设与 CRF 策略重编码，音轨默认 copy 以省一次不必要的有损再压。也要诚实写清边界：这是整帧等比或你手动解锁后的缩放，不是智能追脸裁切，也不会自动给横屏四周垫黑变成竖屏「信箱」；横素材硬填九比十六像素若未先在外部做构图，只会得到拉伸或你需另选目标尺寸。另，手机竖拍的「旋转元数据」与编码帧宽高可能不一致，导出后请以播放器与文件属性里的实际宽高为准做验收。单文件五百兆上限与 WASM 性能现实存在，长直播建议先切段再缩放。只处理有权素材，换分辨率不改版权。
如何用预设或自定义像素在浏览器里导出可分享的缩放版 MP4
- 在桌面浏览器打开调整视频尺寸，选取本机视频并等待元数据载入；确认页面提示的单文件上限后，观察自动填入的宽高等于是解码后的预览尺寸，若与手机相册「看起来是竖」不一致，先理解这是旋转元数据与编码像素常见差异再决定目标宽高。
- 点选一百零八零 p、七百二十 p 或四百八十 p 预设，或在锁定宽高比前提下手动改一侧数值让另一侧联动为偶数；若你要非标准广告位像素，可取消锁定单独输入，但应预知与源比例不一致时会出现拉伸，必要时回到剪辑先裁切或垫画布。
- 点击缩放并等待进度完成，下载带 `-resized` 后缀的 MP4，用目标渠道各测一遍首秒与字幕区；通过后按「用途_宽高_日期」命名并与母带互链哈希，勿用缩放版覆盖唯一精修母带。
调整视频尺寸常见问答
锁定宽高比时点一百零八零 p 预设，为什么宽会变成一千九百二十而高仍按我源片比例算，这算不算「没有真正变成 YouTube 默认画布」？
预设给的是常见横屏基准的一对宽高，工具在锁定比例下会保持你的纵横比去贴合这条边，而不是强行把构图改成平台模板；若你要严格固定一千九百二十乘一千零八零像素且不允许上下留空，需要源本身就是该比例或先在剪辑里裁切/加边再缩放。
从四 K 缩到一百零八零 p 后肉眼觉得更糊，是 CRF 与 ultrafast 预设必然损失还是下采样本身正常、我该如何判断该不该保留四 K 母带？
下采样不会增加细节只会合并像素，主观发糊与码率预算、运动幅度与源噪声都相关；应并排对比同一片段在目标播放设备上的观感，并永远保留四 K 或原始工程作为母带，缩放版只作传播档。
导出后播放器显示宽高与我在输入框里填的差两个像素，是不是工具偷偷改了，还是偶数对齐与 SAR 修正的正常行为？
脚本会把宽高收束到不小于二的偶数以适配常见色度子采样；`setsar=1` 用于避免非一方形像素导致外部工具读到的显示尺寸漂移，应以导出后探测到的视频流宽高为验收依据。
音轨是会议双声道混音，缩放视频时会不会被重编码导致口型对不齐或音量变化，若出现不同步应优先怀疑哪些源特征而不是缩放滤镜本身？
当前链路对音频采用 copy，正常情况下不会二次有损压缩视频轨以外的声波；若你遇到不同步，应优先怀疑源是否可变帧率或播放器缓冲策略，而不是先怀疑缩放滤镜本身。
五百兆上限内一段两小时录屏缩放失败，更可能是内存顶穿还是磁盘临时空间不足，排障顺序应怎么写进团队 wiki？
应先关其它 WASM 重任务、换更短样片试跑确认不是源损坏，再检查本机浏览器可用内存与系统剩余磁盘；仍失败时记录浏览器版本与文件码率特征，避免全员重复踩同一上限。