requestVideoFrameCallback的核心价值在于实现帧对齐处理时机，即在视频帧解码完成、尚未渲染前精准触发回调，为滤镜合成争取最大处理窗口；需配合disableRemotePlayback、playsinline、异步滤镜流水线、帧节拍控制及降级方案才能稳定达成2～3帧低延迟。
requestVideoFrameCallback 的核心价值
它让浏览器在视频帧真正准备就绪（解码完成、可绘制）的下一帧时机触发回调，绕过 requestAnimationFrame 的屏幕刷新节奏和 video 元素的渲染延迟，实现真正“帧对齐”的处理时机。关键不是“快”，而是“准”——在帧刚解码完、尚未被渲染前拿到，为滤镜合成争取最大处理窗口。
基础使用：绑定与帧数据获取
需先确保 video 元素启用 disableRemotePlayback="true" 和 playsinline（移动端），并调用 play() 进入可播放状态。回调中通过 videoFrame 对象获取 RGBA 数据：
- 调用 videoFrame.copyTo(imageBitmap) 获取可离屏处理的图像资源（推荐，避免 canvas 读写瓶颈）
- 或用 videoFrame.createImageBitmap()（更轻量，但部分浏览器支持度略低）
- 不建议直接 drawImage 到 canvas 后 getImageData —— 触发同步读取，大幅增加延迟
异步滤镜流水线设计
把滤镜逻辑拆成“获取→计算→回填”三阶段，全部异步化，避免阻塞主线程导致丢帧：
- 在 requestVideoFrameCallback 回调内立即调用 videoFrame.copyTo()，返回 Promise
- 将 ImageBitmap 传入 Web Worker 执行耗时滤镜（如卷积、HSV 调整），主线程不等待
- Worker 处理完成后，用 transferToImageBitmap() 将结果零拷贝传回，再用 canvas.getContext('2d').drawImage() 渲染
- 每次处理完一帧，立刻发起下一次 requestVideoFrameCallback，保持链式调用
延迟控制与健壮性要点
实际应用中需主动管理帧节拍，防止积压或跳帧：
立即学习“前端免费学习笔记（深入）”；
- 检查 videoFrame.presentTime 与上一帧时间差，若超过 1.5 倍帧间隔（如 60fps 下 >25ms），说明已滞后，可跳过当前帧处理
- 调用 video.cancelVideoFrameCallback(id) 在暂停/销毁时及时清理，避免内存泄漏
- 降级方案：检测 API 不可用时（如 Safari），fallback 到 canvas.captureStream().getVideoTracks()[0] + ondataavailable，延迟高但兼容
不复杂但容易忽略
真正低延迟不靠堆砌技术，而在于紧扣“帧就绪即处理”这一时机本质。requestVideoFrameCallback 是钥匙，但必须配合异步数据流转、帧节拍判断和合理降级，才能在不同设备与网络条件下稳定输出 2～3 帧以内延迟的滤镜视频流。
