如何在高频动画中借助 requestVideoFrameCallback 实现网页视频的实时滤镜叠加

不能直接替代，但能显著降低延迟——requestVideoFrameCallback提供解码帧原始像素数据，绕过drawImage同步拷贝开销，适合美颜、AR等逐帧处理场景，需Chrome114+/Firefox125+支持，且必须配合video元素使用。

requestVideoFrameCallback 能不能替代 drawImage 做实时滤镜？

不能直接替代，但能显著降低延迟——requestVideoFrameCallback 提供的是视频解码帧的原始像素数据（通过 VideoFrame 对象），绕过了 canvas 的 drawImage 同步拷贝和合成开销。它适合对帧率敏感、需逐帧处理（如美颜、AR 特征点跟踪）的场景，但不适用于简单 CSS 滤镜或纯 GPU 渲染的静态效果。

关键区别在于时机：requestVideoFrameCallback 在浏览器即将提交该帧到屏幕前触发，而 drawImage + requestAnimationFrame 通常滞后 1–2 帧，尤其在 60fps 动画中容易积压。

• 必须配合 video.requestVideoFrameCallback 使用，不能用在 canvas 或 img 上
• 仅 Chrome 114+、Edge 114+、Firefox 125+ 支持（Safari 仍无计划）
• 回调中拿到的 VideoFrame 默认是 YUV 格式（format: "yuv420"），不能直接传给 putImageData
• 若视频未启用 playsinline 或未用户手势触发播放，回调可能永不触发

如何从 VideoFrame 提取 RGBA 并写入 WebGL 纹理？

YUV 到 RGBA 的转换必须在 GPU 完成，否则 CPU 解码 + JS 转换会卡死主线程。最轻量方案是用 WebGL 2 的 copyTextureToBuffer + 自定义着色器，但更通用的做法是利用 VideoFrame.copyTo 输出为 RGBA 格式（需显式指定）：

video.requestVideoFrameCallback((frame) => {  const rgbaBuffer = new OffscreenCanvas(1, 1).getContext('2d').createImageData(frame.displayWidth, frame.displayHeight);  // 注意：copyTo 会自动做色彩空间转换，但要求目标 canvas 尺寸匹配  frame.copyTo(rgbaBuffer.data, { format: 'rgba' });<p>// 此时 rgbaBuffer.data 是 Uint8ClampedArray，可传给 WebGL texturegl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, frame.displayWidth, frame.displayHeight, 0, gl.RGBA, gl.UNSIGNED_BYTE, rgbaBuffer.data);</p><p>frame.close(); // 必须调用，否则内存泄漏});

• frame.copyTo 的 format: 'rgba' 会触发内部 YUV→RGB 转换，性能尚可（硬件加速），但比原生 YUV 纹理多一次拷贝
• 务必检查 frame.displayWidth/frame.displayHeight，它们可能与 video.videoWidth 不同（受缩放、letterboxing 影响）
• WebGL 纹理尺寸需是 2 的幂（非必需但推荐），否则需设置 gl.NEAREST 和禁用 mipmap
• 不要复用同一个 OffscreenCanvas 的 ImageData，每次应新建或重置 data 视图

为什么滤镜动画卡顿？三个常被忽略的内存陷阱

高频回调下，卡顿几乎都源于隐式内存分配或同步阻塞。最典型的是：

• 在回调里创建新 Uint8ClampedArray 或 ImageData —— 每秒 60 次 GC 压力极大；应预分配并复用缓冲区
• 忘记调用 frame.close() —— VideoFrame 持有底层解码帧引用，不释放会导致视频解码器停顿
• 在回调中执行耗时 JS 计算（如卷积滤镜）—— 即使是 5ms 也会让帧率掉到 30fps；必须用 WebAssembly 或 WebGL shader 替代
• 未设置 video.setAttribute('playsinline', '') 且页面在 iOS Safari 中运行 —— 回调完全不触发

一个最小可行复用模式：

let cachedBuffer = null;video.requestVideoFrameCallback(function processFrame(frame) {  if (!cachedBuffer || cachedBuffer.length !== frame.displayWidth * frame.displayHeight * 4) {    cachedBuffer = new Uint8ClampedArray(frame.displayWidth * frame.displayHeight * 4);  }  frame.copyTo(cachedBuffer, { format: 'rgba' });  // → 直接传给 WebGL 或 WASM 滤镜函数  frame.close();  video.requestVideoFrameCallback(processFrame); // 主动续订});

requestVideoFrameCallback 和 WebCodecs 的定位差异

如果你需要精确控制解码参数（如跳过 B 帧、指定分辨率）、做编码回传，或处理非播放态视频（如分析本地文件），requestVideoFrameCallback 不够用，得上 WebCodecs。但它更重、兼容性更差（仅 Chromium 系），且无法对接 <video> 元素的播放状态。

• requestVideoFrameCallback 是「播放时截帧」，零配置，依赖 video 元素生命周期
• WebCodecs 是「手动解码流」，可暂停/seek/丢帧，但需自己管理 VideoDecoder 和 EncodedVideoChunk
• 两者不能混用：一旦调用 decoder.decode()，<video> 就不再输出帧，requestVideoFrameCallback 会静默失效
• 移动端低端设备上，requestVideoFrameCallback 的帧率稳定性优于 WebCodecs（后者易因解码压力丢帧）

真正在意首帧延迟和持续帧率的滤镜应用，优先跑通 requestVideoFrameCallback + WebGL pipeline，别过早切 WebCodecs。