YouTube SABR 抖动降档收口：不再频繁掉 480p/240p，掉档必须「真饿」。
- 挂死期间也能及时降档（P11-326）：ABR 原本只在段完成时评估，大段请求挂死时整段饥饿零评估，只能等 8s 看门狗整场重载。利用 Media3
reevaluateBuffer → shouldCancelChunkLoad在挂死期间仍被周期性调用的现成评估点：runway≤12s且（ETA 来不及 / 首字节后静默≥3s）时取消在途段并重评估，取消不再 evict 会话。升档按档高分级：≤1080p 维持原口径，1440p 用 60s 持续带宽 + 近 15s 无断流，2160p 要求持续证据 +need×1.1 ≤ min(sustained, cap)+ 近 20s 无断流。 - 进度条显示缓冲段（P11-327）：TV 主进度条原来就在画缓冲段，但
ProgressBuffered比轨道还暗，等于不可见；改为比轨道亮、比已播段暗。TV 迷你进度条与移动端在线/离线滑块补画缓冲段。 - 后继段等待收口（P11-328/329）：ETA 改为累加本响应已宣告的全部视频段（原来只记第一个，请求段一到手 ETA 就归零，P11-305 让路误判）；请求段到手后最多再等后继段 5s（缓冲 <20s 时），到点早停、把单发槽让给下一笔；强制降档加 5s 最小观察窗口，避免 TCP 慢启动阶段的 1~1.5Mbps 假速率触发误降。
- 不把音频请求当视频请求（P11-330）：SABR 音频响应会顺带推视频段，旧口径「响应里出现过视频段头」就把音频请求当视频请求，音频静默 3s 会触发视频档位降档，并用音频的 350K 速率选出 240p。改为按
req.formatItag绑定视频请求，音频响应体不再参与视频档位判据。 - 挂死证据不再无条件绕过缓冲（P11-331）：304 份日志校核，32 次
silenceHang=true降档中约 14 次缓冲在 15~41s；改为缓冲 ≥12s 时不因单笔挂死降档。 - proactive 强制降档只下一档（P11-332）：5s 观察窗内的单笔速率仍会被慢启动/服务端 pacing 压低（真机 597
706K 而 est 1215M），fit-to-supply 会一步跳 240p；强制降档改为只降相邻一档，深降只留给缓冲真的 <8s 的常规水位急救。 - 验证：P11-326
332 云编译均绿（43593985531 / 43596316812 / 43599300240 / 43601652426 / 43603567870 / 43605215089）。真机 dev.r2326r2330 逐步收敛：19:47/20:00 的 2160/1440 连续重载 → 21:33 的 240p 误降 → 22:24/22:27 的 240p 深跳，逐项修复；最新构建仍待真机复测。判读见docs/youtube-sabr-abr-upshift-notes.md§75–81。