浏览器也能秒级处理视频换脸：Timeline Studio 的 WebGPU 本地推理实践

浏览器也能秒级处理视频换脸：Timeline Studio 的 WebGPU 本地推理实践

摘要：视频换脸通常让人想到 Python、CUDA、服务端 GPU 和漫长的上传队列。我们在开源项目 Timeline Studio 中走了另一条路：将人脸检测、身份特征提取、逐帧换脸、光流跟踪和视频编码全部放进浏览器，素材无需上传到编辑后端。本文介绍这条基于 SCRFD、MobileFaceSwap、ONNX Runtime Web、WebGPU、WebCodecs 和 OpenCV.js 的端侧视频处理链路，以及我们如何在速度、稳定性、隐私和工程可用性之间做取舍。

项目地址：

• GitHub：https://github.com/MartinDelophy/ai-video-editor

为什么要在浏览器里做换脸

传统在线视频换脸一般是这样的：

1. 用户把原视频上传到服务器；
2. 后端等待 GPU 调度；
3. 服务端解码、推理、重新编码；
4. 用户再下载成片。

这套架构成熟，但也带来三个问题：素材上传耗时、GPU 服务成本，以及人脸数据离开本机后的隐私压力。

Timeline Studio 是一个本地优先的浏览器 AI 视频编辑器。换脸功能延续了这一原则：源人脸、目标图片和目标视频都在当前设备内处理。模型准备完成后，短视频片段可以直接进入秒级本地处理链路，不必等待服务端任务队列。

这里的“秒级”需要讲清楚：它指模型已下载并完成热启动后，图片或短片段能够在数秒量级开始并完成处理的交互体验，不是对任意时长、任意分辨率和任意显卡承诺固定耗时。实际速度取决于 GPU、浏览器、视频长度、输出采样率和编码器。项目会在控制台输出真实的逐帧推理、帧处理和编码耗时，方便在具体设备上测量，而不是用一个脱离硬件环境的数字概括所有情况。

整体技术链路

换脸不是只运行一次神经网络。一个可用的视频流程至少要解决身份提取、人脸对齐、跨帧跟踪、逐帧生成、融合和重新编码。

Timeline Studio 当前链路可以概括为：

源人脸图片
  └─ SCRFD 检测 + 5 点关键点
      └─ 112×112 相似变换对齐
          └─ Identity Network
              └─ Conditioner
                  └─ 缓存源身份条件权重

目标视频
  └─ WebCodecs 顺序解码
      └─ SCRFD 稀疏锚点检测（默认 2 FPS）
          └─ PyrLK 双向光流跟踪中间帧
              └─ 224×224 人脸对齐
                  └─ MobileFaceSwap Generator（每个输出帧）
                      └─ 颜色匹配 + 遮罩羽化 + 逆变换合成
                          └─ WebM 编码并加入 My assets

工程上最重要的拆分是：人脸检测不必在每一帧都运行，但换脸生成器仍对每个有效输出帧执行。默认输出采样率为 8 FPS，检测锚点为 2 FPS，也就是每四帧重新检测一次，其余帧用光流更新五个关键点。这样减少了较重的人脸检测次数，同时保留逐帧表情生成。

1. 用 SCRFD 锁定人脸与五点关键点

第一步使用 SCRFD 10G BNKPS ONNX 模型检测人脸框和五点关键点：双眼、鼻尖和两个嘴角。

输入画面会等比缩放并填充到 640×640，再转换为 NCHW Float32 张量。SCRFD 的三个输出层对应 8、16、32 三种 stride，解码后通过 IoU 阈值做 NMS，最多保留 12 张人脸。

我们没有简单地“取第一张脸”。源图片优先选最高置信度的人脸；视频首帧倾向选择面积较大且靠近画面中心的人脸；后续锚点则根据与上一帧人脸框的中心距离和面积变化打分，从而尽量保持同一目标。

同时还会检查五官几何关系：

const complete =
  eyeDistance >= 0.14 &&
  mouthDistance >= 0.10 &&
  noseY > eyeY &&
  noseY < mouthY;

这类保守检查非常必要。源脸过小、严重遮挡、只露出半张脸，或者关键点顺序异常时，继续生成通常只会得到更糟的结果。与其输出错误换脸，不如尽早给出清晰失败提示。

2. 相似变换比直接裁剪更重要

检测到关键点后，我们计算五点到标准模板的二维相似变换，包括统一的缩放、旋转和平移。

源脸被对齐为 112×112，用于身份提取；目标脸被对齐为 224×224，用于逐帧生成。生成结束后，再使用该矩阵的逆变换把结果贴回原视频坐标。

