YouTube 的取流不再"整批收完才用" —— 大响应边收边用、拿够就停；顺带修掉「起播就被自己降一档、还锁 90 秒」。
变更
- SABR 响应改成流式读（P11-217）。以前是"把整包读完才开始解析"，服务端一次推 25
65MB 时，播放器在 1131 秒里拿不到任何一段（真机实测一笔64.95MB / 31073ms，而 25 秒启动看门狗先把它整个重载掉了）。现在边收边解、段一完成就交给播放器，拿够（请求段 + 一层余量）就停止读流。同一场景实测：38.49MB / 6498ms，首帧明显前移。中途异常时已经到手的段会留下（以前是整批作废、颗粒无收）。 - 起播期只等"请求段本身"（P11-218）。手选 2160p 的首笔实测从
38.49MB / 6.5s降到13.19MB / 3.2s；已开播后仍留一层余量（下一轮往返要时间，只拿一段会让缓冲在往返期间见底）。真机：点 2160p → 13.6 秒出画，全场 0 stall。 - 修「起播就被自己降一档、还把中间档锁 90 秒」（P11-220，来自 P11-219 的判据链复盘）。起播时"缓冲 = 0"是必然状态，却触发了水位急救降档，并顺手把该档 90 秒禁选 —— 后果是中间层消失：之后降档只能跨级跳（1080p→480p）、升档要多爬一级，用户看到"清晰度来回跳"。现在水位急救要求"本会话曾缓冲过"（零字节挂死这种独立证据不受影响）。真机复测：起播不再出现
buffer-critical downgrade: bufS=0s，整场只有升档、没有降档/冷却/跨级。
已知
- 4K 自动升档仍很难触发（下一步做）：升档要求"缓冲 ≥ 30 秒"，而按需拉取让缓冲常驻 9~18 秒 —— 只有"刚收完一大笔"的尖峰才够，而那一刻 loader 停拉、没有评估点。手动选 2160p 不受此限（实测可正常起播）。计划：把带宽判据改成按每笔请求记账（应得/实得/有效时间/零回复），让"交付速率"不再被停拉空窗和慢样本扭曲，再把地板改成"覆盖两次本档往返"。
- pot-less 会话仍会概率性被服务端判
status=3（与 token、与形状无关），自动重载恢复。 - 判死后到播放器上抛错误之间还有约 30 秒的等待（媒体框架自己的重试节拍），待改。
- alpha.5~alpha.12 里记的已知项仍未变。