视频压缩到 25MB：微信、邮件、Discord 上限与不糊的压法

你想发一个视频，进度条走到一半停住：「文件过大」。

这大概是网上最常撞到的一堵墙，而绝大多数教程的回答都一样敷衍——「用个压缩工具吧」——既没说该压到多少，也没解释为什么压完之后画面糊成了马赛克。

这篇讲真正要紧的部分：文件体积到底由什么决定、各个平台需要压到多少、以及为什么想压得很小就必须牺牲分辨率，而不只是「质量」。

1. 你实际要对付的那些限制

这张表里有两个特别容易踩的坑：

微信的「25MB」不是死限制。 直接从相册发确实卡 25MB，但改成按「文件」发送，上限直接放宽到 1GB。很多人压了半天视频，其实换个发送方式就解决了——代价是对方收到的是文件而不是可以直接播放的视频。
朋友圈有两道限制。 体积 25MB 之外还有时长 30 秒。只压体积不裁时长，照样发不出去。

搞清这四个，才能从「碰运气」变成「算得出来」：

注意这个列表里没有「质量百分比」。那个滑块只是间接在调码率，这也正是它没法告诉你「压完到底塞不塞得下」的原因。

只需要目标体积和时长两个数：

可用码率 = 目标体积（比特） ÷ 时长（秒）

举个具体的：25MB，10 分钟的视频。

25 MB  = 209,715,200 比特
600 秒 时长
209,715,200 ÷ 600 ≈ 349,000 bps ≈ 349 kbps

再扣掉音频大约 128 kbps，留给画面的只剩约 220 kbps。

这个数字就是全部答案。它真的很少。

这一步是大多数工具跳过的。

220 kbps 摊到 1920×1080、每秒 30 帧的画面上，每个像素分到的数据少得可怜。编码器没有预算去表现细节，只能做它唯一能做的事：在每一块像素里丢掉细节。那就是块效应的来源。

解法反直觉：用更少的像素。 同样是 220 kbps，摊到 426×240 的画面上，每个像素分到的数据大约多二十倍。画面在屏幕上确实变小了，但它是干净的，而不是糊的。

下面是我们的压缩器实际在用的对照表——每种码率真正撑得住的最高分辨率：

视频	目标	可用码率	输出分辨率
30 秒 1080p	25 MB	6653 kbps	1920×1080（不降）
1 分钟 1080p	25 MB	3262 kbps	1280×720
2 分钟 1080p	16 MB	957 kbps	852×480
10 分钟 1080p	25 MB	211 kbps	426×240

10 分钟的视频压到 25MB，结果就是一个 240p 的视频。没有任何工具、任何设置能改变这一点——比特就是不够。声称能做到的，要么在偷偷延长文件，要么在虚报输出。

如果算出来的分辨率低得没法接受，你有三个杠杆——而且都比去找「更好的压缩工具」有效得多：

先裁时长。 时长在分母上。把 10 分钟裁到真正要紧的 3 分钟，可用码率直接涨到三倍多，分辨率就能从 240p 提到 480p 以上。这是收益最大的一步。

降低音频码率，或者干脆去掉音频。 人声在 64 kbps 下已经足够清楚，紧张的目标下这能省出码率给画面；纯画面的片子则能腾出全部 128 kbps。

能放宽目标就放宽。 前面说过，微信改用「文件」发送上限是 1GB。如果对方能接受收文件或者收个链接，这道限制就根本不存在了。

我们的视频压缩工具的入口就是目标体积而不是质量滑块，所以第一次导出就能落在点上：

全程在浏览器里运行，所以既不用等上传，也没有体积上限——服务端压缩工具的讽刺之处恰恰在于，你最需要压的那些大文件，它反而不收。

能不能不掉画质地压缩？ 不能，至少没法有意义地做到。压缩的本质就是丢信息。好工具能做的是把剩下的比特花在最不容易被看出来的地方——这正是「宁可降分辨率」优于「留一张码率不够、满是块效应的高分辨率画面」的原因。

为什么产出比目标略小？ 编码器没法精确命中请求的码率，所以刻意压到比上限低几个百分点。24.6MB 能发出去，25.3MB 不能。

压完反而比原文件还大，怎么回事？ 说明你的源文件本来就压得比目标更狠。一个 5MB 的视频本身已经很高效了，你却要求 25MB，等于允许编码器花更多而不是更少。请选一个小于原文件的目标。

降分辨率和降帧率，该选哪个？ 几乎总是选降分辨率。30fps 降到 15fps 省下的比你想的少（相邻帧本来就很好压），却会让动作明显卡顿。减少像素是更划算的交易。