做音视频开发这几年，要说哪个概念最容易被新手搞混，时间戳绝对排得上号。很多人在处理播放器卡顿、音画不同步、转封装报错时，排查半天发现根因都是对时间戳的理解有偏差。这篇文章就把这块内容掰开揉碎讲清楚，涵盖PTS/DTS的区别、时间基的换算、音视频同步的实现方式，以及实际开发中常见的时间戳问题排查方法，希望对你有所帮助。

1. 为什么时间戳是音视频开发的基石

1.1 没有时间戳，画面和声音就是一团乱码

想象一下这样一个场景：你面前有两条独立的传送带，一条运输视频帧，一条运输音频采样。视频帧每秒25个，音频采样每秒48000个，它们各自按照自己的节奏从编码器出来，然后在播放器端汇聚。如果没有某种时间上的标签去告诉播放器"这一帧画面应该在第几毫秒显示""这一段声音应该在第几毫秒播放"，那么播放器面对的就是一堆毫无顺序可言的二进制数据。

时间戳就是贴在这堆数据上的时间标签。它让播放器能够明确知道：

• 每个视频帧应该在什么时刻显示在屏幕上
• 每段音频采样应该在什么时刻从扬声器播出
• 视频帧和音频帧之间的相对时间关系是什么

没有这套标签系统，你看到的视频就会像被搅碎的拼图，音频也会变成不知所云的噪音。这就是为什么我在面试音视频开发岗位的候选人时，第一个问题往往是"你们项目里的PTS和DTS分别是干什么的"——基本上一问就知道对方是真正写过播放器逻辑，还是只在网上看过几篇概念文章。

1.2 从一次真实的音画不同步调试说起

去年我接手过一个短视频剪辑项目的优化工作，用户反馈在导出视频后，画面和声音会出现明显的错位，而且错位的幅度随着视频时长逐渐增大，到第10分钟时已经滞后将近两秒。排查过程非常典型：先看编码参数，再看解码器设置，最后定位到时间戳处理逻辑上。

项目里视频采集模块基于Camera2 API，音频采集模块基于AudioRecord，两者分别独立运行。视频模块每采集一帧回调就打包一次数据，音频模块则每20毫秒打包一次数据。问题出在打包时的时间戳计算方式上——视频模块用了 System.currentTimeMillis() 作为基准，音频模块则用了 AudioRecord.getTimestamp() 的纳秒时间，两个时间源本身存在偏差，而且每次回调的处理耗时也会累积进时间戳里。

这类问题在音视频开发中太常见了。时间戳的核心作用，就是为不同来源、不同帧率、不同采样率的数据流建立一条统一的时间轴。理解它，你才能避免很多低级但致命的bug。

1.3 时间戳在不同环节的形态差异

一个完整的音视频处理链路，大致可以分成采集、编码、封装、传输、解封装、解码、渲染七个环节。时间戳在每个环节的表现形式是不同的：

环节	时间戳形态	精度	说明
采集	系统时钟时间	微秒~纳秒	依赖于硬件时钟，Camera和Mic各自维护
编码前	原始时间戳进行转换	微秒	统一到同一时间基准，便于编码器参考
编码后	PTS/DTS（基于时间基）	与时间基相关	编码器重新标记，受GOP结构和B帧影响
封装	对应容器格式的时间戳	取决于封装格式	MP4用时间单位（基于track的timescale），TS用33位90kHz计数器
解码后	解码器输出PTS	与时间基相关	解码器按输入帧的PTS标记输出
渲染	呈现时间戳	毫秒/纳秒	与显示设备的刷新率和音频设备的时钟同步

不同环节的时间戳必须能够互相换算，而换算的核心就是时间基（time_base）。下一节详细展开。

2. 时间戳的核心概念：PTS、DTS与时间基

2.1 PTS与DTS：显示顺序和编码顺序是两码事

PTS全程Presentation Time Stamp，即显示时间戳，表示这一帧数据应该什么时候展示给用户。DTS全程Decoding Time Stamp，即解码时间戳，表示这一帧数据应该什么时候送入解码器。

在理想情况下，PTS和DTS是相同的。但在视频编码中引入B帧（双向预测帧）后，两者就分道扬镳了。

