浏览器端视频抽帧与色度键抠图：绿幕视频转Sprite Sheet实战指南

我做前端动画需求时最烦的一件事，就是手头只有一段视频素材，却要把它变成游戏或网页里能用的序列帧动画。以前的第一反应是打开 Python 写 OpenCV，或者直接甩给 FFmpeg 一段命令行脚本。后来我发现，像“视频转序列帧”这种活，完全可以在浏览器里干完，而且干得相当利索：把一段 8 秒的绿幕视频拖进页面，抽帧、抠图、拼成 sprite sheet，全过程不需要装任何软件，不需要配环境，打开一个网页就能跑通。

这篇文章会把这套浏览器端流程拆开讲清楚。核心就三件事：绿幕视频抽帧得到序列图、色度键抠图得到透明背景、按网格排列拼成雪碧图并输出 PNG。适合 Web 前端开发者、独立游戏制作者，以及所有不想为一次性素材处理去装重型软件的人。我会把每一步的原理、代码和实际踩过的坑都写出来，尤其是一些在文档里很难查到的细节。

1. 为什么我放弃了 Python 和 FFmpeg，选择在浏览器里处理这套流程

先说明一下这套方案的适用范围。如果你要批量处理几百条素材，或者视频时长很长，那浏览器不是最优解，FFmpeg 命令行和 Python 脚本仍然是更高效的工具。但如果你只是处理几段几秒到几十秒的短视频，浏览器方案有它独特的优势。

我把几种方案放在一起对比过，做了个表：

这个对比里最关键的一点是可视化交互。用 Python 处理时，参数调得对不对，通常要等脚本跑完、输出图片之后才能看到结果。如果绿幕的拍摄环境不理想，比如背景偏色、边缘有绿色溢出，你就得反复改参数重跑，时间全耗在等待上了。而浏览器方案里，我可以把相似度阈值、边缘过渡宽度这些参数做成滑块，拖动的同时实时看到当前帧的抠图结果，确认效果没问题再一键跑全量，效率完全不一样。

另一个让我倾向浏览器的原因是隐私和易用性。视频素材往往是还没公开的项目资产，如果只是本地处理，用浏览器 File API 读取文件后，数据完全留在本地，不用上传到任何服务器。把处理页面直接发给同事，对方用浏览器打开就能用，省去了配置环境的功夫。对于团队内部工具这种场景，这个优势非常实际。

当然，浏览器方案的边界也得说清楚。它对视频编码的支持取决于浏览器内核，常见的 H.264、VP9 都没问题，但某些专业编码格式可能无法解码。另外，处理超大分辨率和超长视频时会受浏览器内存和 Canvas 尺寸限制，后面我会详细讲这几个坑。概括地说：8 秒 1080p 绿幕视频这个量级，浏览器方案是在舒适区里的，放心用。

2. 抽帧：从 8 秒绿幕视频里拿到 96 张原始画面

抽帧是整个流程的第一环，也是最容易被低估的一环。很多人在这一步直接把 video 元素丢到页面上，然后用 setInterval 定时去 drawImage 到 Canvas，最后发现抽出来的帧要么是重复的，要么前后帧跳变不连贯。这里面的核心问题是：video.currentTime 的更新和解码器的帧输出并不是同步的。

2.1 抽帧的合理频率和最终规模

处理 8 秒视频之前，先得确定抽多少帧。这个数字直接影响后续所有步骤的计算量和最终 sprite sheet 的尺寸，所以一定要想清楚用途再定。

游戏行业里角色动画常用 12 fps，这个帧率在流畅度和资源大小之间取得了比较好的平衡，我自己做这类需求也默认从 12 fps 起步。如果后续发现动画有明显的卡顿感，再升到 24 fps 重新跑一遍，成本也不高。素材原始帧率如果低于目标帧率，那就只能按原始帧率来，否则抽出的帧会重复。

2.2 对 seek 事件链的正确使用

