WebSocket仅提供实时通道，帧对齐需应用层实现：用requestVideoFrameCallback获取expectedDisplayTime作为帧锚点，结合时钟同步与服务端统一帧总线仲裁，客户端通过masterClock软对齐渲染。
WebSocket 本身不处理视频帧对齐，它只负责低延迟、双向、全双工的实时消息通道；真正的帧对齐必须由应用层协同设计——结合音视频时间戳、客户端时钟同步、服务端统一参考时钟与帧序号校验来实现。
用 MediaStream + video.currentTime + requestVideoFrameCallback 实现本地精准帧定位
现代浏览器（Chrome 110+、Edge 110+）支持 requestVideoFrameCallback，可捕获解码后的真实渲染帧时间戳，比单纯读取 video.currentTime 更可靠：
- 在播放器加载完成后，调用
video.requestVideoFrameCallback((now, metadata) => {...})，其中metadata.presentedFrames和metadata.expectedDisplayTime提供高精度帧呈现信息 - 将当前帧的
expectedDisplayTime（单位：毫秒，基于 performance.timeOrigin）作为本机“帧锚点”，本地标注操作（如框选、打标）均绑定此时间戳 - 避免使用
Math.round(video.currentTime * 1000)，因 currentTime 受缓冲、丢帧、播放速率影响，误差常达 ±50ms 以上
通过 WebSocket 同步带时间戳的标注事件，而非原始帧数据
WebSocket 不传输视频帧，只传输轻量级结构化事件。每个标注动作需携带三类时间信息：
-
本地采集时间：
performance.now()记录用户点击/拖拽时刻（毫秒级，同源高精度） -
对应帧时间：
metadata.expectedDisplayTime（已减去performance.timeOrigin，转为绝对时间戳） -
服务端授时补偿：连接建立时，客户端向服务端发送
{type:'ping', t1:performance.now()}，服务端立刻回{type:'pong', t1, t2:Date.now()}，客户端计算单向延迟 ≈ (t2−t1)/2，并记录时钟偏移量
标注消息示例：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
{
"type": "label",
"frame_ts": 1718234567890.45, // 帧绝对时间戳（ms）
"local_ts": 12456.78, // 本地 performance.now()，用于抖动分析
"offset": -12.3, // 客户端时钟相对服务端的偏移（ms）
"data": { "x": 0.32, "y": 0.41, "w": 0.15, "h": 0.22, "class": "car" }
}服务端维护统一帧时序总线，做一致性仲裁
服务端不是简单转发消息，而是构建一个以视频 GOP 起始时间为基准的逻辑帧序列（例如每 40ms 一帧，对应 25fps），并为每个连接维护其上报帧时间的滑动窗口校准模型：
- 接收标注事件后，用
frame_ts + offset折算到服务端统一时间轴，落入哪个逻辑帧区间即归属该帧 - 对同一逻辑帧内收到的多个标注，按
local_ts排序并去重（防止双击或网络重传） - 当某客户端连续 3 帧的
frame_ts偏离全局帧节奏 >±15ms，主动推送校准指令{type:'resync', target_frame_ts: ...}，要求其重新对齐
客户端渲染时做动态帧补偿，确保视觉一致
多人看到的同一帧画面，可能因设备解码性能、GPU 渲染延迟不同而存在 ±2~3 帧偏差。此时不能强制跳帧，而应采用“软对齐”：
- 所有客户端共享同一个
masterClock = Date.now() − videoStartTime（服务端统一下发起播时间） - 渲染标注时，不查
video.currentTime，而是查masterClock对应的最近逻辑帧 ID，再查该帧下聚合的所有标注数据 - 若本地视频落后 masterClock >1 帧，UI 显示“等待同步中…”提示，但保持标注图层静止，避免闪烁错位
