VideoFrame.timestamp 是一个以微秒为单位的呈现时间戳（PTS），表示该帧预期被显示的时间点，而非采集、接收或启动时间；它不对应真实世界时钟，也不适用于直接测量 WebRTC 端到端延迟。
videoframe.timestamp 是一个以微秒为单位的呈现时间戳（pts），表示该帧**预期被显示的时间点**，而非采集、接收或启动时间；它不对应真实世界时钟，也不适用于直接测量 webrtc 端到端延迟。
VideoFrame.timestamp 是 WebCodecs API 中 VideoFrame 接口的关键属性，其定义明确为 Presentation Timestamp（PTS），即“呈现时间戳”。根据 W3C WebCodecs 规范，该值表示该视频帧应在播放时序中被渲染的逻辑时刻（相对于媒体时间轴），单位为微秒。它本质上是解码器/播放器调度系统用于维持正确帧率、处理 B 帧依赖、实现音画同步等目的而使用的内部时序参考。
⚠️ 需特别注意以下几点：
-
非 Wall-Clock 时间：
timestamp不反映真实世界中的绝对时间（如Date.now()或performance.now()），也不对应帧在服务器端生成、网络到达客户端、或<video></video>元素开始播放的任意物理时刻； -
相对且源依赖：其起始零点（
0）由媒体源决定——例如，MediaStreamTrack 可能以第一帧采集时间为0，而编码后的 MP4 文件可能以moov中的mvhd时间刻度为基准。不同来源、不同编码器甚至同一设备的不同会话都可能导致 PTS 偏移不一致； - 不保证单调或连续：在存在丢帧、重传、解码错误或播放速率调整（如变速播放）时，PTS 可能出现跳变、重复或非线性增长；
-
不可用于跨设备时间对齐：由于缺乏 NTP/PTP 级别的时间同步机制，两个独立设备上的
VideoFrame.timestamp无法直接比对以计算端到端延迟。
✅ 若你正尝试评估 WebRTC 流的端到端延迟（如从摄像头采集到远端画面渲染），不应依赖 VideoFrame.timestamp。更可靠的方法包括：
-
使用 WebRTC 内置统计接口：
RTCRtpSender.getStats()和RTCRtpReceiver.getStats()提供标准化的延迟相关指标，例如：const stats = await pc.getStats(); stats.forEach(report => { if (report.type === 'inbound-rtp' && report.mediaType === 'video') { console.log('Round-trip time (RTT):', report.roundTripTime, 's'); console.log('Jitter:', report.jitter, 's'); // 注意：endToEndDelay 并非标准字段，但部分浏览器（如 Chrome）实验性支持 } }); 主动打点法（需协同设计）：
在发送端注入带时间戳的视觉标记（如闪烁像素、数字水印或音频提示），接收端通过requestVideoFrameCallback+performance.now()捕获渲染时刻，再结合已知的发送侧performance.now()差值估算延迟（需考虑本地时钟漂移补偿）。服务端辅助方案：
若可控信令与媒体服务器（如 SFU），可在关键帧头部嵌入 NTP 时间戳，接收端解析后与本地高精度时钟比对——但这已超出纯客户端VideoFrame能力范围。
总之，VideoFrame.timestamp 是媒体流水线内部的呈现调度信号，价值在于保障播放质量，而非提供可观测的延迟度量。在构建低延迟 WebRTC 应用时，应优先采用 WebRTC 标准统计、RTT 估算及端到端主动探测等经过验证的工程实践。