如果省略人脸对齐，网络就需要同时学习身份、头部旋转、尺度和位置变化；对于轻量浏览器模型而言，这会明显增加眼睛漂移、嘴角错位和脸型抖动。稳定的几何归一化实际上是整个端侧方案的基础。

3. 身份只提取一次，重复生成直接复用

MobileFaceSwap 在项目中被拆成身份网络、条件网络和逐帧生成器：

• Identity Network 从 112×112 源脸中提取身份特征；
• Conditioner 将身份特征转换为生成器需要的动态条件权重；
• Generator 接收目标人脸和已生成的身份条件，输出换脸结果与融合遮罩。

源图片通过文件名、大小和修改时间生成缓存键。同一个源脸再次生成时，Worker 会直接复用已经计算好的条件权重：

if (conditionedWeights && sourceKey === key) {
  postProgress(requestId, 100, "faceSwapSourceCached");
  return;
}

这点对交互速度很关键。用户常常会拿同一张源脸尝试多个片段，如果每次都重新运行身份提取和条件网络，会把本可避免的延迟重复叠加。

模型 Worker 也会保持存活，ONNX Session 不随单次任务销毁。模型热启动后，后续生成不再表现成一次新的模型下载。

4. WebGPU 推理与 Worker 隔离

推理运行在独立 Web Worker 中，使用 onnxruntime-web/webgpu：

const options = {
  executionProviders: ["webgpu"],
  graphOptimizationLevel: "all",
};

const generator = await ort.InferenceSession.create(
  generatorModel,
  options,
);

这样做有两个收益。

第一，模型推理和张量准备不会长时间占用 React UI 所在的主线程；时间线、进度条和取消按钮仍能响应。

第二，Worker 可以集中管理 Session、条件权重和取消状态，避免组件重渲染导致模型反复初始化。

四个模型文件会并行下载，下载完成后再串行创建 SCRFD、Identity、Conditioner 和 Generator Session。并行下载缩短网络等待，串行编译则避免多个 WebGPU Session 同时初始化造成显存和编译压力。

当前模型总量约 309 MB。首次使用需要下载，后续请求通过浏览器缓存复用。模型同时提供 Hugging Face 与 ModelScope 线路，并固定到不可变 revision，既方便国内网络访问，也避免上游 main 分支变化导致同一版本产生不同结果。

5. WebCodecs 顺序解码，避免反复 seek

浏览器逐帧处理视频时，一个常见但低效的写法是不断修改 <video>.currentTime，等待 seeked，再把画面画到 Canvas。短视频还能工作，片段稍长后就会频繁触发关键帧回溯和解码等待。

Timeline Studio 通过 Mediabunny 的 Input + CanvasSink 接入 WebCodecs，并按目标时间戳顺序获取 Canvas：

const sink = new CanvasSink(track, {
  poolSize: 3,
  decoderOptions: { optimizeForLatency: true },
});

const iterator = sink
  .canvasesAtTimestamps(times)
  [Symbol.asyncIterator]();

如果当前编码格式或浏览器不能使用这条路径，才回退到原生 video seek。也就是说，高性能路径和兼容路径都存在，但不会为了兼容性放弃 WebCodecs 的顺序解码优势。

6. 稀疏检测加双向光流，稳定锁定同一个人

视频换脸最容易出现的问题之一，是画面中出现第二个人后目标突然跳脸。

项目默认每秒运行两次 SCRFD 锚点检测。锚点之间使用 OpenCV.js 的 pyramidal Lucas–Kanade 光流追踪五个关键点，窗口为 21×21，金字塔层数为 3。

仅看正向光流还不够。我们会把追踪后的点再从当前帧反向追踪回上一帧，计算 forward-backward error：

const accepted =
  trackedPoints >= 4 &&
  forwardBackwardError <= 3.5;

五个点至少有四个稳定，且平均双向误差不超过 3.5 像素，才接受当前追踪结果。否则立即丢弃该帧的人脸位置，等待下一个检测锚点重新锁定。

当目标丢失时，系统保留原始帧，而不是在错误人物上强行换脸。这是一种“失败关闭”策略：少换一帧通常比换错一个人更可接受。

7. 融合质量不只靠生成器

生成器输出 224×224 RGB 结果和一张人脸遮罩。直接贴回原画面会产生明显的方形边缘、肤色跳变和锯齿，因此合成前还有三步后处理。

第一步是颜色匹配。在有效遮罩区域内分别计算生成脸与目标脸各通道的均值和标准差，对结果做有限范围的缩放和平移，并用 0.72 的强度混合，避免校正过度。

