HTML5视频播放由浏览器硬件加速，无需RAF驱动；RAF仅适用于在视频上叠加Canvas动画、逐帧图像处理或自定义时间轴等需同步渲染的场景。

HTML5视频本身已由浏览器底层硬件加速处理，通常无需用 requestAnimationFrame（RAF）主动控制帧渲染。盲目结合反而可能引入同步开销、掉帧或视觉卡顿。真正需要 RAF 的场景，是**在视频画布上叠加动态图形、做逐帧图像处理、或实现自定义时间轴逻辑**——这时 RAF 才成为协调视频帧与自定义绘制的关键工具。

明确视频帧与 RAF 的关系

HTML5 元素的播放是独立于 JavaScript 主线程的，其解码与合成由浏览器媒体管线管理。调用 requestAnimationFrame 并不能“驱动”视频播放，也不能保证每次回调都对应一个新视频帧。实际中：

• 视频帧率（如 24/30/60 fps）和 RAF 回调频率（理想 60fps）未必对齐，尤其在性能受限时 RAF 可能降频，而视频仍按自身节奏解码；
• video.readyState 和 video.currentTime 的精度有限，直接依赖 RAF 时间戳推算视频帧易产生漂移；
• 推荐以 video 元素的 timeupdate 事件或 seeking/playing 等生命周期事件为基准，仅在需逐帧同步绘制时，再用 RAF 对齐渲染时机。

叠加 Canvas 动画：用 RAF 同步绘制，而非驱动视频

常见需求是在视频上方绘制字幕、标记点、滤镜效果等。此时应：

• 将 设置为与 相同尺寸，并用 CSS 层叠定位覆盖；
• 监听 video 的 play 事件启动 RAF 循环，在每次回调中：
  — 先读取 video.currentTime 获取当前时间点；
  — 调用 ctx.drawImage(video, ...) 将当前视频帧绘制到 canvas；
  — 再叠加自定义图形（如路径、文字、滤镜后处理）；
• 避免在 RAF 中调用 video.play() 或修改 currentTime，以防触发异步状态变更打断渲染流。

逐帧图像处理：用 captureStream() + RAF 更可靠

若需对每一帧做 JS 处理（如人脸识别、色彩分析），不建议靠 RAF 定时采样——容易漏帧或重复采样。更稳的方式是：

• 调用 video.captureStream() 获取 MediaStream；
• 创建 MediaStreamTrack 的 Processor（如使用 OffscreenCanvas + Worker）；
• 或搭配 VideoFrame API（Chrome 94+）在 requestVideoFrameCallback 中获取精确帧对象；
• 仅当兼容性要求低、且只需轻量处理时，才在 RAF 回调中用 ctx.drawImage + ctx.getImageData 采样，同时加帧号比对防重复。

性能关键：跳过非可视帧 & 合理节流

即使使用 RAF，也要防止无意义重绘：

• 检查 document.hidden，页面不可见时暂停 RAF；
• 用 video.paused 或 video.ended 控制是否继续循环；
• 对高分辨率视频，可降低 canvas 绘制分辨率（如设 canvas.width = video.videoWidth / 2），再用 CSS 缩放显示；
• 避免在每次 RAF 中新建对象（如 ImageData），复用缓冲区。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！