WebSocket仅提供通信通道，音画同步需应用层实现：服务端统一授时并分发含render_ts的时间戳帧，客户端通过ping-pong校准时钟、按render_ts调度渲染，并结合丢帧重传与音画差值动态重同步。
WebSocket 本身不提供音画同步能力，它只是双向实时通信通道。音画同步校准必须在应用层结合时间戳、网络延迟估算和播放端缓冲控制来实现。核心思路是：服务端统一授时 + 客户端本地时钟对齐 + 基于时间戳的渲染调度。
服务端统一时间戳生成与分发
所有音视频帧都携带服务端生成的绝对时间戳（如 Unix 毫秒 + 微秒级偏移），而非相对 PTS。推荐使用高精度单调时钟（如 process.hrtime()）配合 NTP 校准后的系统时间，每帧附带：
- server_ntp_time：服务端当前 NTP 时间（毫秒，已校准）
- frame_id 和 media_type（audio/video）
- render_ts：该帧应在客户端本地时钟的哪个时刻渲染（单位毫秒，由服务端根据目标播放位置 + 预估端到端延迟计算得出）
WebSocket 消息格式示例（JSON 或二进制）：
{
"type": "media_frame",
"media": "video",
"frame_id": 12345,
"render_ts": 1718923456789, // 客户端应在此刻显示该帧
"data": "base64..."
}客户端时钟对齐与延迟估算
仅靠服务端时间戳不够，需补偿网络传输抖动和客户端处理延迟。客户端启动时执行一次或周期性地进行时钟同步：
立即学习“前端免费学习笔记（深入）”；
- 发送
{"type":"ping","t1":Date.now()}到服务端 - 服务端立即回传
{"type":"pong","t1":t1,"t2":server_time_now} - 客户端收到后记录
t3 = Date.now()，估算往返延迟rtt = t3 - t1，并推算服务端时间偏移：offset = (t2 - t1) + (t2 - t3) / 2 - 后续所有
render_ts都按此 offset 校正为本地可比时间
建议每 10–30 秒重做一次 ping-pong，用滑动窗口平滑 offset 和 rtt 值。
基于时间戳的播放调度与动态校准
客户端不按接收顺序播放，而按 render_ts 排序并调度：
- 维护一个最小堆（或有序数组）缓存已接收但未到渲染时刻的帧
- 用
requestAnimationFrame或setTimeout（精度要求高时可用performance.now()+ 自旋等待）驱动渲染循环 - 每一帧实际渲染前，检查
render_ts - offset是否已到达；若滞后 > 50ms，丢弃该帧并告警；若提前过多（> 500ms），插入静音/冻结帧，或动态调慢解码节奏 - 音频采用 Web Audio API 的
AudioContext.currentTime精确调度；视频用HTMLMediaElement不适用，建议用OffscreenCanvas+requestVideoFrameCallback（Chrome 94+）或createImageBitmap渲染
异常处理与容错机制
真实网络下必然存在乱序、丢包、延迟突增。需补充：
- 帧内带序列号（
seq），客户端检测丢帧并请求关键帧（通过 WebSocket 发送{"type":"request_keyframe"}） - 为每个媒体流维护独立的“理想播放线”（Ideal Play Time Line），根据最近 5 个成功渲染帧的
render_ts斜率，预测下一帧应到时间，用于判断是否需要加速/减速 - 当音画 render_ts 差值持续 > 80ms，触发重同步：暂停视频、跳转音频播放位置（Web Audio 的
start(when, offset)）、再恢复 - 所有时间相关操作统一使用
performance.timeOrigin + performance.now()，避免Date.now()被系统时钟调整干扰