B帧的特点是需要参考前后的帧才能解码，所以编码器在输出时会把B帧调整到它参考的帧之后。举个例子，一段视频帧的显示顺序是I帧、B帧、P帧、B帧、P帧（即IBBPBBP），但编码后的比特流顺序可能变成了I帧、P帧、B帧、P帧、B帧。解码器必须按照比特流中的顺序（也就是DTS）依次解码，但渲染器必须按照原始顺序（也就是PTS）来显示。

我第一次理解这个概念时，脑海里浮现的画面是排队进电影院——DTS是入场检票的顺序，PTS是大家按照票面座位落座的顺序。检票员（解码器）必须按队伍顺序放人进去，但座位号（PTS）决定了每个人最终坐在哪里。

在FFmpeg中，每个AVPacket（未解码的数据包）和AVFrame（解码后的帧）都带有pts和dts字段。日常开发中有一个重要经验：解封装拿到的packet直接送入解码器时，解码器内部是按dts的顺序处理的，输出frame时会把pts一起带上。我们做播放器渲染时，必须以frame的pts为准，绝对不能以入队顺序为准。

2.2 时间基：时间戳的刻度尺

时间基（time_base）描述了时间戳的精度。它是用有理数表示的，例如 1/90000 就表示时间戳的每个单位对应1/90000秒，也就是大约11.1微秒。

这里必须强调一个初学者最容易踩的坑：不同格式的时间基不一样。MP4格式的timescale通常取90000，因为MPEG-TS标准使用90kHz的时钟；MP4内部track的timescale则可以由编码器自己定义，常见的有15360（基于48kHz音频的320倍）、16000、90000等；而FLV格式则统一使用毫秒（timescale为1000）。

时间戳换算的核心公式极其简单：

实际时间（秒） = 时间戳值 / timescale

反过来：

时间戳值 = 实际时间（秒） × timescale

在FFmpeg中，封装层一般用 AVStream.time_base 表示流的时间基。解封装拿到packet后，packet.pts就是以这个time_base为单位的值。解码器输出的frame，其pts也是以这个time_base为单位。我们做渲染时如果要换算成毫秒，就要做如下换算：

double timestamp_ms = frame->pts * av_q2d(stream->time_base) * 1000;

这段代码做了三件事：取帧的pts值，乘以时间基对应的有理数（av_q2d返回的是time_base.num除以time_base.den的浮点值），得到以秒为单位的实际时间，再乘以1000转成毫秒。

2.3 AVRational与时间基的计算

FFmpeg中用AVRational结构体表示有理数：

typedef struct AVRational {
    int num;   // 分子
    int den;   // 分母
} AVRational;

保留有理数而不是直接用浮点数，是为了避免浮点误差在长视频中累积。比如1/44100和0.0000226757之间存在细微差异，单次计算看不出来，但一帧一帧累积下去，到几百万帧之后就会出现肉眼可见的偏差。

FFmpeg提供了一组专门处理时间基换算的API：

• av_q2d(AVRational a) ：转为double类型
• av_rescale_q(a, b, c) ：将数值a从时间基b换算到时间基c
• av_rescale_q_rnd(a, b, c, rnd) ：上述换算的取整版本，可指定舍入方式

实际开发中时间基换算的一个高频代码如下：

// 将packet的pts从stream的time_base换算到dst_time_base
int64_t new_pts = av_rescale_q_rnd(pkt->pts,
                                   in_stream->time_base,
                                   out_stream->time_base,
                                   AV_ROUND_NEAR_INF | AV_ROUND_PASS_MINMAX);

这里用了 AV_ROUND_NEAR_INF | AV_ROUND_PASS_MINMAX 两个标志位，前者表示四舍五入取整，后者保证INT64_MIN和INT64_MAX这两个特殊值能被原样传递而不溢出。

2.4 起始时间戳的规范化问题

很多刚接触音视频开发的同学会遇到这样一个困惑：从摄像头采集到的第一帧视频的时间戳可能不是从0开始的。这在直播场景中很常见，因为采集模块通常使用系统启动时间作为基准。直接把这个原始时间戳用于编码和封装，虽然也能工作，但会导致两个问题：

• 生成的视频文件起始时间不是0，某些播放器会显示异常
• 多路流（比如音视频两路）的起始时间戳不一致时，封装的音视频不同步概率极大

