视频帧数计算器
为 AI 视频换算帧数、帧率和时长
本页这个帧数计算器面向 AI 视频与动画制作流程,用来在帧数、帧率和片段时长这三项之间进行换算。你只要填入其中任意两个值,剩下的第三个就会立刻计算出来,计算依据是 Wan、AnimateDiff、ComfyUI 的视频节点以及 Stable Video Diffusion 共同遵循的(帧数 - 1)/ 帧率这条惯例。
开源视频模型在思考方式上以帧为单位,而不是以秒为单位。Wan 2.x 在 16 fps 下生成 81 帧,AnimateDiff 工作在 16 帧的上下文里,而 ComfyUI 的批量数对应的就是原始的帧数。电影人则习惯按秒和时间线帧率来思考。本页这个计算器的作用就是在两者之间做翻译,下面的补帧面板还会进一步告诉你,RIFE 或 FILM 在走向 24 fps 时间线的路上,对你的帧数和帧率究竟做了什么。
这个工具全部在你的浏览器里运行。你填入的任何内容都只留在本地,不会被发送到服务器。
你的换算结果
5 秒
帧数:81
帧率:16 fps
时长:5 秒
如果直接用帧数除以帧率,得到的结果是 5.063 秒。但可播放的时长实际跨越的是「帧数 - 1」个间隔,这也正是生成出来的片段会比简单除法算出来的结果短一个帧间隔的原因。
补帧
RIFE、FILM 这类补帧工具会在不改变时长的前提下把帧率翻倍:每个帧间隔里都插进新的中间帧。
输出帧率:32
输出帧数:161
时长:5 秒(不变)
计算时使用这个关系:时长 =(帧数 - 1)/ 帧率 | 输出帧率 = 帧率 x 倍数 | 输出帧数 =(帧数 - 1)x 倍数 + 1
目标:24 fps 时间线
以 16 fps 为起点来看,想要精确保持原来的时长,补帧倍数应该是 1.5 倍,这样能得到 24 fps 下的 121 帧,播放时长仍然是 5 秒。若使用的补帧工具只支持整数倍,可以先用 3 倍补到 48 fps,再按 2 比 1 丢帧,或者在剪辑软件里把帧率降到 24。
如果不做补帧,而是把原始帧直接按 24 fps 播放,片段就会从 5 秒缩短到 3.333 秒,时长损失 33.3%。正是这个由帧率换算带来的偏差,让直接扔进 24 fps 时间线的 AI 片段显得像是被加速了。
帧数参考表
常见片段时长对应的帧数,用的是「帧数 = 时长 x 帧率 + 1」。
| 片段时长 | 8 fps | 12 fps | 16 fps | 24 fps | 25 fps | 30 fps | 60 fps |
|---|---|---|---|---|---|---|---|
| 2 秒 | 17 | 25 | 33 | 49 | 51 | 61 | 121 |
| 4 秒 | 33 | 49 | 65 | 97 | 101 | 121 | 241 |
| 5 秒 | 41 | 61 | 81 | 121 | 126 | 151 | 301 |
| 8 秒 | 65 | 97 | 129 | 193 | 201 | 241 | 481 |
| 10 秒 | 81 | 121 | 161 | 241 | 251 | 301 | 601 |
工作原理
在选定要求解的目标值、再填入另外两个已知量之后,计算器就会套用「时长 =(帧数 - 1)/ 帧率」这个公式。公式里的减一很关键:一个片段可播放的长度,是第一帧和最后一帧时间戳之间的那段时间,所以 N 帧只跨 N - 1 个间隔。这就是为什么 Wan 在 16 fps 下用 81 帧给出一个 5 秒片段,也是为什么 AnimateDiff 的渲染结果,会比帧数除以帧率略短一点。补帧面板套用的是「输出帧率 = 帧率 x 倍数」和「输出帧数 =(帧数 - 1)x 倍数 + 1」,也就是 ComfyUI 里 RIFE 和 FILM 节点用的那套算术。
5 秒视频是多少帧?
这完全取决于帧率。五秒在 16 fps 下是 81 帧,在 24 fps 下是 121 帧,在 30 fps 下是 151 帧,每一个都含末尾那一帧。一个从帧数到秒的计算器,只有在你知道自己的模型以什么帧率生成时,才给得出有用的答案:Wan 默认 16 fps,AnimateDiff 的流程常见在 8 到 16 fps,Stable Video Diffusion 则按设置在 6 到 14 fps 之间输出短爆发。
帧率和帧数之间的关系,不只影响画面节奏,也同样支配着 AI 视频的预算算术。ComfyUI 里的时长并不是按秒直接设定,而是按帧来设定的,而每多增加一帧,都要额外消耗显存和生成时间,因此当你知道「16 fps 下的 5 秒片段需要 81 帧」时,就等于知道该在时长框里填写什么数字,也等于在把任务排进队列之前,提前知道它会花掉多少成本。
把 AI 的产出放到剪辑时间线上,是另外一半需要完成的功课。剪辑师通常在 24、25 或 30 fps 下剪片,而一段 16 fps 的生成结果直接扔进 24 fps 的时间线时,要么会播得短了三分之一,要么会因为混合帧而出现抖动。补帧是那个成本更低的解法:做 1.5 倍的一遍补帧,能把 16 fps 精确带到 24,而用 3 倍补帧到 48 fps,再按 2 比 1 丢帧之后,能给出干净的 24 fps,同时还白送你一个 2 倍慢动作的选项。
适合谁
- 用 AI 做电影的人 在花掉 GPU 时间之前,把按秒衡量的镜头表换算成 Wan、AnimateDiff 或 ComfyUI 真正要的帧数。
- 剪辑师 算出那个能把生成素材落到 24 或 30 fps 时间线上、既不抖动也不会被意外变速的补帧倍数。
- 动画师 按 8 或 12 fps(一拍二)规划动画,并清楚每种片段时长对应的确切帧数预算。
从剧本出发,直接得到分镜。
熙熙 把你的剧本拆成镜头,并据此生成分镜。景别、角度、运镜和时长都由你掌控。角色在镜头之间保持一致。
- 0 美元,永不过期
- 导出 PDF 和 Final Draft
- Mac、Windows、Linux、iPad

