8.2.3 抖动缓冲：与网络和解的艺术
8.2.2 解决了播放器内部的宪政问题，但帧不是从解码器里长出来的——它们从网络来。而网络的脾气，第七章已经领教过：RTMP 的块流会堵车，HLS 的分片会迟到，Wi-Fi 的信号说没就没。到达间隔忽快忽慢，这就是抖动（Jitter）。播放器若网络给多少吃多少，画面节奏就会被网络的喷嚏带着走。抖动缓冲的职责，是把一条崎岖的供给曲线，熨成一条平滑的消费曲线——代价只有一个：延迟。这一节，看工程如何在这对冤家之间讨价还价。
缓冲的本质：用空间换时间
缓冲区的原理朴素得像水库：上游洪水与枯水交替，下游要求水流恒定，那就筑坝蓄水。雨季存下的水，旱季放出去。网络快时多收帧存着，网络慢时吃库存——水位涨落之间，观众的播放头始终感知不到上游的风浪。
但水库不能无限大。缓冲即延迟：播到第 10 秒的画面时，缓冲区里躺着的可能是第 15 秒的内容——水位有多深，观众离 "现在" 就有多远。点播场景里这只是进度条的虚位，直播场景里却是真金白银的体验：球赛进球的欢呼从隔壁传来，你的屏幕还在中场倒脚。抖动缓冲的全部设计，都在回答同一个问题：用多少延迟，换多少平滑。
ffplay 的双门限：帧数与时长的联合作证
先看不等网络时缓冲水位管什么——8.2.1 已经见过它的内存闸门角色：PacketQueue 上限 15MB，超限读线程暂停 [2]。连上网络，水位还担起第二份差事：起播与续播的判决。ffplay 的条件是双门限 [2]：
为什么要两道闸，一道不够吗？单看帧数，字幕这类稀疏流可能攒半分钟也凑不够 25 条；单看时长，低码流音频 1 秒可能只有两三个包，水位虚高。帧数管 "够密"，时长管 "够长"，联合作证才排除两类错觉。这套双门限在每次卡顿后还会重演——缓冲被打穿、队列见底时，播放器回到续播等待，重新攒够双门限再启程。观众看到的 "转圈"，就是这场重新蓄水。
水位还有更细的颗粒度：已解码帧的 FrameQueue 只留极小窗口——视频 3 帧、音频 9 个采样块、字幕 16 条 [2]。解码后的帧是重资产，库存越小，seek 时作废的代价越低（8.1.4 的 serial 甄别也因此轻快），延迟也因此可控。压缩侧宽、解码侧严，两级水位的宽窄搭配，藏着对内存、延迟、跳转成本的三方妥协。
跷跷板的两端：起播延迟与卡顿率
缓冲水位调多深，是流媒体产品最经典的权衡，没有最优解，只有立场：
- 水位深：抗抖动能力强，卡顿率低——代价是起播慢、直播延迟高
- 水位浅：起播快、延迟低——代价是网络稍一咳嗽，画面就转圈
第七章的低延迟直播（7.4）把这条跷跷板压到了极限：LL-HLS 用部分分片把水位削到亚秒级，代价是对网络质量的苛刻要求；而传统 HLS 默认三片缓存、十几秒延迟，换的是地铁里也能稳播的从容。同一套水位逻辑，产品按场景投票——体育直播押浅水位，追剧点播押深水位。
8.2.2 的外部时钟调速，其实是这条跷跷板上的第三只手：水位快见底时不立刻停播，先降速 10% 撑一会儿——用几乎不可察觉的变速，换取缓冲重新蓄水的时间。停播是亮红灯，降速是黄灯滑行，工程的分寸感全在这些过渡带里。
小结：缓冲是播放器的谦逊
抖动缓冲承认了一个事实：网络不在播放器的管辖范围内。主时钟管内部秩序，缓冲管外部无常——一内一外，播放器的核心系统至此闭环。剩下的最后一段旅程，是帧离开播放器前的临门一脚：YUV 数据如何变成屏幕上的光。下一节，渲染管线。