规范做法是在封装前做一次偏移校正：记录第一帧的pts为 start_time ，然后每一帧的pts都减去 start_time 。如果音频和视频起始点不同，也要统一对齐到同一时刻。

这类代码写起来不复杂，但仍值得注意。以FFmpeg为例，在muxing之前对含B帧的视频做偏移时，必须以DTS的最小值作为基准，而不是PTS的最小值。因为解码顺序上包是乱序的，PTS最小的那帧不一定是第一个被写入的包。

3. 音视频同步：时间戳的终极应用

3.1 三种主流同步策略

音视频同步是播放器开发的核心挑战之一，其本质是让音频和视频按照各自的时间戳正确呈现。目前主流的同步策略有三种：

以音频为基准（Audio Master） ：播放器维护一个audio clock，持续追踪当前正在播放的音频帧的pts。视频渲染时，将视频帧的pts与audio clock比较，如果视频帧提前到达，则等待；如果视频帧晚到，则丢弃或跳帧。

以视频为基准（Video Master） ：与上面相反，以视频输出的节奏为基准，音频做调整。这种方案的问题在于音频的调整（变速或跳过采样）比视频掉帧的听感更明显，所以实际产品中很少用。

以系统时钟为基准（External Clock Master） ：播放器维护一个独立的参考时钟，音频和视频分别与参考时钟比较。这种方案复杂度更高，但灵活性也更强，适合需要精确控制起播和跳转的场景。

实际开发中，以音频为基准是最常见的方案。原因很朴素：人耳对声音的时序变化比对画面的时序变化敏感得多。视频偶尔掉一帧观众往往察觉不到，但音频如果出现断音或变速的顿挫感，体验会大打折扣。

我自己写播放器时，代码结构大致是：

// 计算avsync delay
int64_t audio_clock = get_audio_clock();          // 音频时钟，取自音频设备缓冲区的pts
int64_t video_pts = get_video_pts();              // 当前待渲染的视频帧pts
int64_t diff = video_pts - audio_clock;
int64_t threshold = 40 * 1000;                    // 40ms阈值
if (diff > threshold) {
    av_usleep(diff);                              // 视频快于音频，睡一会儿
} else if (diff < -threshold) {
    drop_video_frame();                           // 视频慢于音频，直接丢帧
}

3.2 同步中的缓冲与延迟折衷

同步策略写起来不复杂，但工程上真正的难点在于平衡延迟与同步的精度。缓冲区越大，音视频同步的抖动越小，但延迟就越高。以直播场景为例，行业里常见的目标端到端延迟是2至5秒，在这个范围内要做到音画同步，一般需要将同步误差控制在40毫秒以内（针对音频驱动的视频渲染）。

具体到播放器内部，通常的做法是维护一个音频输出缓冲区和视频帧队列。音频缓冲区由底层音频设备驱动消费，视频帧队列由渲染线程按照pts调度。简单来说就是：渲染线程读取一帧视频，比较它的pts和当前音频播放位置，他早到就等，晚到就丢。工程上的一个常见调优点是这个40毫秒阈值的选取。设得太小，网络抖动稍大就会频繁丢帧，画面跳跃感强；设得太大，肉眼能看到明显的声画错位。根据我的经验，在普通网络环境下40到80毫秒是一个不错的区间，你可以在你的播放器里做成可配置参数，按实际测试效果调整。

3.3 音频时钟的正确获取方式

音频时钟直接决定了同步的准确性。很多新手会犯一个错误：用音频解码线程当前解码到的帧的时间戳作为audio clock。这是不准确的，因为解码线程通常会比渲染超前几百毫秒（内部有预读缓冲）。正确的做法是以音频设备实际播放的位置为准。

在Android的AudioTrack场景中，可以用 AudioTrack.getPlaybackHeadPosition() 获取已经播放的帧数，除以采样率得到当前播放位置。在iOS的AudioQueue场景中，可以通过提交的buffer和已经播放的sample数推算。而在桌面端的SDL2场景中，FFmpeg自带的 audio_clock 更新逻辑是基于每个packet送入设备的时间戳再减去设备缓冲时长的估算值。

