先缩分辨率，再动 CRF
从 1080p 降到 720p 往往比把 CRF 拉高更划算，观感也更自然
调 CRF、缩分辨率、降帧率，浏览器本地压缩并实时显示进度。压完直接看前后体积与压缩率。环境支持时输出 MP4，不支持时自动降级为 WebM，页面会如实标注。
文件不上传服务器，压缩全部在本地浏览器处理，断网也能用（首次需加载 ffmpeg CDN 内核，约 30MB）
| 参数区间 | 观感 | 适用场景 |
|---|---|---|
| CRF 18 - 22 | 接近视觉无损 | 体积通常仍有 30% - 60% 下降，适合存档 |
| CRF 24 - 28 | 画质与体积平衡 | 大多数聊天、网课、分享场景的推荐区间 |
| CRF 30 - 35 | 明显可见压缩痕迹 | 只在体积硬性受限时使用，暗部与快速运动会糊 |
| 缩到 720p | 体积下降最明显 | 手机观看足够；大屏观看会明显变软 |
| 抽帧到 15fps | 体积再降一档 | 动作片、游戏录屏会卡顿，讲课类可用 |
从 1080p 降到 720p 往往比把 CRF 拉高更划算，观感也更自然
目标体积取决于时长：10 秒和 10 分钟想压到同一体积，画质天差地别
PPT、讲课、代码演示内容变化慢，15 - 24fps 足够，能省一大截
压缩是有损不可逆的，任何一次覆盖式保存都可能让你失去高质量版本
ffmpeg.wasm 需要 SharedArrayBuffer；不满足时本工具自动改用录制方案
微信对文件体积有限制，先缩到 720p + CRF 28 再发
多数邮箱单附件 25MB 左右，短视频压到 20MB 以内最稳妥
内容变化慢，降帧率 + 720p 即可，体积能降一半以上
网页视频越小加载越快，480p + 低帧率足够当示意
| CRF 是什么 | 恒定质量参数，数值越小画质越好、体积越大；18 接近无损，35 已明显失真 |
|---|---|
| 分辨率优先 | 长边缩到 1080/720/480，体积按面积近似平方下降，通常比硬拉 CRF 更划算 |
| 帧率的影响 | 帧率减半约等于运动信息减半；静态内容降帧几乎无损，快速运动降帧会卡顿 |
| 为什么需要 SharedArrayBuffer | ffmpeg.wasm 新版多线程内核依赖它，要求页面处于 crossOriginIsolated 状态 |
| 降级方案是什么 | 不满足隔离条件时，改用 canvas 逐帧绘制 + MediaRecorder 录制，输出 webm 而非 mp4 |
| 能压多大 | 浏览器内存有限，建议单文件 300MB 以内；超大可先裁剪或分段处理 |
视频太大，先别急着找会员。这个页面把压缩放在你的浏览器里：调 CRF、缩分辨率、降帧率，实时看进度，压完直接对比前后体积。环境支持时用 ffmpeg.wasm 输出 MP4；不支持时自动降级为 canvas + MediaRecorder 输出 WebM，并在界面上如实标注。
压缩耗时与视频时长、分辨率强相关，可能达到原片时长的数倍。首次使用还需下载约 30MB 的 ffmpeg 内核，请保持页面在前台并留出足够时间。
不会。压缩全部在浏览器内完成，视频不出本机；只有 ffmpeg 程序文件从 CDN 下载。
当页面没有 SharedArrayBuffer 隔离环境时，ffmpeg.wasm 无法运行，工具会自动改用 canvas + MediaRecorder 录制，浏览器原生只稳定支持 WebM。
分享用 24 - 28，存档用 18 - 22，体积硬性受限才用 30 以上。数值越小体积越大。
原片本身码率就低、时长又短时，可压缩空间有限。此时优先降低分辨率或帧率，而不是继续拉高 CRF。
通常为视频时长的 1 - 5 倍，取决于分辨率、设备性能与参数。浏览器需要保持在前台，休眠会中断。
建议 300MB 以内、时长 10 分钟以内。浏览器内存有限，超大文件容易失败，可先裁剪分段。
会。所有有损压缩都不可逆，本工具只做一次编码，建议保留原片并只在副本上操作。
审核通过后就会展示在留言板上，稍安勿躁～
数据更新：2026-11-02 · 依赖 ffmpeg.wasm 0.12.10 与 MediaRecorder，均在本机运行。
还没有留言，来抢沙发吧！