2. 时间模型：全局时钟、本地时钟、时间戳（RTP时间戳、PTS/DTS）
做多媒体同步，说白了就是跟时间打交道。我入行那会儿，总觉得同步不就是对个时间嘛，有什么难的？直到第一次遇到音画不同步的线上事故，才明白时间模型是整个系统的基石。这一章，我们就来拆解这个基石。
2.1 全局时钟：系统的“绝对时间”
全局时钟，你可以把它想象成整个系统的“心跳”。它提供了一个统一的、单调递增的时间基准。所有参与者——编码器、解码器、渲染器——都拿这个时间作为参考。
为什么需要它？因为每个设备都有自己的本地时钟，而本地时钟之间是有偏差的。没有全局时钟，你根本没法判断一个数据包是“早到”还是“迟到”。
核心要点：全局时钟不一定是物理上的绝对时间（比如UTC），它更多是一个逻辑上的、所有节点都认同的参考时间。在直播场景中，通常由服务器或信号源生成。
常见的全局时钟实现方式有几种：
- NTP（网络时间协议）： 通过分层的时间服务器同步，精度可达毫秒级。我在做跨地域直播时，就靠它来对齐多个机房的时钟。
- PTP（精确时间协议）： 硬件级的时间同步，精度能达到微秒甚至纳秒级。主要用于广电或专业音视频领域。
- 自定义时间源： 在封闭系统中，直接用信号源的时间戳作为全局时钟。
我的经验： 别迷信全局时钟的“绝对”二字。它只是相对统一。我曾经遇到过一个案例，NTP服务器本身因为网络抖动产生了漂移，导致所有客户端同步失败。所以，一定要给全局时钟加一个“信任但验证”的机制。
2.2 本地时钟：每个设备的“本地心跳”
本地时钟就是设备自己的晶振驱动的计数器。它便宜、易得，但精度和稳定性参差不齐。你想想看，一个手机和一个专业摄像机的晶振，能一样吗？
本地时钟有两个关键问题：
- 漂移（Drift）： 晶振频率会随温度、电压变化。两个设备即使一开始同步，过一会儿也会产生偏差。
- 抖动（Jitter）： 瞬时频率的波动，导致时间间隔不均匀。
所以，我们通常不会直接用本地时钟来做同步决策。而是用它来“锁相”——通过算法（比如PLL）跟踪全局时钟，让本地时钟的频率和相位与全局时钟保持一致。
避坑指南： 我曾经在嵌入式设备上直接拿本地时钟的毫秒数当时间戳用，结果播放器端音画不同步得一塌糊涂。后来才发现，那个设备的晶振在高温下会跑偏。记住：本地时钟只能用于相对计时，不能用于跨设备同步。
2.3 时间戳：连接数据与时间的桥梁
时间戳，就是把时间信息“贴”在数据包上。接收端拿到数据包，一看时间戳，就知道该什么时候处理它。
这里有两个最核心的时间戳概念：RTP时间戳和PTS/DTS。很多人搞混它们，其实分工很明确。
2.3.1 RTP时间戳：网络传输的“节拍器”
RTP时间戳是RTP协议头里的一个字段，32位，单位是采样率（比如音频的8kHz、视频的90kHz）。它主要用于网络层面的抖动消除和丢包检测。
它的特点：
- 单调递增： 每个数据包的时间戳都比前一个大（除非有静音包或跳帧）。
- 与采样率挂钩： 视频通常用90kHz，因为这是MPEG标准里定义的，能精确到1/90毫秒。
- 不直接表示播放时间： 它只是一个“序号”，告诉你数据包的相对顺序和间隔。
举个例子： 一个视频流，帧率30fps，那么每帧的RTP时间戳间隔就是 90000 / 30 = 3000。如果第一帧是0，第二帧就是3000，第三帧是6000。接收端看到时间戳差3000，就知道这一帧应该在上一帧之后1/30秒播放。
2.3.2 PTS/DTS：解码与渲染的“调度员”
PTS（显示时间戳）和DTS（解码时间戳）是编码器生成的，通常放在容器格式（如MP4、TS）的元数据里。它们直接告诉解码器和渲染器：
- DTS： 什么时候开始解码这个数据包。
- PTS： 什么时候把解码后的数据渲染出来。
为什么需要两个？因为有B帧（双向预测帧）。B帧的解码依赖后面的P帧，所以解码顺序和显示顺序不一样。DTS和PTS就是用来处理这个“顺序错乱”的。
| 类型 | 作用域 | 单位 | 生成方 | 主要用途 |
|---|---|---|---|---|
| RTP时间戳 | 网络传输层 | 采样率（如90kHz） | 发送端（RTP打包时） | 抖动消除、丢包检测、网络同步 |
| PTS | 解码/渲染层 | 时间基（如毫秒） | 编码器 | 控制显示时间 |
| DTS | 解码层 | 时间基（如毫秒） | 编码器 | 控制解码顺序 |
我的习惯： 在调试同步问题时，我会先看RTP时间戳是否连续。如果RTP时间戳本身就有跳变或回绕，那后面的PTS/DTS再准也没用。RTP时间戳是“第一道防线”。
2.4 三者关系：一张图说清楚
全局时钟、本地时钟、时间戳，它们不是孤立的。全局时钟提供基准，本地时钟跟踪基准，时间戳则把数据“锚定”在这个时间轴上。下面这张图展示了它们之间的协作关系。
2.5 实践中的坑与对策
理论说完了，聊聊实战。我踩过的坑，你们就别再踩了。
- RTP时间戳回绕： 32位计数器，以90kHz算，大约13小时回绕一次。直播流如果跑一天，时间戳就回绕好几次。接收端必须处理回绕，否则会认为数据包“迟到”或“早到”。我一般用模运算或扩展时间戳位宽来解决。
- PTS/DTS精度不足： 有些编码器生成的PTS精度只有毫秒级，对于高帧率视频（比如120fps），每帧间隔只有8.3毫秒，毫秒级精度根本不够。这时候需要把时间基放大，比如用微秒或1/1000秒。
- 本地时钟与全局时钟脱钩： 如果本地时钟突然因为省电模式降频，或者NTP同步失败，本地时间会瞬间跳变。我建议在同步引擎里加一个“时钟健康度”检测，一旦发现异常，立即切换到保守模式（比如用RTP时间戳的间隔来推算）。
重要提醒： 永远不要假设时间戳是完美的。编码器可能打错时间戳，网络可能乱序，接收端可能丢包。一个好的同步系统，必须能容忍这些“不完美”。我见过太多系统，因为一个错误的时间戳就导致整个播放卡死。
嗯，时间模型这部分，说白了就是给数据流“定规矩”。全局时钟定基调，本地时钟跟着跑，时间戳就是贴在数据上的“时间标签”。搞懂了这三者的关系，后面讲同步算法就轻松多了。