需要特别提醒的是，Android的 getPlaybackHeadPosition() 在暂停和刚启动时会有些怪异行为，我已经不止一次遇到过这个API返回0的情况。稳妥的姿势是同时记录一个 last_pos 和 last_pos_update_time ，当发现返回值回退时使用上一次的值，继续推进时再更新，这样可以保证这个数据源的可靠性。

4. 实操：FFmpeg转封装中的时间戳处理

4.1 一个转封装场景的具体处理过程

结合具体场景来看，这是最近一个下项目里实际遇到的问题：项目需要从RTSP流中实时拉取视频，转封装为FLV推送到直播服务器。原始RTSP流中视频是H.264，音频是AAC，两者都带有时间戳。但推流时如果不做时间戳处理，直播画面会卡顿，或者延迟越来越大。

处理流程大致分四步：

第一步，解封装并获取流信息。 使用 avformat_open_input 打开RTSP地址， avformat_find_stream_info 解析流信息。此时每个AVStream的time_base已经由解封装器自动设置完成。

第二步，创建输出封装上下文。 调用 avformat_alloc_output_context2 创建FLV封装器。值得注意的是，FLV封装器要求的time_base是1/1000（毫秒）。这与RTSP内部的time_base可能不同，所以要为每个输出流设置time_base。

第三步，逐帧读包并做时间戳换算。 从输入读到的AVPacket，已有其pts和dts（都以输入流的time_base为单位）。转封装时，需要将pts和dts换算到输出流的time_base下。

av_packet_rescale_ts(pkt, in_stream->time_base, out_stream->time_base);

这个函数是我日常用的最多的一个时间戳换算API，它内部就是对pts、dts和duration同时做 av_rescale_q_rnd 换算。

第四步，检查并修正时间戳顺序。 FLV是流式格式，每个tag的时间戳必须单调递增。如果发现当前的dts小于上一个包的dts（回退），需要做钳制处理，把它强行设置为上一个dts的值。在实际经验中，个别编码器在关键帧附近会出现时间戳轻微波动，如果不对这种回退做处理，会直接导致播放端卡顿甚至断流。

4.2 转封装中duration字段的处理和B帧的坑

转封装时很多人只关注pts和dts，容易忽略duration字段。实际上，FFmpeg在部分封装格式（如FLV）中会用duration来计算后续包的时间戳。如果duration缺失或为0，会导致音频帧的间隔计算错误。

处理方式是在读包后判断：

if (pkt->duration <= 0) {
    pkt->duration = av_rescale_q(1, in_stream->time_base, out_stream->time_base);
}

这种方式对于固定帧率的内容是可行的。但如果帧率不固定，更稳妥的做法是从相邻帧的pts差值推导duration。

另一个高频坑是含B帧视频的PTS/DTS顺序问题。常规的H.264码流中，同一轨的视频包的DTS序列是严格递增的，但PTS序列可能不是单调的（因为B帧）。在做时间戳钳制时，必须对DTS做单调性检查，而不是PTS。原因很简单：封装器写数据时是按照DTS（解码顺序）写入的，DTS回退会导致封装器崩溃或产出非法文件。PTS在严格单调递增的播放场景中不是必须的，而且处理逻辑上它一个微小的回退，往往是正常现象。

4.3 音频时间戳的特别说明

音频时间戳的处理看起来比视频简单，但也有一些容易忽略的细节。AAC是带帧的编码格式，一个AAC帧固定包含1024个采样点。在采样率为44100Hz的情况下，一帧时长为1024/44100秒，约23.2毫秒。如果时间基是1/44100，那么每帧的时间戳增量就是1024。

但在一些异常流中，音频的pts增量不总是恒定的。例如某些采集设备在CPU繁忙时偶尔会重复或丢失音频帧。做转封装时，如果发现音频帧的pts跳变过大（超过单帧时长的两倍），基本可以判定为采样缺失。对这种流，上游的采集逻辑需要修复，而不仅仅是调时间戳。

音频时间戳处理的另一个特殊性在于编码延迟。AAC编码器通常在编码前会引入一定的priming samples（ZOH/FE），也就是编码器的内部延迟，这部分采样在解码时需要特殊处理。在MP4封装中，会有一个叫edit list的机制来标记这些延迟采样。如果你转封装时没有处理这个信息，在部分播放器上会出现开头的一小段音频与画面错位。

5. 时间戳相关的常见问题与排查思路

