从视频里截帧与做 GIF：分辨率、批量间隔，以及那个固定的 10 fps

视频更新于 2026-09-29

从视频里取静帧，和把一小段做成动图，是两个不同的活，但人们总以为它们表现一致。它们不。视频截图按原始分辨率抓单帧，视频转 GIF 把一段时间重编码成动画。两者都完全在浏览器里跑，没有服务端转码。

截帧工具在做什么

它的机制是把视频播进一块离屏画布、再把像素抄出来——和给正在播放的视频截屏是同一件事，只不过驱动它的是解码器，而不是你的显示器。

由此有两条后果：

拿到的是视频自己的分辨率，不是播放器窗口的。 1080p 的源就给你 1080p 的 PNG，哪怕页面上那个预览框很小。你也拿不到比文件里更多的细节，这里没有任何放大步骤来假装做得到。

你拿到的是解码器在该时间点产出的那一帧。 多数 MP4 与 WebM 下，它和你看到的一致。但可变帧率的素材——屏幕录制和手机视频尤其——在精确时间点抓到的帧，可能比你盯住的那一帧早一点或晚一点。要卡某个具体瞬间，挪一下播放头连拍两三张：花几秒，比猜便宜。

输出是 PNG 或 JPEG，用单选按钮切换，默认 PNG。JPEG 的编码质量固定在 0.92——不错，但不可调。凡是带文字、运动模糊或硬边缘的画面，请留在 PNG：文件更大，但编码器不会替你做块决策再多添东西。

单张下载的文件名带着时间戳——一个墙上时间戳加帧位置，形如 capture_20260929_114207_00-12-34.png——一叠静帧不用改名也知道顺序。

批量截图

设一个间隔，工具就把播放头往前推、每到一处截一张。输入框标注 0.5 到 60 秒，但只有下限是真的被校验的：手动敲进去的 120 会被照用不误，于是"间隔比片子还长"只会得到一帧就结束了，不会报错。

请按帧数来规划，而不是"多截点更保险"。90 秒的片子按 0.5 秒间隔是 180 张，每张都是原始分辨率的 PNG——几百 MB 的画布工作，外加一个你得翻半天才筛完的 ZIP。建议从 2 秒起步，扫一眼相册，再对你真正要的那段收紧间隔重跑一次。

一个要留意的行为：批量循环会等跳转完成，并额外挂了一个超时作为保险。在慢速或高关键帧密度的文件上，两者可能都触发，于是相册里偶尔出现几乎重复的相邻帧。导出前扫一眼——事后再去重比这难受得多。

截下的图在页面里累积成相册。全部下载会把它们放进 ZIP 内一个名为 screenshots 的文件夹，压缩包文件名带日期时间，形如 screenshots_2026-09-29-11-42-07.zip。打包这一步用的脚本来自 CDN，所以批量下载需要联网——尽管你的视频本身仍然一点都没离开这台机器。

一次页面加载只能处理一个视频

文件一载入，投放区就消失且不再回来。要换第二个片子，刷新页面。文件打不开时也该这么处理：这个页面没有解码失败的提示，不支持的容器表现就是"什么都没发生"——视频区域一片空白，也不会有任何报错。如果某个文件拒绝加载，先怀疑编码（非苹果浏览器上的 HEVC/H.265 in MP4 是最常见的那个），而不是怀疑工具。

转 GIF：几个写死的选择

输入是起始时间、持续时间和宽度，输出是这段时间的动画。

硬性边界：

时长上限 30 秒。 超过就在动手之前明确拒绝（提示「持续时间不能超过 30 秒」）。默认是 3 秒。
帧率固定 10 fps，界面里没有对应控件。这个工具产出的每一张 GIF 都是 10 帧每秒。这是一个刻意的取舍：GIF 每帧都存成一张完整图像，10 fps 能让几秒的动作保持在"发得出去"的体积上。代价是快速运动会看出频闪，缓慢细微的动作会略显卡顿。
宽度归你，80 到 1920 像素，默认 320；高度按源比例缩放。
编码器跑两个 worker、quality 取 10，两个值都写死在代码里，界面上都调不了。

两个实际会碰到的怪处：

进度条会走两遍。 一根条被两个阶段共用：先是「生成 GIF（n/总数）」，接着是「编码 GIF…」。进入编码时填充宽度会重来，所以百分比在跑到一半时会往回退一次。这只是显示问题，任务并没有重新开始。

输出文件名永远不变。 无论输入什么，你拿到的都叫 video-to-gif.gif，做了几张就得自己改名。成品只活在页面内存里，不下载就没了，刷新即丢失。在禁止程序化下载的浏览器上，页面给了两条退路：右键预览图另存为，或者把界面上那个只读文本域里的 base64 复制出去。

为什么你的 GIF 有 12 MB，该先砍哪一刀

GIF 是 256 色、几乎没有高效压缩的格式，它不做帧间补偿，所以每一帧都要付出一整张图的代价。体积大致正比于宽 × 高 × 帧数 × 色彩复杂度，这也就给出了下手顺序：

先砍时长。 这是最便宜的收益——用 3 秒而不是 8 秒，减掉一半以上体积，而多数"表情包"用途几乎看不出损失。
再砍宽度。 聊天与社交嵌入的甜区是 320–480 像素；宽度减半省下的字节，比任何质量微调都多。
挑动作少的片段。 每帧变化大的片段比半静止的片段贵得多。取能读懂的最小窗口。

把宽度拉到 1920 技术上允许，实践中很少明智——你会得到一个哪儿也发不出去的包。

如果"无声循环"这个形式本身不是目的，一段 WebM 或 MP4 更小也更好，但那是另一个编码活，这两个工具不做。而同一支视频只要你想要静帧，请走视频截图：一张 PNG 胜过五帧同一个静止画面。

隐私

两个页面都在本地读取文件、在标签页内解码，交给你一个可直接下载的成品。不上传、不排队、服务器上没有副本——这也正是为什么这两个工具的可播范围等于你浏览器解码器的能力，而不等于本站的能力。页面照例加载站内统计与广告脚本。需要如实说明的一处外部依赖：截帧的打包下载与 GIF 编码器都来自 CDN，所以这两页的最后一步需要联网。