工作流 约 4 分钟
压缩前先算账：四个计算器的配合用法
"压到 50MB 以内"这类需求最怕试错：压一次等五分钟，超了调参再压一次。四个计算器把整条决策链变成算术——动手处理前，答案已经算出来了。
核心一算：目标大小反推码率
按目标大小压缩的入口是码率反推：总码率（kbps）≈ 目标大小（MB）× 8192 ÷ 时长（秒）。工具把这个换算自动化——输入目标大小和时长，直接得到应设的总码率，还能按视频与音频的分配比例（如音频留 128kbps）拆出视频码率。结果直连"按大小压缩"工具，参数免手抄。
算出来的码率要过一遍合理性检查：对照常见分辨率的码率参考表，如果 720p 只分到 500kbps，说明目标大小对这段素材过于苛刻——要么提高预算，要么降分辨率，硬压的结果是画质崩盘。
辅助三算：体积、比例、时间码
体积正算（文件大小估算器）：按当前码率和时长预估成品体积——上传平台前预估是否超限，方向与码率反推正好相反，两者互为验算。宽高比换算：给定比例（16:9、9:16）和一个边长，算出另一边与化简后的比例——裁切与画布设置的必备小工具，避免 1280×720 和 1280×721 这类差一像素的尴尬。
时间码换算：帧数、秒、SMPTE 时间码三方互转，支持 29.97 丢帧制。字幕对轴、截取定位、口播卡点都按"第几秒"思考，而剪辑软件按"第几帧"显示——需要换算的场合，手算容易在丢帧制上翻车。
把计算器嵌进工作流
推荐的处理前仪式：拿到需求和素材时长，先算码率（三十秒）→ 合理性对照（半分钟）→ 定参数处理 → 成品体积估算复核。全程两分钟，换来的是"一次压对"，省掉的是一轮又一轮的"压完发现超了再重来"。
计算器不能替代判断的部分也要清楚：算出的是平均码率，实际编码按内容复杂度浮动；CRF 模式没有精确体积承诺，需要精确大小就用目标码率模式——这是两套压缩哲学，计算器属于后者。