5.1 音画不同步

这是时间戳问题的头号症状。排查时按优先级顺序依次检查：

• 音频时钟是否取到了真实播放位置，而不是解码位置
• 视频帧的pts是否在送入渲染队列前被篡改
• 编码器是否开启了B帧，B帧的DTS/PTS是否正确
• 是否使用了不同的时钟源（比如一个用系统当前时间毫秒，一个用AudioTrack位置）

我踩过的一个极为隐蔽的坑是：在AR眼镜项目里，视频源是摄像头传感器直接输出的，帧率固定在30fps，但实际帧到达的时间间隔偶尔会跳到50毫秒以上。此时如果按固定帧间隔去推算时间戳，误差就会累积。解决思路是从数据包里读取硬件时间戳。这类问题在嵌入式场景中尤其常见，软件时间戳会被线程调度、CPU频率波动干扰，所以遇到高精度同步要求时，优先使用硬件时间戳通道。

5.2 关键帧后的卡顿或快进

症状是播放到关键帧附近时画面卡一下，然后快速跳过几帧。这类问题多半是I帧的PTS和前后P帧的PTS不连续导致的。有些编码器在插入GST（序列头）或SEI时，没有正确递增PTS，导致PTS出现一个跳变。播放器检测到PTS大幅度跳跃后，会触发快进逻辑。

排查方法：使用FFmpeg命令行工具逐帧打印PTS和DTS，观察跳跃点的具体情况。

ffprobe -show_packets -select_streams v -print_format json input.mp4 | jq '.packets[] | {pts, dts, flags}'

如果发现跳跃总在I帧附近，基本上就是编码器的GOP间隔设置或SEI插入逻辑有问题，需要去编码器侧修改参数。

5.3 播放器起播慢

起播慢的常见原因之一，是播放器在等待首帧PTS为0的数据。但很多格式的首帧PTS并不为0。处理方式是：播放器需要计算出所有流的偏移量（每路流的首帧PTS与全局最小PTS的差值），然后在音视频同步时应用这个偏移。具体来说，播放器应该将第一帧视频PTS作为基准，后续所有帧PTS都减去这个基准值，再与audio clock比较。

5.4 转封装后文件无法播放

用FFmpeg转封装后输出的文件在某些播放器上播放异常，原因通常是没有正确设置输出流的time_base。在 avformat_write_header 之前，必须调用：

out_stream->time_base = (AVRational){1, 1000};

否则封装器可能使用默认值（通常是1/90000），而FLV封装器内部计算时间戳时按毫秒处理，就会产生1000/90000的换算误差，播放器端每帧时间都会错乱。

5.5 音频早于视频开始导致的开头静音段

常见于从采集端开始就使用不同时间戳基准的项目中。如果音频的PTS比视频的PTS整体小200毫秒，在播放器里表现为开头画面还没出来，声音已经开始了。排查时需要打印两端流的前几帧PTS做对比。我在实际项目中输出过类似下面的数据：

video: pts=0, time=0.000s
video: pts=3000, time=0.033s
audio: pts=0, time=0.023s
audio: pts=1024, time=0.047s

第一帧音频的时间是23毫秒，第一帧视频的时间是0毫秒，两者差了23毫秒。这个偏差在这个量级一般没问题，但如果超过80毫秒，播放器就需要做音画对齐处理。对齐的标准做法是：将音频整体延迟输出，或者视频端增加等待时间。注意，调整结束后要保持相对偏移不变，不能在播放过程中频繁修正，否则会出现持续的抖动感。

6. 工具与命令行技巧：用ffprobe快速检查时间戳

看遇到时间戳问题，我习惯先用FFmpeg自带的工具做快速排查，这样可以快速定位大概方向，比直接读代码高效得多。

6.1 用ffprobe查看流的time_base

ffprobe -show_streams -select_streams v -print_format json input.mp4

输出里重点看field的time_base值为1/90000还是1/1000或其他，以及该流的duration是否为预期的时长。如果你发现duration与实际不符，大概率是时间戳换算出了问题。

6.2 用ffprobe逐帧查看PTS/DTS

ffprobe -show_packets -select_streams v -print_format json input.mp4

会得到一个很长的JSON，里面有每个packet的pts和dts。对排查B帧问题和时间戳回退非常有用。