第二步是遮罩形态学处理。遮罩会先膨胀、腐蚀，再做盒式模糊；同时叠加一张带羽化的边界遮罩，避免网络输出靠近 224×224 边缘时形成硬切。

第三步是逆变换合成。处理后的脸和 Alpha 遮罩通过目标帧对齐矩阵的逆矩阵回到原坐标，再用 Canvas 的 destination-in 完成裁切。

这些看似传统的图像处理步骤计算量不大，却直接决定了最终结果是否“贴得上去”。

8. “秒级”的核心不是单个模型，而是整条流水线

浏览器端速度优化不能只看一次 session.run()，因为用户等待的是从点击按钮到拿到视频的总时间。我们把耗时拆成三部分：

• inferenceMs：生成器逐帧推理累计耗时；
• frameProcessingMs：解码、检测、追踪、推理、融合和帧压缩总耗时；
• encodingMs：最终视频编码耗时。

完成后浏览器会输出：

[Face Swap][Performance]
{
  "frameProcessingMs": ...,
  "encodingMs": ...,
  "inferenceFrames": ...,
  "inferenceMs": ...,
  "model": "mobilefaceswap-224",
  "totalFrames": ...
}

这个指标设计也揭示了端侧视频 AI 的性能原则：

1. 模型只下载一次，并在浏览器缓存；
2. Session 只编译一次，Worker 保持存活；
3. 源身份只提取一次；
4. 检测使用稀疏锚点，中间帧交给光流；
5. 解码优先走 WebCodecs 顺序路径；
6. ArrayBuffer 通过 transferable 在 Worker 间转移，减少复制；
7. 处理、推理和编码分别计时，才能找到真正瓶颈。

默认参数是 8 FPS 输出、2 FPS 检测锚点和最长 60 秒片段。这是当前面向浏览器交互的速度与稳定性折中，并不等同于影视级 24/30 FPS 最终制作。开发者可以通过环境变量调整输出 FPS 与锚点频率，但更高参数会直接增加推理和编码成本。

9. 本地优先不等于没有工程边界

浏览器端换脸的优势很明确：

• 原始人脸和视频不需要上传到编辑服务器；
• 不需要维护按分钟计费的 GPU 推理集群；
• 模型缓存后可以离线或弱网重复使用；
• 能直接接入浏览器时间线、素材库和导出流程；
• 用户取消时可以停止解码和后续推理，不生成残缺下载文件。

但它也有现实边界：

• 需要最新版 Chrome 或 Edge 及可用 WebGPU；
• 首次约 309 MB 模型下载仍受网络速度影响；
• 不同集成显卡、独显和移动设备的性能差异明显；
• 大角度侧脸、快速遮挡、极小人脸和多人交叉仍是难点；
• 当前使用的是研究权重，商业发布前必须单独核验模型许可；
• 换脸必须取得源人脸和目标人物的明确授权。

因此，项目在 UI 中要求用户确认授权，并明确提示研究模型不能未经许可直接用于商业发布。本地运行解决了“素材是否上传”的隐私问题，但不能替代肖像权、著作权和模型许可证合规。

10. 部署时容易忽略的细节

如果要把类似方案部署到生产环境，至少需要注意以下几点。

首先，使用 HTTPS。WebGPU、Worker 和现代媒体 API 在安全上下文中才能稳定工作。

其次，为页面配置跨域隔离响应头：

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-origin

再次，模型地址必须固定版本并支持正确的 CORS/CORP 响应。不要直接依赖会变化的 main，否则缓存、校验和复现都会变得困难。

最后，为模型下载提供清晰的阶段进度、镜像回退和可理解的错误提示。不要把原始的 Failed to fetch 直接扔给用户。模型下载失败、WebGPU 不可用和目标人脸丢失，应该是三类不同错误。

结语

WebGPU 让神经网络真正进入浏览器，WebCodecs 让浏览器能够高效接管视频帧，Worker 和 transferable buffer 则让这套计算密集型流程仍然保持可交互。将它们组合起来之后，视频换脸不再天然等于“上传文件、等待云端 GPU、下载结果”。

Timeline Studio 的实践说明，浏览器已经可以完成一条完整的视频 AI 流水线：检测、对齐、身份提取、跟踪、生成、融合、编码和素材管理都发生在本机。模型热启动后，短视频换脸可以进入秒级体验，同时避免素材上传和服务端排队。

如果你对浏览器媒体、WebGPU/ONNX、本地 AI 或多轨视频编辑感兴趣，欢迎体验项目、阅读源码或参与改进：

• 开源项目：https://github.com/MartinDelophy/ai-video-editor

如果这个项目对你有帮助，也欢迎在 GitHub 点一个 Star。