如何在高频动画场景下借助 requestVideoFrameCallback 提升视频处理精度

requestVideoFrameCallback 比 timeupdate 更适合高频视频处理，因其严格对齐视频帧输出节奏（如30fps时约33ms触发），且提供精确的 mediaTime 时间戳；而 timeupdate 频率低、不可控且与渲染脱钩。

为什么 requestVideoFrameCallback 比 timeupdate 更适合高频视频处理

因为 timeupdate 是基于播放时间戳的节流事件，触发频率不可控（通常 200–500ms 一次），且与真实帧渲染脱钩；而 requestVideoFrameCallback() 直接绑定浏览器合成器帧提交时机，回调触发时刻严格对齐视频帧输出节奏。在 30fps 视频中，它基本稳定在 ~33ms 间隔触发；60fps 下则接近 ~16.7ms —— 这才是做逐帧分析、画布同步绘制、动作捕捉等高频操作的可靠时基。

必须手动递归注册，否则只执行一次

requestVideoFrameCallback() 的设计是单次回调：注册后仅在下一帧触发，之后自动注销。若不主动重注册，后续所有帧都不会进入回调。常见错误就是写成一次性调用，结果只拿到第一帧数据就停了。

• 正确做法是在回调函数内部立刻再次调用 video.requestVideoFrameCallback(callback)
• 避免在回调中做耗时操作（如大图 drawImage、复杂计算），否则可能阻塞下帧注册，导致丢帧
• 建议加一层防重入保护：用布尔标记是否已注册下帧，防止异常重入造成重复注册

兼容性检测不能只看 API 存在，要实测触发

部分 iOS 15.4+ 设备或旧版 Safari 虽然 "requestVideoFrameCallback" in HTMLVideoElement.prototype 返回 true，但回调永不执行——这是已知的“伪支持”现象。仅靠特征检测会误判。

• 必须发起一次真实调用并设置超时兜底：video.requestVideoFrameCallback(() => { resolved = true; })，配合 setTimeout(() => { if (!resolved) cb(false); }, 200)
• iOS 最低可靠版本是 15.4，但 15.4–15.6 仍有小概率静默失败，生产环境建议 fallback 到 timeupdate + 帧差检测（video.currentTime 变化速率）组合方案
• Chrome 94+、Edge 94+、Firefox 114+ 支持较稳；Android WebView 需 Chrome 100+ 内核

与 requestAnimationFrame 混用时的节奏冲突

两者触发逻辑不同：requestAnimationFrame() 对齐屏幕刷新率（如 60Hz），requestVideoFrameCallback() 对齐视频帧率（如 25/30/60fps）。若同时驱动同一动画逻辑，容易出现帧抖动或采样错位。

• 不要把视频帧处理逻辑塞进 requestAnimationFrame 回调里——它无法反映视频真实帧到达时刻
• 如需叠加 UI 动画（如进度条、遮罩层），应以 requestVideoFrameCallback 为唯一主时钟，UI 更新同步其时间戳参数 now
• 注意 metadata.presentedFrames 和 metadata.mediaTime 字段：前者是累计已提交帧数，后者是该帧对应的媒体时间，比 video.currentTime 更精确（尤其在 seek 或卡顿时）

实际高频场景中，最易被忽略的是帧时间精度与媒体时间漂移问题：video.currentTime 在缓冲、seek、音画不同步时会跳变或滞后，而 requestVideoFrameCallback 回调参数中的 metadata.mediaTime 才是该帧在原始流中的真实时间戳——做动作识别、唇形同步、音画对齐时，必须优先取这个值。