视频压缩计算器

算出一个体积上限给你留下多少余量，或者一个分辨率要花多少体积。码率是精确算术，分辨率结论是推荐值——这一页把两者分开，然后告诉你在那个码率上，我们在三类 1080p 素材上实测到了什么。

秒
MB
总码率
3,425 kbps
精确值
留给视频
3,297 kbps
已扣除 128 kbps 音频
在 1080p 下
能看但偏软
推荐值

25 MB 摊到 1 分钟，留给视频 3,297 kbps。 能达到舒适阈值的最高分辨率是 720p。 1080p 是仍然能看的最高档。

25 MB 能过哪些上限

  • WhatsApp Video in chat (mobile) 16 MB
  • Gmail 实际可用 18 MB· base64 约 +37%
  • Discord Free 20 MB
  • Gmail 25 MB
  • TikTok Android app 72 MB
  • X (Twitter) Standard 512 MB

这个码率上我们实测到了什么

来自我们自己的编码，1080p、libx264 preset medium，测量于 2026-09-06。每类内容只有一个片段，所以请把这些数字当作相对位置而不是误差范围——有价值的是它们之间的差距，而不是单个数值。

  • Screen recording
    ≥ 96.74VMAF
    高于我们在这类内容上测过的所有码率（最高一档是 1,750 kbps → 96.74）；未做外推
  • Animation
    89.1VMAF
    介于实测的 2,840 kbps → 87.85 与 3,793 kbps → 90.51 之间
  • Camera footage
    85VMAF
    介于实测的 3,161 kbps → 84.36 与 3,991 kbps → 88.15 之间

算术本身

给定体积和时长，答案只有一个，而且它是硬上限而不是意见。计算器里标注为“精确值”的部分全部来自下面这两行。

total kbps  = size_MiB × 8,388,608 × 0.98 ÷ seconds ÷ 1,000
video kbps  = total kbps − audio kbps
  • 8,388,608 是每 mebibyte 的比特数。上传限制实际是按 mebibyte 执行却被叫做 megabyte，所以用 1,000,000 去算，得到的目标会比真正被执行的那个大约 5%。
  • 0.98 预留容器和封装开销。MP4 大约占 1–2%，这里按偏悲观的一端留——需要避免的失败是刚好超过硬上限。
  • 128 kbps 是默认的音频假设，即画质合理的立体声 AAC。语音在低于约 96 kbps 之后会开始变单薄。

分辨率阈值是怎么来的

这些是计算器用来对照你的预算的数字。它们是推荐值，不是实测值：来自公开的 H.264 码率阶梯——YouTube 的推荐上传码率和 Apple 的 HLS 制作规范——并整体下调了约三分之一。那些阶梯描述的是对干净母版做第一次编码，而压缩一个已有的 MP4 是从已经经过一次有损编码的素材开始的，比母版更能承受较低的码率。刻意保守：我们真正在意的失败是告诉别人画质没问题，而实际上有问题。

30 fps 下各分辨率的 H.264 码率阈值
分辨率舒适能看
4K20,000 kbps12,000 kbps
1440p9,000 kbps5,500 kbps
1080p4,000 kbps2,000 kbps
720p2,200 kbps1,100 kbps
480p1,000 kbps500 kbps
360p600 kbps300 kbps

以 30 fps 为准。同分辨率的 60 fps 片段需要更多码率；而降帧率通常是错的那个杠杆——代价落在运动上，而观众对运动最敏感。

我们实测了什么，以及为什么单一码率无法服务所有人

18 次编码：三类 1080p 素材，每类六个画质档，libx264 preset medium，每一次都对原片打了 VMAF。测量于 2026-09-06。它出现在这一页的理由是离散度——同一个码率下，三类内容落在完全不同的位置，所以只给出一个结论的计算器，最多只对其中一类说了真话。

Screen recording

实测区间 664–1,750 kbps

  • 1,750 kbps96.74
  • 1,507 kbps96.19
  • 1,244 kbps95.49
  • 1,012 kbps94.16
  • 887 kbps93.23
  • 664 kbps89.88

Animation