视频帧数计算器:完整指南
它用(帧数 - 1)/ 帧率这个惯例,从三个值里的任意两个推出第三个,并且模拟插帧,让你在跑 RIFE 或 FILM 之前就知道输出的帧率和帧数。
这类工作的核心问题其实很清楚:开源视频模型是按帧来计量片段的,而创作者是按秒来规划内容的,并且(帧数 - 1)/ 帧率这个惯例,会让那些想当然的换算直接算错。如果不解决这个问题,它就会在后面的环节里制造摩擦,让决策速度变慢。实际要达到的目标,是得到精确的帧数、帧率和时长,让它们既对得上模型实际生成的东西,也对得上时间线的预期。
需要记住的限制如下:除了文档里已经记下的内容之外,它无从知道某个模型自身的帧数约束(比如 Wan 的 4n+1 步长),也不会预测导出之后编码器的行为;因此最终时长请你在剪辑软件里亲自核对。
进阶用法:有经验的团队会给整个项目锁定一个生成帧率,把每个镜头的帧数写进镜头表,并用同一个倍数跑完所有插帧,这样每一段素材落到时间线上的方式都一致。
一步步怎么做
- 选择要求解的值,输入已知的两个:模型那边通常给你帧数和帧率,故事板那边通常给你秒数。
- 用帧率快捷按钮对齐你模型的原生帧率(Wan 用 16,AnimateDiff 用 8 到 16),不要靠猜。
- 在生成任何东西之前,先跑一遍插帧面板,规划好从生成帧率到时间线帧率的路径。
- 把结果复制进镜头表,帧数预算才能一路留到剪辑和成本估算阶段。
按角色分的使用场景
- AI 影像创作者:把一个 6 秒的镜头换算成确切帧数,填进 ComfyUI 的时长字段再排队。
- 剪辑师:挑一个插帧倍数,把 16 帧率的生成结果放进 24 帧率的时间线,而不留下变速痕迹。
- 动画师:为 12 帧率的动画流程做帧数预算,知道每多一秒的代价。
常见的坑
- 直接用帧数除以帧率,然后纳闷为什么每段素材都比预期短了一个间隔。
- 把 16 帧率的生成结果直接扔进 24 帧率的时间线,然后交付了由此产生的卡顿或加速。
- 无视模型的步长约束,去要一个它会悄悄取整的帧数。
行业里的做法
- 把这几个锚点记熟:16 帧率下 81 帧是 5 秒,24 帧率下 121 帧是 5 秒。
- 在调色和加颗粒之前先插帧;插帧算法在干净的帧上表现更好。
- 当模型限制帧数时(Wan 的 4n+1),取最接近的合法值,然后在这里重新算出真实时长。
请把这个工具的输出当成决策时的辅助,而不是把它当成写作本身的替代。一个好剧本之所以被记住,靠的是具体的选择、准确的情绪,以及戏剧动作的清晰。工具的作用是把噪音去掉,让你的精力落到真正要紧的地方,也就是人物、冲突、升级和兑现。每过一轮就回看一次结果,并把接受的改动记下来,你的工作方式就会一稿比一稿更快、更可预期。这种稳定正是专业合作者看重的东西:意外更少,理由更清楚,剧本也会朝着有意识的方向生长。
延伸问答
帧数计算器用的是什么公式
时长 =(帧数 - 1)/ 帧率。减一是因为 N 帧覆盖的是 N - 1 个可播放的间隔。反过来算就是:时长 × 帧率 + 1。
Wan 为什么生成 81 帧
Wan 2.x 的原生输出帧率是 16 帧率,如果要生成一个目标时长为 5 秒的片段,帧数的算法是 5 × 16 + 1 = 81。除此之外,这个模型对帧数的取值还有偏好,倾向于 4n+1 这种形式,而 81 恰好同时满足原生 16 帧率下 5 秒时长和 4n+1 这两个条件。
AnimateDiff 用什么帧率
AnimateDiff 的运动模块在训练时是围绕 8 到 16 帧率的上下文窗口来做的,因此大多数工作流会选择在 8、12 或 16 帧率下完成渲染,等到交付环节再通过插帧的方式把帧率提高。
该直接生成 24 帧率还是插帧上去
同样时长下,24 帧率生成比 16 帧率多花 50% 的帧。大多数工作流按模型原生帧率生成再插帧,把原生 24 帧率留给运动快、插帧痕迹看得见的镜头。
帧数怎么影响显存和生成时间
帧率对时间的影响接近线性,但对显存的影响很大,原因在于视频模型需要跨帧进行注意力计算。在时长不变的前提下把帧率减半,帧数预算也跟着减半,这也是先按 16 帧率生成、再插帧会成为默认省钱做法的主要原因。
最终该按什么帧率导出
按你的交付目标:电影感用 24 帧率,PAL 制播出用 25,社交媒体和录屏用 30 或 60。先定目标,再倒推生成帧率和插帧倍数。
常见问题
原因在于时长的计算方式是(帧数 - 1)/ 帧率,而不是帧数 / 帧率。一个片段真正可播放的长度跨越的是帧与帧之间的间隔,而 N 帧只对应 N - 1 个间隔。所以 16 fps 下的 81 帧片段算出来正好是 5.0 秒,而不是 5.06 秒。
81 帧是这么来的:5 x 16 = 80 个间隔,再加上末尾那一帧,合计 81 帧。这正是 Wan 的默认输出设定为 81 帧的原因,它在原生的 16 fps 下解码出来就是一个 5 秒片段。
假如你手上的补帧工具支持小数倍,那就直接按 1.5 倍来做补帧,补完之后时长完全不变。要是补帧工具只认整数倍,那就先用 3 倍把素材补到 48 fps,再隔一帧丢一帧把帧数降回来;或者干脆按 48 fps 导出,交给剪辑软件去做归一处理。千万别只做变速:把 16 fps 的帧按 24 fps 播放,时长会被砍掉三分之一。
计算方式是把目标秒数乘以你的输出帧率,然后再加 1。同样是 4 秒的片段,在 16 fps 下是 65 帧,在 24 fps 下则是 97 帧。另外,有些节点还会把帧数限制在模型特定的步长上(比如 Wan 用的就是 81 这种 4n+1 的值),所以请就近取到合法的数值。
不会。补帧做的事情是往每一个已有的帧间隔里填进新的中间帧,因此对 16 fps 下的 81 帧做一次 2 倍补帧,得到的是 32 fps 下的 161 帧,时长仍然是 5 秒。只有当你之后又去变速、做速度斜坡或者丢帧的时候,时长才会发生变化。