抽帧最关键的技术细节，是必须利用 video 的 seek 事件链来保证每一帧都是精确的。核心逻辑是先让视频跳到目标时间点，等浏览器的解码器真正完成 seek 并触发seeked事件后，再从 video 元素上抓取画面，这才算拿到了一帧稳定且正确的画面。

实际代码写出来是这样一个流程：

async function extractFrames(video, { fps = 12, size = 256 } = {}) { const totalFrames = Math.ceil(video.duration * fps); const offCanvas = document.createElement('canvas'); offCanvas.width = size; offCanvas.height = size; const ctx = offCanvas.getContext('2d', { willReadFrequently: true }); const frames = []; for (let i = 0; i < totalFrames; i++) { const targetTime = i / fps; // 关键：等 seeked 事件真正触发后再绘制 await seekTo(video, targetTime); ctx.drawImage(video, 0, 0, size, size); frames.push(ctx.getImageData(0, 0, size, size)); } return frames; } function seekTo(video, time) { return new Promise((resolve) => { const handler = () => { video.removeEventListener('seeked', handler); resolve(); }; video.addEventListener('seeked', handler); video.currentTime = time; }); }

绘制时直接 drawImage 到 canvas，这一步已经完成了缩放，也就是把 1920×1080 的原始画面统一降采样到 256×256，这样后续抠图和拼接的数据规模就完全可控了。如果不做这一步降采样，96 帧 1080p 的 ImageData 会直接占用 96 × 1920 × 1080 × 4 字节，差不多 796MB 内存，页面大概率直接卡死。

2.3 为什么精确到帧这么重要

如果你在社区搜“视频抽帧”，会看到有人说直接监听 timeupdate 事件去绘制。这个方法看起来简单，但 timeupdate 的触发频率通常是 4Hz 左右，跟视频的 24fps、30fps 完全不是一回事，触发的时候你画出来的画面大概率是当前解码缓冲里的某一帧的近似位置，而不是你想要的第 i 帧。结果就是序列帧里出现大量重复帧或者错位帧，动画播放起来会明显抽搐。

强调一下，seeked事件链虽然要多写几行异步代码，但它是浏览器提供的最精确的抽帧方式。这个事件只有在解码器真正完成了视频定位，并且 video 元素已经准备好输出指定时间点的画面时才会触发，帧的稳定性和准确性都有保障。

2.4 视频加载阶段容易踩的坑

抽帧前视频必须完成元数据加载，并且要准备好第一帧画面。通常在 load 后直接调用 play 会报错，或者 drawImage 出来是黑屏。我习惯等待loadeddata事件触发后再开始抽帧，这个事件表示当前帧的数据已经可用。

video.muted = true; // 必须静音，否则某些浏览器会阻止自动播放 video.playsInline = true; await new Promise((resolve) => { if (video.readyState >= 2) resolve(); else video.addEventListener('loadeddata', resolve, { once: true }); });

还有个很隐蔽的坑：如果视频文件是通过URL.createObjectURL(file)创建的本地地址，一切正常；但如果你从 CDN 跨域加载视频，则必须在 video 上设置crossOrigin = 'anonymous'，并且服务器要返回 CORS 响应头，否则后续getImageData会直接抛出一个常见的 SecurityError 异常。后面我会专门展开讲这个问题。

3. 抠图：色度键抽离绿幕，以及我最头疼的边缘溢色问题

拿到序列帧之后，接下来就是抠图。既然素材是绿幕，最直接的方案就是用色度键算法。这里我想先说一个结论：对于绿幕素材，基于规则的颜色距离判断，效果往往比你想象中好，而且成本极低，适合浏览器即时处理。

我看到相关热搜词里有人提到用 Java 跑 ONNX 的 RMBG-2.0 模型做人物抠图，还有人在问 GIMP、PS 怎么抠。这些方案处理人像发丝、复杂边缘确实更强，但需要较重的依赖或手动操作。绿幕素材天然给了我们一个强先验——背景颜色已知，那就没必要上模型，几行像素操作就能得到干净的透明通道。

3.1 色度键算法的核心逻辑

最基本的色度键思路，是对每个像素判断它和绿色基准颜色的“距离”。如果距离很近，说明是背景，alpha 设为 0；如果距离很远，说明是前景，alpha 设为 255。所谓距离，通常是在 RGB 空间里算欧氏距离。

function chromaKey(imageData, keyColor, threshold, smooth) { const data = imageData.data; const [kr, kg, kb] = keyColor; const threshSq = threshold * threshold; for (let i = 0; i < data.length; i += 4) { const r = data[i]; const g = data[i + 1]; const b = data[i + 2]; const dr = r - kr; const dg = g - kg; const db = b - kb; const distSq = dr * dr + dg * dg + db * db; if (distSq <= threshSq) { data[i + 3] = 0; // 完全透明 } else { const dist = Math.sqrt(distSq); // 在阈值和过渡区间之间做线性插值，得到半透明边缘 const alpha = Math.min(1, Math.max(0, (dist - threshold) / smooth)); data[i + 3] = Math.round(alpha * 255); } } }

这里面有两个参数需要理解透彻。threshold是相似度阈值，值越大，抠掉的绿色范围越大，但如果设置得过高，会把人物身上的绿色衣服、绿色装饰也误伤成透明。smooth是过渡宽度，它决定了绿色边缘到前景色之间的 alpha 渐变区间。smooth 设置得越宽，边缘越柔和，但太宽会让主体轮廓看起来发虚、有半透明的绿色光晕。

这里有一个容易混淆的点：如果只是一刀切地把小于阈值的像素 alpha 设为 0、大于阈值的设为 255，边缘会出现明显的锯齿和彩色噪点。原因在于绿幕拍摄时，人物边缘的像素是背景绿和前景色的混合，它们既不属于纯绿背景，也不属于纯前景色。只有通过过渡宽度参数给这些混合像素分配中间 alpha 值，才能模拟出自然的边缘半透明效果。

3.2 绿幕不均匀时，基准色自动估计

实际拍摄中绿幕往往不是均匀的纯绿色。灯光不均匀、背景布有褶皱，都会让绿幕像素的 RGB 在一个范围内波动。如果用一个写死的绿色基准值，比如(0, 177, 64)，大概率会留下大片绿色残留。

我用的方案是自动估计基准色：取第一帧画面的四个角和四边中间区域的像素平均值。因为绿幕拍摄时，人物通常在画面中央，四周基本都是背景。如果不放心，可以多取几个点做均值，或者用中位数，这样能避免个别反光点干扰。

function estimateKeyColor(imageData, samplePoints) { let rSum = 0, gSum = 0, bSum = 0; let count = 0; const { width, height, data } = imageData; for (const [px, py] of samplePoints) { // px, py 是 0~1 的归一化坐标 const x = Math.floor(px * width); const y = Math.floor(py * height); const idx = (y * width + x) * 4; rSum += data[idx]; gSum += data[idx + 1]; bSum += data[idx + 2]; count++; } return [ Math.round(rSum / count), Math.round(gSum / count), Math.round(bSum / count) ]; }

实测下来这个方案对大多数业余拍摄的绿幕视频都够用。当然也有例外，如果人物站在绿幕前伸开双臂，把四个角都挡住了，自动估计就会失准。这种情况我会在 UI 上加一个“点击画面取背景色”的交互，人工指定一个背景区域。虽然只是个小功能，但能解决不少现场拍摄的意外。

3.3 边缘绿色溢出的处理

这部分是抠图里最难搞的问题，也是我反复调了很多次才摸清规律的地方，值得单独拉出来说。

绿幕拍摄最典型的问题就是绿色溢色。光线在绿幕和人物之间多次反射，会让角色边缘、头发丝、衣服边缘染上一层淡淡的绿光。即使 alpha 已经抠干净了，这些像素仍然会在最终合成到其他背景上时显出一圈绿边，非常难看。

色度键完成之后，还需要做一步去溢色处理。简单有效的思路是：对每个残余像素，如果它的绿色通道明显高于红、蓝通道，就压低绿色通道的值，让它回归中性色。

function despill(data) { for (let i = 0; i < data.length; i += 4) { const r = data[i]; const g = data[i + 1]; const b = data[i + 2]; if (g > r && g > b) { // 线性地压低绿色分量，强度可以调节 data[i + 1] = Math.round(Math.max(r, b) * 0.7 + g * 0.3); } } }

这段代码的意图是：如果一个像素确实整体偏绿，说明它带了背景的绿色溢出，这时把绿色通道往红蓝通道的水平拉近。0.7 和 0.3 是我试过的比较稳妥的比例，既能把绿边去掉大部分，又不会让人物肤色变得发紫。如果你想通过 desaturate 的方式处理，也可以直接把这个像素的饱和度大幅降低。效果差别不是很大，按实际预览来选就行。

这里要提一下为什么不做 AI 模型抠图。RMBG-2.0、rembg 这类模型的优势在于不需要绿幕，任意背景都能抠人像，发丝级的细节也处理得很好。但代价也很明显：模型动辄几十上百 MB，需要在 Node 端或者用 ONNX Runtime 加载推理，浏览器的纯前端场景跑起来并不轻松。而绿幕素材本身就是为色度键准备的，用规则算法几分钟就能适配整个流程，对于轻量、快速出图的诉求更划算。如果你的素材根本没有绿幕，那我也建议先用桌面级别的 AI 工具处理好再导出透明视频或 PNG 序列。

4. 拼图：把透明序列帧排版成一张 sprite sheet 并输出元数据

每一帧都抠完图之后，已经把背景彻底剥离，此时它们都是带透明通道的独立画面。如果直接把几十张 PNG 分别导出，使用方要加载几十个文件，不够高效。于是需要拼接成一张 sprite sheet，也就是把多帧按网格排列放进同一张大图里。Web 上无论 CSS steps 动画还是游戏引擎，对这种格式的消费都很成熟。

4.1 拼接画布的几何排布

拼接前先决定每帧的尺寸和网格的列数。假设我们用的是 256×256 的帧尺寸，12 fps、8 秒共 96 帧，那选择 12 列 8 行是比较均衡的排布：整张画布是 3072×2048，宽高比接近 3:2，在 Web 上使用和压缩都比较友好。

计算行数没有特别复杂的公式，思路是明确列数后向上取整：

const cols = 12; const rows = Math.ceil(frameCount / cols); const sheetWidth = cols * frameWidth; const sheetHeight = rows * frameHeight;

列数的选取会直接影响 sprite sheet 的宽高比和单边尺寸。选择 12 列时，单边像素是 3072，完全在常见显卡纹理的限制范围之内。如果选 24 列，就会变成 6144×1024，尺寸更大，虽然也不算违法，但在部分低端移动设备上可能触发纹理上限问题。从安全角度考虑，单边不要超过 4096 是比较稳妥的经验值。

4.2 sprite sheet 的生成代码

把序列帧画到大画布上，其实就是一个二维坐标换算问题。第 i 帧的网格坐标可以通过取模和除法得到：

function buildSpriteSheet(frameImages, cols, frameWidth, frameHeight) { const rows = Math.ceil(frameImages.length / cols); const sheetCanvas = document.createElement('canvas'); sheetCanvas.width = cols * frameWidth; sheetCanvas.height = rows * frameHeight; const ctx = sheetCanvas.getContext('2d'); frameImages.forEach((image, index) => { const x = (index % cols) * frameWidth; const y = Math.floor(index / cols) * frameHeight; ctx.putImageData(image, x, y); }); return sheetCanvas; }

这里的 image 是前面抽帧时的 ImageData 对象，已经被色度键算法和去溢色处理过。putImageData 与 drawImage 不同，它不做缩放、不带变换，直接把像素数据按坐标放置，适合这种精确写位置的操作。但需要注意的是，putImageData 不经过 canvas 的合成管道，如果你做了某些全局变换或半透明设置，它是不会生效的，在这个场景下反而更贴合需求，我们要的就是原样放置每一帧。

回到之前的抽帧逻辑，如果不想在内存里保存 96 个 ImageData 对象再统一拼接，可以把抽帧、抠图、放网格这个过程串联起来，每处理完一帧就直接 putImageData 到 sprite sheet 的对应位置。这样可以大幅压缩运行占用，也是我在内存优化部分会重点提到的思路。

4.3 输出 PNG 和配套的元数据 JSON

sprite sheet 生成后，导出一般用 toBlob 得到 PNG 文件。PNG 支持 alpha 通道，是透明序列帧的标准格式。

sheetCanvas.toBlob((blob) => { const url = URL.createObjectURL(blob); const a = document.createElement('a'); a.href = url; a.download = 'sprite-sheet.png'; a.click(); URL.revokeObjectURL(url); }, 'image/png');

只给一张图还不够，消费者还需要知道每帧在什么坐标、帧尺寸是多少、总共有几帧。所以我会一并生成一份 JSON 元数据：

{ "spriteSheet": "sprite-sheet.png", "frameWidth": 256, "frameHeight": 256, "cols": 12, "rows": 8, "count": 96, "fps": 12, "frames": [ { "index": 0, "x": 0, "y": 0 }, { "index": 1, "x": 256, "y": 0 } ] }

这份 JSON 对使用方至关重要。Web 动画里要算出当前帧在 CSS steps 中的位置，游戏引擎里要知道每个裁剪矩形的左上角坐标，都依赖这份数据。如果不输出它，使用者还得自己数格子、量尺寸，体验会很差。

5. 三个最容易翻车的前端细节：内存、CORS 与逐帧对齐

浏览器端跑到这里，主体功能已经通了。但这套流程要稳定跑起来，还有三个坑必须提前知道，每一个我都踩过。

5.1 内存问题：不要一次性保存所有帧的 ImageData

我第一次直接把所有帧的 ImageData 放在一个数组里再统一处理，8 秒 24fps 的视频直接让浏览器页面崩溃。原因很好理解：一帧 1920×1080 的 RGBA ImageData 占 8.3MB，192 帧就是 1.6GB，浏览器渲染进程根本扛不住。

解决办法就是我在前面提到的“流式管线”：不要把抽帧当成独立步骤，而是把抽帧、抠图、拼网格放在一个流水线里，处理完一帧就立刻处理并写入 sprite sheet，然后释放这一帧的引用。这样不管视频多长，内存占用始终是固定的一帧加 sprite sheet 缓冲的大小，不会被帧数放大。

即使降采样到了 256×256，流式处理仍然是更稳妥的方案。因为 JavaScript 的垃圾回收在面对大量临时大对象时，会频繁触发耗时较长的 GC 停顿，页面会出现明显的卡顿感。能少创建对象就少创建对象。

5.2 CORS 问题：跨域视频会污染 Canvas

如果你的视频素材是从本地文件读取，这一步不会遇到问题。但如果你把工具部署到团队内部，视频放在 CDN 或另一台服务器上，就必须处理跨域问题。否则会在getImageData这一步直接抛异常：浏览器认为当前 canvas 已经被跨域数据污染，出于安全策略禁止读取像素。

解决方式分两步。第一步，拿到 video 元素后设置 crossOrigin 属性，必须在视频开始加载之前设置：

video.crossOrigin = 'anonymous'; video.src = 'https://cdn.example.com/video.mp4';

第二步，CDN 需要在响应头里返回 CORS 授权。如果是 nginx，要加：

add_header Access-Control-Allow-Origin *;

如果这两个条件缺一个，后续操作都会失败。我自己排查这个问题时绕了很久，最后在浏览器控制台里看到 “The canvas has been tainted by cross-origin data” 的报错才确认。现在的建议是：做本地文件的工具就坚持用 File 对象转 objectURL，不涉及跨域；做在线服务就把 CORS 头提前配好，并加上明确的错误提示。

5.3 逐帧对齐：为什么用定时器抽帧会得到重复帧或漏帧

前面提过 timeupdate 不精确。这里再往深说一层：即使你使用 requestAnimationFrame 循环，在 rAF 回调里读 video.currentTime，也不一定能拿到与视频帧序列严格对应的画面。因为浏览器的视频渲染有自己的节奏，currentTime 的步进和 canvas 绘制之间没有强同步关系，在性能波动时，一个 rAF tick 里可能跳过一帧，也可能连续两帧相同。

要精确对齐视频帧，比较可靠的是使用requestVideoFrameCallback，它在浏览器渲染完一帧并准备输出时回调，能拿到当前帧的 mediaTime，这和解码器的帧节奏是一致的。

if ('requestVideoFrameCallback' in video) { video.requestVideoFrameCallback(function onFrame(now, metadata) { const mediaTime = metadata.mediaTime; // 这里可以用 mediaTime 判断是否到了下一个抽帧时间点 video.requestVideoFrameCallback(onFrame); }); }

但需要注意兼容性，老版本的浏览器不支持这个 API。我的处理方式是：优先用 requestVideoFrameCallback，不支持就回退到 seek 事件链方案。seek 方案虽然要逐个时间点跳转，效率稍低，但胜在兼容性最广，对 8 秒视频来说耗时也可以接受。

5.4 背景偏色时不能只看预估基准色

前面说的自动估计基准色方法，更多是解决“绿幕整体偏色”的问题。但实际视频里，还经常遇到局部光照不均、角落偏暗、部分区域偏蓝的情况。自动估计出来的基准色是一个全局平均值，无法照顾到所有区域。

这种情况我会用另一种思路：先对每一帧做一次更低阈值的粗抠，确认哪些区域肯定是背景；然后在每个像素的判断里加入背景像素的局部平均值。不过这样逐帧逐区域计算量会明显上涨，8 秒视频在普通笔记本上可能要多花两三秒。实际使用中，我会在 UI 上提供“手动划区域选背景色”的功能，优先让用户处理极端场景，而不是让算法硬扛所有情况。

6. 参数调优与实用技巧：从自动跑通到效果精修

功能全部打通之后，剩下的事就是把效果调到能用的程度。色度键抠图的参数很依赖素材本身的光照条件和绿幕质量，所以我把这一节单独拿出来，讲讲实际调参的经验和常见问题的处理方法。

6.1 先抽一帧做实时预览，把参数调到满意再全量跑

前面反复强调可视化调试方便，这在参数调优阶段体现得最明显。我的交互设计是：先抽第一帧，把 threshold 和 smooth 两个参数做成滑块，每次拖动都用当前帧重新执行色度键抠图，并在页面上显示抠图和去溢色之后的效果。这样两个人配合调整时，一个人拖动滑块，另一个人盯着看边缘和背景残留，能在几秒钟内找到合适的参数组合。

参数调准之后，再对整个视频跑全量流程。这样能避免全量跑完才发现参数不对，再重新跑一遍的时间浪费。一个简单的实现思路：

function previewFrame(imageData, params) { const temp = new ImageData( new Uint8ClampedArray(imageData.data), imageData.width, imageData.height ); chromaKey(temp, params.keyColor, params.threshold, params.smooth); despill(temp.data); previewCtx.putImageData(temp, 0, 0); }

注意复制一份再处理，避免污染原始帧数据，这样调整参数时可以反复从原始状态重新计算，而不是越调越偏离。

6.2 常见问题对照表

调参过程中遇到的效果问题，绝大多数可以归到这四类。我整理了一个速查表：

这四类问题的处理优先级是：先解决大片的背景残留，因为这是最影响观感的；再处理边缘绿边；最后才调细节的半透明。如果顺序反了，可能越调越乱。

6.3 对 alpha 边缘再做一次收缩

即使加了过渡宽度，边缘仍然可能出现一圈极淡的绿晕。这是因为色度键算法天然无法区分边缘像素里到底是“半透明的前景”还是“带有绿色溢出的不透明前景”。这时候需要做一次 alpha 收缩，把最外圈的边缘像素往内移动一点点，等于把带嫌疑的像素裁掉。

alpha 收缩的简单实现是使用“最小邻域”思路：遍历每个像素，如果它周围 8 邻域中出现了一个 alpha 为 0 的像素，就把当前像素的 alpha 降低。重复一两次，效果就等同于形态学上的腐蚀。这个操作对发丝边缘尤其有效，但对规则的几何边缘会有轻微缩小，所以强度要克制，一般做 1 轮就够。

6.4 合成验证：放到真实背景上看效果

抠图的效果不能只看透明通道的 checkerboard 图，必须放到真实背景上看。我的习惯是在工具里内置几种测试背景，比如白色、黑色、一张真实的场景图，一键切换预览。黑背景最能暴露绿色残留，白背景最容易看出边缘发虚和半透明问题，真实背景则是最终验收标准。

这是因为 alpha 通道和颜色混合的效果在不同背景下差异巨大。一个边缘残留绿色平均值 (0, 80, 0) 的像素，放在黑底上几乎看不出来，放在白底上会显出一圈灰绿色，非常明显。如果你只盯着黑底调参，决定“没问题”之后，换到亮场景可能直接翻车。

7. 浏览器方案和常用抠图工具的一个横向补充

写到这里，可能有些读者会想：这些操作在 GIMP 或 Photoshop 里不是也能做吗？确实能，GIMP 有 color to alpha 插件，PS 有色度键相关功能，甚至还有 AI 人像抠图。但差别在“自动化”和“批量处理”上。

如果要抠一张图，PS 的快速选择工具或者 GIMP 的路径工具反而更精细。但如果要把 96 帧画面做成序列帧，任何手动工具都会有大量重复劳动：每一帧都要导出一张 PNG，再单独建一个大画布手动拖进去排列位置。这不是能不能做的问题，是效率问题。浏览器方案里，参数调好之后整个流水线一键跑完，从视频到 sprite sheet 和 JSON 元数据，一次到位。

关于 AI 方案，我知道很多人用 ONNX 跑 RMBG-2.0 这类模型，一个 Python 或 Java 后端，几个请求就能把人物抠出来。如果目标是处理任意背景的视频，而且对发丝、半透明物体要求很高，AI 方案的下限下限确实要远优于色度键。但在这个项目里，素材风格可控、背景颜色已知，加上目标产物是 sprite sheet 而不是高保真合成，那么浏览器里的色度键方案已经能提供足够好的质量，优势反而是重量轻、免部署、上手快。

8. 顺着这套方案还能继续扩展的玩法

这套流程跑通后，我顺手给它加了一些扩展功能，发现边际成本很低，收益却很可观。比如“按帧间隔抽帧”，也就是不限定固定 fps，而是每隔 N 帧抽一次，这在处理游戏角色的技能动画时很实用，有些动作变化慢的部分没必要每帧都保留。

再比如“角色包围盒自动裁剪”。绿幕视频里人物往往只占画面一部分，如果直接全图抽帧，sprite sheet 里大部分都是透明区域，浪费空间。处理思路是：对第一帧的 alpha 通道做扫描，找到非透明像素的包围盒，然后把所有后续帧都按这个包围盒裁剪。这个功能实现起来不算复杂，但通常能把最终的 PNG 体积压缩 30% 到 50%。

还有一个很实用的方向是“反向合成预览”。既然已经有了透明序列帧，可以直接把序列帧合成到一个新的背景画布上，动态预览动画实际播放效果，省得每次都要导出之后才能看效果。我把它做成了模式切换开关，预览模式消耗的内存稍多一些，但整套流程不用离开页面。

这些都是围绕“视频转序列帧”这个核心的合理延伸，在自动驾驶、游戏动画、Web 动效等场景里都有用途。对我来说，最大的收获不是省了多少时间，而是确认了一个判断：很多你以为得开重型软件干的活，浏览器在平台能力已经逐步跟上来之后，完全有能力承担其中相当大一部分。

最后分享一个小技巧：如果你的绿幕视频尺寸不是规则的 16:9，或者人物的运动范围特别大，不要强求输出正方形帧。可以先让用户输入缩放尺寸和每帧宽度，工具会计算高度并等比缩放。正方形帧序列只是默认值，不是唯一选择。这个细节我在实际给动效团队做素材时帮了大忙，输出的 sprite sheet 更紧凑，压缩比也更好。