6.3 用ffmpeg直接修正时间戳

遇到容灾场景，比如某个视频的起始PTS不从0开始，可以直接用ffmpeg命令纠偏：

ffmpeg -i input.mp4 -muxdelay 0 -muxpreload 0 -output_ts_offset 0 -c copy output.mp4

-output_ts_offset 0 表示把输出时间戳偏移设置为0（也就是归一化到从0开始）， -c copy 表示不重新编码，只做容器层处理，速度极快。

更通用的方式是使用 -t 和 -ss 配合完成同步偏移，但这时候需要谨慎，因为 -ss 在某些版本中会重置时间戳基准，行为并不完全一致。我的经验是：能用 -output_ts_offset 解决的绝不依赖 -ss 。

6.4 关于时间戳转实际时间的工具

虽然在网络热词里经常看到"时间戳转时间"这类需求，但那通常是秒级Unix时间戳，用于日志排查。音视频开发中的时间戳是容器内的时间戳，单位取决于track的timescale，和Unix时间戳完全是两个体系的。如果确实需要把Unix时间戳（秒）转换成真正的时间，在Linux下一条命令即可：

date -d @1700000000 "+%Y-%m-%d %H:%M:%S"

顺便提一句，在排查播放器日志时，如果日志里看到的时间戳是Unix时间戳（10位或13位），可以先用这种方式转换为人可读的时间，再去对比音画不同步出现的真实时间点，能帮助你更好的定位是否是直播链路中的某处缓存问题。

在日常开发中，我每次遇到时间戳相关的疑难杂症，第一反应都是先用ffprobe把数据打出来看一眼。一个标准的时间戳问题，从数据形态上基本都能一眼判断出问题点。这是排查链路里最快、最有效的手段。

7. 项目实践中的经验沉淀

在写播放器、推流器、编辑器这些音视频应用时，我逐渐形成了一套时间戳处理的经验规范。不一定适合所有项目，但至少可以帮你少走弯路。

第一，尽可能早地统一时间戳基准。在采集端就把视频和音频的时间戳统一到同一个时钟上。如果是Android平台，可以用 System.nanoTime() （单调时钟，不受系统时间调整影响）作为公共参考。如果是iOS平台，可以用 CMClockGetHostTimeClock() 获取的统一时钟。相比用 System.currentTimeMillis() （墙上时钟，受网络对时、用户手动改时间影响），单调时钟更可靠。

第二，在数据进入任何队列之前先校正时间戳。我在播放器中会看到一个现象：解码线程从网络缓冲区取数据的耗时会影响最终音频的递送节奏。解决方案不是等到渲染时才去补偿，而是每帧读取后立即对比参考时钟并提前做偏移校正。总之，时间戳不能只在最后一步处理，每一层处理时都要保证时间戳的正确性。

第三，所有时间戳的单位互换，统一走有理数换算，绝不用double硬乘。长时间运行的音视频会话如果不使用高质量的有理数换算，误差会日积月累，到后面就会出现无法解释的抖动。FFmpeg的 av_rescale_q 、 av_packet_rescale_ts 等API，在你还没有足够的理由不使用它们之前，尽量别绕开。

第四，写日志时务必同时保留原始时间戳和换算后的实际时间。我在排查线上问题时，经常因为只看到换算后的时间而无法判断原始异常值。原始时间戳换算前可能会暴露帧间隔不稳定、时间戳回退等问题，一旦被换算成实际时间就很可能引入舍入误差，把问题掩盖过去。所以，在转发时间戳做日志记录时，建议同时打两路数值。

第五，多路流的起始时间偏差要在转封装之前解决。如果在容器里写入的第一帧音频PTS和第一帧视频PTS有偏差，很多播放器会直接认为二者不同步，进而触发各自的缓冲策略，导致整个播放体验崩坏。在做录制或推流功能时，第一帧数据的时间戳对齐我认为是仅次于内容完整性的重要事项之一。

时间戳这个话题虽然基础，但在工程实践中牵扯的问题却非常深。我希望通过这篇文章的梳理，让刚入门的朋友有一个相对完整的框架，也让已经踩过坑的同仁有几分共鸣。如果你在项目中遇到过更有意思的时间戳问题，欢迎交流，一起填坑。