今年 6 月的一场解说场，主播在片中笑点后 3 秒才听到观众反应。那一场结束后我们拉了三天的链路数据，发现延迟不是单点造成的，而是四段各加了半秒到一秒：转码排队、切片时长、播放器缓冲、以及解说音轨的独立对齐。
问题一：整片排队
旧流程要求整部影片转码完成才允许排片，90 分钟的片子要等 40 分钟以上。更麻烦的是，转码任务按提交顺序排队，晚提交的短片要等长片跑完。我们把它改成两级队列：
- 首帧优先：先转前 3 分钟，完成后立即标记“可开播”，其余分片后台继续。
- 分段预取：按 6 秒切片，观众播放到第 N 片时，系统提前预取 N+3 片，避免末尾等待。
这一项把开播等待从 40 分钟压到 4 分钟，也让临时加场成为可能——9 月的影展修复单元有 3 场是当天下午才确认的。
问题二：切片太长，延迟下不来
切片 10 秒时，播放器至少要缓冲 2 片才能稳定起播，理论延迟下限就是 20 秒级的缓冲池。我们没有直接改成 1 秒切片，因为那样请求数会翻十倍，弱网下反而更容易卡。
最终采用 2 秒切片 + 关键帧对齐：画面每隔 2 秒一个关键帧，播放器可在任意切片起播；同时对弱网用户保留 6 秒切片的降级流，由播放器根据缓冲健康度自动选择。
延迟不是一个数字，而是一组取舍：切片越短延迟越低，请求越多；缓冲越小延迟越低，抗抖动越差。我们最终选的是“1.2 秒 + 0.14% 中断率”。
问题三：解说音轨拖慢了画面
解说场最初把解说音轨和正片混流后再推，混流环节需要额外 600 毫秒做对齐。现在改成双轨并行推流，观众端由播放器按选择合成：选原声就只播正片轨，选解说就叠加解说轨，选混合则按预设音量比混合。
副作用是字幕轴要单独校准。我们把字幕时间码与画面关键帧绑定，字幕不再跟随音频时钟，避免了解说轨延迟导致字幕错位。
问题四：播放器的“安全缓冲”
不少播放器默认为防卡顿会预缓冲 3 片，实际观看时这 3 片就是 6 秒延迟。我们重写了起播策略：首帧到达即起播，缓冲低于 1 片时才降码率，而不是先停住等缓冲。
这项改动在 4G 网络下的中断率反而下降了：从 0.21% 到 0.14%。原因是过去的“先停住”会让用户误以为卡死而退出，现在则通过降清晰度维持连续。
改造后的数据
- 端到端平均延迟：3.4 秒 → 1.2 秒（P95 为 1.9 秒）。
- 开播等待：40 分钟 → 4 分钟（90 分钟影片）。
- 放映中断率：0.21% → 0.14%。
- 解说场观众“音画不同步”投诉：月均 37 条 → 4 条。
还有没解决的部分：跨省弱网用户的 P99 延迟仍在 2.6 秒左右，下一步计划在三个边缘节点做本地混流，目标压到 2 秒以内。这项改造不影响版权与排片规则。