8.1.4 管线与 seek：工程落地的暗坑（Pipelines, Seek & The Pitfalls）

前三节搭好了框架的骨架：逆运算的本质、六库的分层、收发分离的接口。本节处理剩下的硬骨头——时间与跳转。这是解码管线里最深的水域，无数播放器的花屏与音画错乱，都溺在这片水里。

PTS 与 DTS：时间轴上的双轨

第五章 5.3.1 建立过 PTS 的概念，到了 API 层，它裂解成一对必须分清的字段 [1]：

• pts（显示时间戳）：这一帧该在何时上屏，以所在流的 time_base 为单位
• dts（解码时间戳）：这一帧该在何时送进解码器

两者之间有一条铁律，官方文档写得斩钉截铁：pts 必须大于等于 dts——显示不可能先于解码 [1]。第六章 B 帧的双向预测结构，让 "解码顺序 ≠ 显示顺序" 成为日常，这对字段便是它在 API 层的落点：I/P/B 混杂的码流里，解码器按 dts 进食，播放器按 pts 上屏，两条时间轴各走各的，互不迁就。

avformat 层的 av_read_frame 给出一份体贴的保证：读出的包，pts/dts/duration 总会按流的 time_base 填好，容器给不出时会按规则猜测补齐 [1]。但保证里埋着一个例外：含 B 帧时，pts 可能为 AV_NOPTS_VALUE——此时不解码载荷，就该信赖 dts [1]。把 NOPTS 当 0 处理，是新人交的第一笔学费。

seek 的三层组合拳

用户拖动进度条的一瞬间，播放器要面对 8.1.1 留下的那个推论：解码器的任何输入都不能假设 "从第一帧开始"。参考帧缓冲里全是旧位置的上下文，直接续播必花屏。正确的 seek 是一套三层组合拳 [1][2]：

• 定位：av_seek_frame 的职责是 seek 到关键帧——配上 AVSEEK_FLAG_BACKWARD，取目标时刻之前最近的关键帧 [1]。为什么必须是关键帧？第七章 TS 分片的 PAT/PMT、HLS 的关键帧边界，道理一脉相承：只有关键帧能独立解码，从这里重启才不会带着对旧参考帧的依赖
• 清场：avcodec_flush_buffers() 重置解码器内部状态、冲刷内部缓冲 [1]——省略这一步，seek 前缓存的参考帧会混进新位置的解码，花屏的根因十有八九在此
• 甄别：avformat 与 avcodec 都清了，管线队列里还可能躺着 seek 前已解出的旧帧。ffplay 的解法是 PacketQueue 上的 serial 序号：seek 时序号自增，消费者见到旧序号的帧一律丢弃 [2]——没有原子清空队列的黑魔法，就用版本号让旧数据自然失效

三层各管一段，缺一则事故。这套组合拳也是检验播放器成色的试金石：能正确 seek 的播放器，管线设计多半差不到哪去。

参考实现的工程形态：ffplay 线程管线

把以上所有零件装成整机，工业界有一份公开的参考答案——FFmpeg 自带的 ffplay。它的线程形态是播放器管线的标准教科书 [2]：

• 三线程结构：主线程专职渲染；read_thread 专职解封装、向队列喂包；每个解码器各配一个解码线程（音频、视频各一）
• 队列解耦：线程之间以 PacketQueue（压缩包）与 FrameQueue（解码帧）衔接——每级消费者按自己的节奏取用，生产者不被拖累
• 条件变量节拍：队列满时生产者挂起等待（ffplay 用 continue_read_thread 条件变量），消费后唤醒——背压思想在管线级的重演

"解耦用队列、节拍靠条件变量"，这十二个字概括了播放器管线的标准工程形态。8.3 的实战里，我们自己的简易播放器将复刻这个形态——只不过用 Python 与 PyAV 改写。

小结：骨架已成，灵魂何在

回看 8.1 全节：逆运算的本质、六库的正交、收发分离的状态机、时间与跳转的暗坑——解码器框架的骨架已然成型。但一台只有解码器的机器还不会 "播放"：帧解出来了，何时上屏？音画两条线，向谁对齐？这些问题的答案不在解码器里，而在播放器的心脏。下一节，播放器核心系统。