修「无效流量」根因:升档预取会占用服务端响应的预算,把正在播放的清晰度的数据挤掉(实测一次白下 8MB 又整段丢弃、连续 25~33 秒拿不到画面)。本次让预取在缓冲变薄时立即撤销。
变更
- 预取在缓冲变薄时立即撤销(P11-136)。此前的预取窗口只看一次:进入时缓冲够厚(≥20 秒)就开启,之后 30 秒内每个请求都会向服务端点名索要「下一档」的数据,哪怕缓冲已经塌到 0。真机两场实测的后果是:服务端照办(每个响应约 7.87MB 全是下一档的数据),而当前只认正在播放的格式,于是整段丢弃 —— 更糟的是响应预算被这些数据占满,当次真正需要的分段挤不进来,连着 6 次重试、每次再下 8MB,最后服务端会话被重置、重来一遍。两场「连续 32.8 秒 / 25 秒零可用画面」的时间窗与预取窗口逐帧吻合。现在进入线仍是 20 秒,但缓冲跌破 15 秒就立即撤销,不再与正在播放的清晰度抢响应预算。
- 本版的两次卡顿与上一版无关:上面那两次「零可用画面」窗口的起因就是本次修的预取抢占(上一版 alpha.8 已修掉降档级联自己把缓冲吃干的那次卡顿)。
已知问题
- 升档预取本身仍未生效:它向服务端要回来的数据目前会被白名单整段丢弃(格式不在「当前播放的格式」里),所以「切档命中缓存、不必现拉」这个目标还没达成 —— 实测候选档是 1080p 而缓存内容也对不上同分辨率的其它变体。本次只是先止住它抢占响应的副作用;让它真正生效(白名单放行 + 候选档与实际升档目标对齐)在下一轮验证。
- 升档代价仍是现拉:720→1080 约 2.9s、1080→1440 约 6.6s、1440→2160 约 14.3s。
- 移动端播放器不读「默认播放倍速」:
MobilePlayerScreen把起播倍速写死 1.0x,该设置在移动端一直失效,单独跟进修复。 - 服务端偶发改推其它清晰度 / 跳过所请求的分段:这仍是上面那类「零可用画面」的诱因之一(本次修的是我们自己的预取抢占,服务端行为本身仍未处理)。