4、视频时钟实现：视频帧率控制与显示时间戳，video_refresh中的时钟同步逻辑

视频时钟，说白了就是告诉播放器「这一帧该什么时候显示」。你想想看，如果没有一个精确的时钟，视频帧要么放得太快像快进，要么堆在一起卡成狗。我在项目中遇到过不少次，明明解码没问题，画面就是一顿一顿的，最后查出来都是视频时钟没校准好。

这一章，我们就深入 video_refresh 这个核心函数，看看 FFmpeg 到底是怎么用显示时间戳来控制帧率、怎么跟音频时钟做同步的。

4.1 视频帧率控制：不是你想放多快就多快

视频文件里每一帧都有一个 PTS（显示时间戳），单位通常是微秒或者基于某个时间基。播放器要做的事很简单：到了该显示的时间，就把帧送出去。

但这里有个坑——解码器可能一口气解出好几帧，而显示器刷新率跟视频帧率不一定匹配。所以 FFmpeg 在 video_refresh 里做了两件事：

• 计算当前帧应该显示多久：根据相邻两帧的 PTS 差值，得到这一帧的持续时长。
• 对比系统时钟：如果还没到显示时间，就 sleep 等待；如果已经过了，就立即显示，甚至丢帧。

核心代码逻辑大致是这样的：

// 计算当前帧与下一帧的时间差
double duration = next_pts - current_pts;
// 如果下一帧不存在，就用平均帧率估算
if (duration <= 0 || duration > 1.0)
    duration = 1.0 / fps;

// 计算当前帧实际应该显示的时间点
double delay = duration - (get_clock() - vp->pts);
// 如果 delay > 0，说明还没到时间，sleep
if (delay > 0)
    av_usleep((int64_t)(delay * 1000000));

嗯，这里要注意：get_clock() 返回的是主时钟（通常是音频时钟）的时间，而 vp->pts 是这一帧的显示时间戳。两者的差值就是「这一帧已经迟到多久」或者「还有多久才到」。

4.2 显示时间戳：PTS 是怎么算出来的？

PTS 不是凭空产生的。在解封装阶段，每个 packet 都带着时间戳信息。但到了解码后，我们需要把 packet 的 PTS 转换成 以秒为单位的浮点数，才能跟系统时钟做比较。

FFmpeg 里有一个标准做法：

// 从 AVFrame 获取 PTS，并转换成秒
double pts = frame->pts * av_q2d(stream->time_base);

这里 av_q2d 把有理数时间基转成浮点数。比如时间基是 1/90000，PTS 是 3600，那实际时间就是 3600/90000 = 0.04 秒。

我个人习惯在调试时把 PTS 打印出来，看看是不是单调递增的。如果出现 PTS 回退或者跳变，那多半是封装格式有问题，或者 B 帧的 PTS 顺序没处理好。

场景	PTS 行为	可能原因
正常播放	单调递增，间隔均匀	—
PTS 回退	后一帧 PTS 小于前一帧	B 帧重排序错误，或封装时间基不一致
PTS 跳变	间隔突然变大或变小	视频流中有 I 帧间隔不均匀，或丢帧
PTS 为 AV_NOPTS_VALUE	无法计算显示时间	某些编码器或封装不写 PTS，需要估算

4.3 video_refresh 中的时钟同步逻辑

video_refresh 是 FFmpeg 播放器里最核心的渲染调度函数。它不负责解码，也不负责渲染，只做一件事：决定什么时候把哪一帧送出去。

它的工作流程可以概括为：

1. 从帧队列取出一个视频帧（FrameQueue 里拿）。
2. 计算该帧的显示时长（duration）。
3. 获取当前主时钟时间（通常是音频时钟）。
4. 计算 delay = duration - (主时钟 - 帧的 PTS)。
5. 根据 delay 做决策：
   • delay > 0：还没到时间，sleep 等待。
   • delay < -阈值：已经迟到太多，直接丢帧。
   • 其他情况：立即渲染。

你想想看，这个逻辑其实跟「闹钟」很像。每一帧都有一个「闹钟响铃时间」（PTS），主时钟就是「当前时间」。闹钟没响就等着，响过了就赶紧做事，响过太久就算了不等了。

4.4 视频时钟与音频时钟的博弈

在音画同步中，视频时钟通常是「从属」的。也就是说，视频的显示节奏要跟着音频走。具体做法是：

• 主时钟 = 音频时钟（如果有音频流）。
• 视频帧的 PTS 与主时钟比较，决定是等待还是丢帧。
• 如果音频暂停或结束，主时钟回退到系统时钟。

这里有一个细节：音频时钟本身也是从音频设备的播放位置估算出来的，不是绝对精确。所以视频时钟在做同步时，不能完全死板地跟着音频走，否则会出现微小的抖动。

FFmpeg 的解决方案是：引入一个「同步阈值」。如果视频与音频的偏差在阈值范围内，就不做调整，让视频自然播放。只有偏差超过阈值，才主动丢帧或等待。

// 同步阈值，单位秒
#define SYNC_THRESHOLD 0.01
// 如果偏差小于阈值，不做调整
if (fabs(diff) < SYNC_THRESHOLD) {
    delay = duration;
} else {
    // 偏差太大，调整 delay
    delay = duration + diff;
}

嗯，这里要注意：diff 是视频 PTS 减去主时钟的值。如果 diff > 0，说明视频快了，需要增加 delay 等一等；如果 diff < 0，说明视频慢了，需要减少 delay 甚至丢帧。

4.5 整体流程可视化

下面这张图展示了 video_refresh 中视频时钟同步的完整流程：

4.6 实际项目中的调优建议

光看懂源码还不够，真到了项目里，你还会遇到各种奇奇怪怪的问题。我总结了几条实战经验：

• 不要死等 delay：如果 delay 很大（比如 0.5 秒），说明视频严重超前。这时候与其 sleep，不如直接丢帧，跳到最新的帧。否则用户会感觉画面「卡住不动」。
• 注意系统时钟的精度：av_usleep 的精度是微秒级，但操作系统调度可能让 sleep 多等几十毫秒。如果你做低延迟播放，建议用忙等待或者条件变量。
• PTS 异常要兜底：如果连续几帧的 PTS 都是无效值，就退回到用帧率估算。我见过某些转码工具生成的视频，PTS 全是 0，这时候只能靠帧率硬算。
• 同步阈值要可配置：不同场景对同步的敏感度不一样。直播可以容忍 50ms 的偏差，但录播可能需要 10ms 以内。把阈值做成参数，方便调优。