看直播的时候，有没有遇到过这样的情况：主播张嘴说话，但声音却慢了半拍？或者打游戏时，画面已经爆炸了，音效才姗姗来迟。这种音画不同步的问题，背后往往和视频流的时间戳同步机制有关。
时间戳不是装饰，是协调员
在视频流传输中，每一帧画面和每一段音频都有自己的“出生时间”，也就是时间戳（Timestamp）。它不是简单地记录一下时间，而是告诉播放器：“我该在什么时候被展示”。如果这些时间戳乱了，播放器自然就搞不清节奏，导致画面和声音对不上。
举个生活中的例子：就像两个朋友约好一起进电影院，一个看画面，一个听声音。如果他们拿到的入场时间写错了，一个人早到，一个人迟到，那看到的场景和听到的对白肯定对不上。
网络传输让时间戳更复杂
在本地播放一个视频文件，时间戳相对容易管理。但在网络架构中，视频流通常会被拆成多个小包，经过不同的路径传输。有些包走得快，有些走丢又重发，到达顺序可能乱七八糟。
这时候，播放器不能只按收到的顺序播放，而要依靠时间戳重新排序。比如 RTP 协议中，每个数据包都带有一个时间戳字段，用来表示该包中媒体数据的采样时刻。
RTCP Sender Report 中的时间戳示例：
NTP timestamp: 0xC95C572A.1D897C3E
RTP timestamp: 0x12345678
Sender's clock rate: 90000 Hz这里的 RTP 时间戳以媒体时钟为基准，比如视频常用 90000 Hz，意味着每秒有 90000 个时间单位。哪怕网络抖动，只要时间戳准确，播放器就能算出正确的播放时机。
同步不只是音画，还有多路流
在视频会议或监控系统中，经常需要同时处理多路视频流。比如主摄像头、辅屏共享、远程参与者画面。这些流来自不同设备，时钟源不一致，时间戳自然也不统一。
这时候就需要一个“公共参考时间”，通常是通过 RTCP 的 NTP 时间戳来实现。各路流把自己的 RTP 时间戳和全局 NTP 时间关联起来，播放端就能把它们对齐到同一个时间轴上。
实际开发中的坑
很多开发者在封装视频流时，直接用系统时间生成时间戳，忽略了时钟频率的转换。比如 H.264 视频以 90000 Hz 为基准，但代码里却用了毫秒直接乘 1000，结果时间戳精度不够，久了就会漂移。
正确做法是根据帧率计算增量。例如 30fps 的视频，每帧时间戳应增加 90000 / 30 = 3000：
// 示例：生成连续的时间戳
uint32_t base_timestamp = 0;
uint32_t clock_rate = 90000;
float fps = 30.0;
uint32_t increment = (uint32_t)(clock_rate / fps);
// 每编码一帧，增加时间戳
base_timestamp += increment;另外，网络传输中还要注意时间戳的起始值随机化，避免每次从 0 开始造成同步混乱。
用户感知不到的技术细节
做得好的时间戳同步，用户根本不会注意到它的存在。只有当它出问题时，才会被骂“这直播怎么嘴型对不上”。在网络架构设计中，这类底层细节往往决定了最终体验的流畅度。
无论是做直播推流、点播服务，还是搭建视频会议系统，都不能忽略时间戳的准确性。它不像分辨率那么显眼，也不像码率那样直接影响清晰度，但它决定了你能不能“声画合一”地看完一场球赛。”}