「视频太大发不出去」大概是最高频的日常技术问题之一。微信文件传输、邮件附件、各类平台上传，都有明确的体积上限。
浏览器现在已经能直接干这件事——靠的是 ffmpeg.wasm，把 FFmpeg 编译成 WebAssembly 在你的设备上跑。文件不上传服务器。但这个方案有明确的适用边界，先说结论：十几秒到几分钟的短素材没问题，一部两小时的电影别在浏览器里压。
一、决定体积的只有一件事：码率
很多人以为分辨率决定体积，其实不是。
文件体积 ≈ 码率 × 时长
码率（bitrate）指每秒钟用多少数据来描述画面，单位通常是 kbps 或 Mbps。一段 60 秒、码率 2 Mbps 的视频，体积约为 2 Mbps × 60s ÷ 8 = 15 MB。分辨率之所以看起来影响体积，是因为高分辨率需要更高的码率才不糊，而不是分辨率本身占空间。
所以压缩视频的本质就是降码率，分辨率只是配套调整。
二、分辨率与码率的搭配
码率给太低会出现马赛克和拖影，给太高是浪费。常用参考（H.264 编码、普通动态画面）：
- 1920×1080：4–6 Mbps
- 1280×720：2–3 Mbps
- 854×480：1–1.5 Mbps
- 640×360：0.6–0.9 Mbps
两条修正规则：
画面动得越厉害，需要的码率越高。 游戏录屏、运动镜头、镜头频繁移动的 vlog，按上限取值甚至再高一点。反之，讲课录屏、PPT 演示、固定机位访谈，取下限的一半往往都看不出问题——静态画面帧间差异小，编码器可以省下大量数据。
分辨率降一档，码率能降到约四成。 从 1080p/5Mbps 降到 720p/2Mbps，体积只剩不到一半，而在手机屏幕上几乎看不出区别。这是压缩收益最大的一步。
三、按目标体积反推参数
假设一段 3 分钟（180 秒）的视频要压到 20MB 以内：
总码率 = 20 MB × 8 ÷ 180s ≈ 0.89 Mbps ≈ 890 kbps
留出音频：音频给 128 kbps（够用，语音内容 64 kbps 也可以），剩给视频约 760 kbps。
对照上面的表，760 kbps 撑不起 720p，应该选 480p。如果你坚持 720p，结果就是画面在动起来的时候糊成一团。
这就是为什么很多人「压了但还是很糊」——不是工具不行，是目标体积和想要的分辨率在物理上不可能同时满足。这种情况下有两个真正的解法：接受更低的分辨率，或者剪掉不必要的片段来缩短时长。后者常常被忽略，但一段 3 分钟的视频里如果有 1 分钟是无用的开头和结尾，剪掉就等于直接省下三分之一体积，且完全不损失画质。
四、CRF 模式：不指定体积，只指定画质
如果你没有硬性体积限制，只想「让文件小一点但看起来差不多」，用 CRF（恒定质量）模式比指定码率更聪明——它会在复杂画面多给数据、简单画面少给数据。
CRF 取值 0–51，越小画质越高、体积越大：
- 18：接近视觉无损，体积约为原文件的一半
- 23：默认值，通用推荐，多数情况下看不出损失
- 28：明显变小，细看有损失但可接受
- 32 以上：肉眼可见糊
拿不定主意就用 23。
五、浏览器方案的真实代价
这些必须说清楚，免得你等半天才发现不合适：
首次使用要下载约 30MB 的 wasm 内核。 这是 FFmpeg 本体，绕不过去。本站做了同源托管和实例复用——同一次访问里再打开其他视频工具不用重复下载，但第一次的等待是实实在在的。
速度约为原生 FFmpeg 的三到五成。 WebAssembly 有性能损耗。压一段 1 分钟的 1080p 视频，通常在几十秒到两三分钟，取决于你的 CPU。
内存有上限。 浏览器标签页的可用内存有限，几百 MB 以上的源文件有较大概率失败或崩溃。这不是 bug，是这个方案的物理边界。
什么时候该改用桌面软件： 源文件超过 500MB、时长超过 20 分钟、需要批量处理几十个文件、或者需要硬件编码加速。这些场景请直接用 HandBrake 或命令行 FFmpeg，别在浏览器里硬扛。
反过来，浏览器方案的优势场景是：文件不大、只压一两个、不想装软件、以及——文件内容敏感不想上传。
六、几个具体场景的建议参数
- 发微信/QQ 的手机录像：720p，CRF 26，音频 128 kbps
- 讲课录屏、PPT 演示：保持原分辨率，CRF 28（静态画面压缩效率极高，往往能小到十分之一）
- 上传到需要严格控体积的系统：先算目标码率，再照第三节反推分辨率
- 只需要一小段：先剪辑再压缩，顺序反了会白等
- 只是要做个动图：别压视频，直接转 GIF，注意 GIF 只有 256 色且体积常常比同长度视频更大，控制在 3–5 秒内
常见问题
压缩会不会转掉音频？ 默认会重新编码音频为 AAC。如果你要的是完全去掉声音，用去音轨工具更直接，也更快。
为什么进度条卡在某个百分比不动？ FFmpeg 的进度是按已处理时长估算的，遇到复杂片段会明显变慢。只要页面没报错就是还在跑，此时切换标签页可能让浏览器降低该页优先级，建议保持在前台。
能压 HEVC（H.265）吗？ 浏览器端的 ffmpeg.wasm 对 H.265 编码支持有限，且编码速度慢得多。建议统一输出 H.264，兼容性最好，几乎所有设备和平台都认。
处理完的文件在哪？ 在你的设备上生成后直接触发下载，全程没有经过任何服务器。