整个页面只有一条公式

视频文件之所以有大小，是因为它每一秒都要写下固定数量的位。码率就是「每秒多少位」， 于是体积的算法朴素得让人意外：

文件体积（字节）=（视频码率 + 音频码率，单位 bps）× 时长（秒）÷ 8

除以 8 是因为码率论「位（bit）」，文件体积论「字节（byte）」，一个字节八位。 页面上的三个模式不是三条公式，而是同一条式子换了个未知数： 已知码率和时长求体积、已知体积和时长求码率、已知码率和体积求时长。 这也是为什么你可以拿模式二算出来的码率填回模式一验算，结果一定回到原来的目标体积。

还有一个经常被漏掉的加数：音频码率。128 kbps 听起来很小， 但一小时的片子里它就是 57.6 MB（十进制）。做长视频、播客切片、课程录屏时， 音频这块的占比不容忽视，尤其当视频码率本身压得很低的时候。

为什么第一件事是选进制

「我算了 500 MB，导出来 476 MB」是这类计算最常见的困惑，原因几乎总是同一个： MB 这两个字母在不同地方指的不是同一个数。

• 1024 进制（严格写法是 MiB / GiB）：1 MiB = 1024 × 1024 = 1048576 字节。多数操作系统的文件管理器按这个算，但标签仍写作 MB，混淆就是这么来的。
• 1000 进制（MB / GB）：1 MB = 1000000 字节。硬盘标称容量、不少上传限制和网盘配额用这一套。

两者在 M 这一级差 4.86%，到 G 这一级差 7.37%。一个 4 GB 的上传上限， 按哪套读能差出将近 300 MB——足够让一个「明明算好了」的文件被拒。 所以页面把进制做成一个显式开关放在显眼处，算体积时还把两套读数并排列出来， 就是不想让你在这里翻车。

顺带说清另一半：码率的 k 和 M 没有这个问题，一律十进制。 1 Mbps 就是 1000 kbps，不存在 1024 kbps 的说法。混淆只发生在体积这一侧。

三个模式分别在什么时候用

算体积——最常用。你已经在导出设置里定好了码率，想知道成片会有多大， 够不够塞进邮件附件、网盘配额或者一张卡。页面顺手给出每分钟、每小时的占用， 方便你估长片或者估一整天的录制。

算码率——有硬性体积上限的时候。比如「这段 12 分钟的片子必须压到 200 MB 以内」， 把目标体积和时长填进去，页面先扣掉音频占用，剩下的就是留给视频的码率预算。 注意这是上界：实际设置时通常会再留一点余量，因为容器封装和可变码率的浮动都会往上顶一点。

算时长——录制场景。手上有 64 GB 卡或者 10 GB 的剩余磁盘， 按当前码率能连续录多久？屏幕录制、直播落地、监控留存都属于这一类。 算出来的数字建议再打个折用，因为录制软件通常还要写临时文件。

预设按钮该怎么看

页面提供了 1080p30、1080p60、4K30、竖屏 1080×1920 四个快速填充按钮。 必须说明白：这些是通用经验档位，只用来省下敲数字的功夫，不是任何平台的官方要求， 也不构成画质承诺。

真正决定该用多少码率的是三样东西：编码器（H.264 要的码率明显高于 H.265 和 AV1）、 素材本身的运动量和噪点（一段风吹树叶的空镜比一段 PPT 讲解难压得多）、 以及你的交付目标。这三样这个页面一个都不知道，所以它不会、也不该告诉你「这样导会不会糊」。 想验证只有一个办法：截取最难的那十几秒，用两三个码率各导一遍，放大了对比。

它算不了什么

第一，这是恒定码率（CBR）下的理论值。 现在大多数人其实用的是可变码率或 CRF 质量优先模式，编码器按画面复杂度动态分配位， 静态段省、运动段费。这种情况下本页的数字更适合当参考上界， 真实体积通常比它小，具体小多少取决于素材。

第二，没算容器和附加轨道的开销。 MP4 / MKV 的封装结构、字幕轨、第二条音轨、章节信息都会占地方。 量不大，但在卡着上限的时候会成为压垮的最后一根稻草，留 2%~3% 余量比较稳妥。

第三，不做任何画质与合规判断。 它不知道你的显卡编码器质量如何，不知道目标平台会不会二次转码， 也不知道你的片子过不过审。这些都需要具体核实，页面上一个字都不会替你猜。

做视频相关的工具链选型时，可以顺带看看OpenCut 专题， 那里整理了开源视频编辑方向的现状。想找站内其他算术工具， 都在计算器总览页上。