实测区间 1,646–13,021 kbps

  • 13,021 kbps96.02
  • 9,550 kbps95.1
  • 5,970 kbps93.3
  • 3,793 kbps90.51
  • 2,840 kbps87.85
  • 1,646 kbps79.67

Camera footage

实测区间 2,036–10,673 kbps

  • 10,673 kbps97.18
  • 8,261 kbps95.6
  • 5,705 kbps92.48
  • 3,991 kbps88.15
  • 3,161 kbps84.36
  • 2,036 kbps74.38

这份数据不覆盖什么，以免有人在上面搭建结论：每类内容只有一个片段、各 10 秒、全部 1080p、全部 H.264。足以说明三类内容位置完全不同，但不足以给任何单个数字标注公差，也完全没有涉及 H.265。计算器在这些点之间插值，并拒绝向外推。

速查表

常见体积 × 常见时长下，能达到舒适阈值的最高分辨率。假设音频为 128 kbps。这就是计算器对最常被问到的那些组合给出的答案，预先算好了。

按目标体积与片段时长列出的最佳舒适分辨率
体积15s30s1 min2 min5 min10 min
8 MB1080p480p360p———
10 MB1080p720p480p———
16 MB1080p1080p480p360p——
25 MB1440p1080p720p480p——
50 MB4K1440p1080p720p480p—
100 MB4K4K1440p1080p720p480p
200 MB4K4K4K1440p1080p720p

横线表示该组合下阶梯上没有任何分辨率能达到舒适阈值——片段对这个体积来说太长了。剪短它，或者接受偏软的结果。

关于计算器的问题

目标体积对应的码率怎么算？

把体积（mebibyte）乘以 8,388,608 得到比特数，除以时长（秒），再除以 1,000 得到 kbps。减去音频码率就是留给视频的部分，再扣掉约 2% 的容器开销。整个计算就是这些，而且答案只有一个——判断是从“这个码率够不够”那一刻才开始的。

分辨率推荐是实测还是估算？

是估算，并且全程标注为估算。阈值来自公开的 H.264 码率阶梯——YouTube 的推荐上传码率和 Apple 的 HLS 制作规范——整体下调约三分之一，因为那些阶梯描述的是对干净母版做第一次编码，而压缩一个已有的 MP4 是从已经经过一次有损编码的素材开始的。这一页上的码率数字是算术，通过/不通过的结论是推荐。

为什么同一个码率在一个视频上没问题，在另一个上很糟？

因为内容决定一个码率能走多远。我们对三类 1080p 素材各跑了六个画质档，对全部 18 次编码打了 VMAF：在 3,300 kbps 附近，录屏高于我们为它测过的所有码率，动画落在 89 左右，手持实拍在 85 左右。到区间底部，差距会拉开到十五分以上。单一推荐码率无法同时服务这三类，所以这一页把三类都列出来。

该降分辨率还是降画质设置？

几乎总是降分辨率，而且要比直觉更早降。因为像素数是二维的，720p 只需要 1080p 约 44% 的像素，所以降一档带来的收益远大于继续压画质设置——而且不会带来过度压缩产生的块状和拖影。让分辨率匹配视频真正会被观看的场合，然后再调画质。

音轨要紧吗？

短片段上很要紧。一个 15 秒、限制 2 MB 的视频总共只有约 1,090 kbps 可用；128 kbps 的立体声音轨在第一帧之前就吃掉了将近 12%。超过一分钟之后它就接近舍入误差了。如果片段没有解说，检查一下它是不是正扛着一条完整的立体声静音轨——去掉它是免费的。

为什么 1 MB 是 1,048,576 字节而不是 1,000,000？

因为上传限制就是按这个执行的。平台和操作系统绝大多数按 mebibyte 计量却称之为 megabyte，所以用 1,000,000 的计算器会报出一个比实际被执行的上限大约 5% 的目标——而那恰好就是让上传在“符合标示上限”的情况下失败的那点余量。

这些数字背后的实测

不想自己算

这些页面已经把答案算好、压缩器也已按对应数值预设，覆盖大家最常碰到的那些数字。