先找到那个瞬间，再谈转换
最常见的错误是先把整段转完再裁。先拖动播放头找到入点和出点，然后才抽帧。后面每一步都会变便宜。
三秒是个好目标，更短通常更好。GIF 是循环的，观众会反复看到这个瞬间；两端留白的片段第二遍就开始显得拖沓。切进动作里，也从动作里切出来。
视频
视频转 GIF 完整教程
把视频转成 GIF，主要是在按正确的顺序扔东西：秒、帧、像素，然后才是颜色。顺序对了，十分钟的录像会变成三秒的清晰循环；顺序错了，你会得到一个糊掉的 8MB 文件。
2026 年 9 月 12 日 · 约 8 分钟
帧到底是怎么从视频文件里出来的
浏览器不会直接把 MP4 的"第 147 帧"交给你。它能做的是把 video 元素跳到某个时间点，然后让你复制它显示的内容。抽帧就是"跳转、等它稳定、抓取、再来一遍"的循环。
WebCodecs 更快，但它要求你自己拆容器，而容器里那些编码格式的支持情况又因浏览器和平台而异。跳转抓帧在哪儿都能用。当另一条路的代价是转换直接失败时，通用性胜过速度。
这也是为什么长片段抽帧比你想的慢：每一帧都是一次真实的跳转。先裁剪不只是为了体积——它省下的是绝大部分等待时间。
选择采样频率
采样频率和源视频的帧率没有关系。你要的是均匀分布的时间点，一秒要两个还是三十个都行。
对大多数录屏来说，12.5fps 在聊天窗口里循环起来和原速几乎分不出。手部动作和快切需要 20–25。超过 25，你就是在按线性代价为 GIF 尺寸下眼睛根本分辨不出的帧付费。
尺寸，以及平台会对它做什么
按它将要被显示的尺寸导出，而不是录制时的尺寸。一段 1080p 的录屏要放在 600px 宽的栏里，就该按 600px 导出；多出来的都是花在没人看得见的像素上。
有些平台会对你上传的内容重新编码。部分社交平台会在接收时把 GIF 转成 MP4，也就是说你精心调过的颜色削减会被扔掉再压一遍，而且常常肉眼可见。如果平台直接收视频，上传 MP4 就完全避开了这趟往返，效果还更好。
| 平台 | 处理方式 |
|---|---|
| 社交平台（如 X） | 服务端转成 MP4 |
| Slack、Discord | 原样提供，内联播放 |
| GitHub README | 原样提供，内联播放 |
| 邮件客户端 | 各不相同；很多只显示第一帧 |
颜色、抖动，以及动它们的顺序
实拍视频通常需要 128 色加误差扩散抖动，才能让渐变不出现断层。录屏正相反：它大部分是平坦的，32–64 色、关掉抖动，既更小也更干净。
这些留到最后。把帧率或宽度减半，永远比削减颜色走得更远，而削减颜色是人们最容易察觉的那根杠杆。
音频，以及时间轴为什么不允许它
GIF 没有音轨，所以对 GIF 而言这个问题不存在。对 MP4 和 WebM 导出来说技术上可行——但仍然不提供。
原因在时间轴。片段可以重排、倒放、加速、改时长，没有诚实的办法让声音穿过这些操作还保持同步。一个只在"单片段、1× 正放"时才正确的音频通道比没有更糟，因为它恰好会在人们依赖它的那些情况下无声地出错。
打不开的文件
容器不等于编码。MOV 是容器；里面的 ProRes 才是你的浏览器解不了的东西。MP4 外壳里装的某些手机录制的 HEVC 也一样——扩展名看着没问题，文件还是播不了。
重新编码成 MP4 容器里的 H.264 能解决其中绝大部分。另外值得确认文件没有 DRM 保护，那种情况无论什么编码浏览器都不会解。