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 才是该帧在原始流中的真实时间戳——做动作识别、唇形同步、音画对齐时，必须优先取这个值。
