视频转 GIF
圈出视频里的一小段转成循环播放的动图，帧率和宽度可以调。全部在浏览器本机编码，视频不会上传。
视频只在这台浏览器里解码和编码，不上传也不联网。能读什么格式取决于浏览器自带的解码器，mp4（H.264）最稳。
GIF 为什么没有声音
GIF 是 1987 年定下来的图像格式，文件结构里只有图像数据块、调色板和每帧的延时时间，没有任何存放音频的字段。所以「视频转 GIF 没声音」不是这一页偷懒，而是格式本身做不到。想要带声音的动图，只能用 mp4、webm 这类视频容器，它们的体积还更小。
为什么体积比 mp4 大得多
两个原因叠加。第一，GIF 每一帧都是独立压缩的整张图片，画面里不动的背景、固定的字幕都要逐帧重存一遍；而 H.264 这类编码只记录帧与帧之间的差异，静止部分几乎不占空间。第二，GIF 用的是 256 色索引加 LZW 压缩，压缩率本来就低。所以同样 5 秒的片段，mp4 常见只有几百 KB，转成 GIF 十几 MB 很平常，只能用「短、小、画面简单」来换体积。
256 色量化为什么会掉色
编码时先把每一帧的真彩色像素统计一遍，用聚类算法挑出最合适的 256 种颜色做成调色板，再把每个像素映射到最接近的那一种——这个过程叫量化。天空、皮肤、渐变背景这类连续过渡的色彩，本来可能有几千种中间色，压到 256 种之后相邻像素的跳跃就看得出来了，表现为一圈一圈的色带。默认给每一帧单独生成调色板，比全片共用一张更准，代价是每帧要多写一份颜色表。
规模限制是怎么定的
编码的全部步骤——按帧定位视频、缩放、量化、压缩——都跑在浏览器的主线程上，这段计算没交还给浏览器之前页面完全动不了。所以这里卡了三道线：单次最多 15 秒（按最高 20 帧每秒算正好 300 帧）、宽度上限 640 像素、调色板固定 256 色。帧数超过 150 帧会先提醒，编码过程中每帧刷新一次进度，让界面不至于像卡死。
想要单张高清画面而不是动图，用视频截图取帧导出无损 PNG；想要的是声音，用视频提取音频把音轨分离出来；生成的 GIF 如果还是太大，可以先用图片压缩压小，需要裁掉多余边缘就用九宫格切图那类工具按比例切分。
常见问题
转出来的 GIF 怎么没有声音？
因为 GIF 格式本身就没有音轨。它是 1987 年定下来的图像格式，文件里只有图像数据块和每帧的延时时间，规范里根本没有存音频的地方，任何软件转出来的 GIF 都是静音的。想要带声音就得用视频格式，比如 mp4 或 webm；需要声音又想要动图效果，可以做成静音动图再配一段音频。
为什么 GIF 比同一段 mp4 大那么多？
两个原因叠加。一是 GIF 每一帧都当成独立图片压缩，画面不动的地方也要重复存一遍，而 H.264 这类编码只记录帧与帧之间的差异；二是 GIF 的颜色表和压缩算法都很原始。同样 5 秒的片段，mp4 常常只有几百 KB，转成 GIF 是十几 MB 很常见，所以 GIF 只适合短、小、画面简单的内容。
转出来的颜色发灰、出现一圈圈断层？
这是 256 色量化的必然结果。GIF 每帧的颜色表最多放 256 种颜色，程序要把几十万种颜色归到最近的 256 种里，天空、肤色、渐变背景就会出现色带。这个上限来自 GIF 格式，任何工具都突破不了。想少掉色可以让画面色彩简单一些，或者干脆改用视频格式。
为什么限制在 15 秒和 640 像素以内？
不限制会把标签页拖死。编码要逐帧缩放、统计颜色、重排调色板，再做 LZW 压缩，全是同步占满主线程的活；15 秒乘 20 帧每秒已经有 300 帧，每帧的原始像素数据都是几百 KB 到一兆多。规模再往上，内存和耗时的增长远快于观感的提升，用户看到的就是页面卡死。
帧率选多少合适？
默认的 12 帧每秒是画面比较顺、体积又不夸张的常用值。低于 8 帧会明显看出卡顿，适合刻意做逐格动画的效果；高于 15 帧对观感提升有限，但帧数变多会让体积接近成正比上涨。另外 GIF 的延时字段以 10 毫秒为单位，帧率其实没法做到任意值，20 帧每秒对应 50 毫秒正好整除。
能只转视频中间的一小段吗？
能。拖动起点和终点滑块圈出需要的区间即可，单次最长 15 秒，超出部分会自动砍掉并在界面上说明。想转更长的内容，要么分几段分别转，要么降低帧率和宽度换回区间——体积大致等于帧数乘每帧的编码大小，砍掉一半帧数就砍掉一半体积。
编码的时候页面为什么一卡一卡的？
因为缩放、颜色量化、压缩都在主线程上跑，浏览器只有一条主线程，它忙起来就没空响应滚动和点击了。工具每处理完一帧会交还一次控制权刷新进度，但单帧本身就要几十到几百毫秒，所以帧数多的时候仍会感觉一顿一顿。关掉其他标签页能让它快一些。