电视端看 YouTube 时「看着看着突然自己重载」的两个根因修掉了(承接 alpha.5 的「按编码分组」)。
变更
- 升到高清晰度之前必须先有缓冲(P11-193)。真机上两次重载相隔只有 2 分 36 秒,形状一模一样:重载 → 起播 720p → 一两分钟内自己爬到 4K → 缓冲见底 → 8 秒判死、整场重载 → 重载后继续爬同一堵墙。根因是一条「起播第一爬免缓冲门槛」的豁免:它和门槛是「或者」的关系,而这类循环里自适应码率从来不真正降档(该降的那一枪被另一条带宽闸按掉了)⇒ 豁免一直成立 ⇒ 只有 10 秒缓冲也批准升 4K;换档又把已下好的缓冲丢掉,4K 得从零拉(实测单笔 46MB 要 22.9 秒、25MB 要 26.4 秒)⇒ 8 秒看门狗必开枪。现在高档攀爬要求缓冲到位(地板随本场实际水位浮动,填够就放行,不是锁死),缓冲读数无效时一律不升。
- 让「持续带宽不够就别进 4K」这条闸真正生效(P11-194)。这条闸本来就写着「4K 死亡行军防线」,但它一直没开过枪:判断「本场有没有 4K 档」时读的是轨列表里第一档的分辨率,而第一档实际是这一场会话的主档(720p/480p),于是恒为「没有 4K 档」;同一条闸里还有第二处按「第一档=最高码率」写的判断,同样落空。改成按真实高度判断后,实测供给没到位的 4K 试升会被拒(真机那场是持续供给 6.7Mbps、4K 档要 9.1Mbps),同时「刚重载过就 3 分钟内不许再爬 4K」这条保护也一并恢复。
已知
- alpha.5 的编码分组、alpha.6 这两条都待真机复测。判据:重载后一两分钟内不该再出现爬 4K;若被拦,日志应出现
upshift held (buffer floor, P11-193)或top-tier gate refused (P11-194),并且要看到缓冲/持续带宽到位后才有下一次升档。 - 体感变化(有意为之):自动档进 4K 明显比以前难 —— 现在要求实测持续供给达到 4K 档需要的 1.1 倍(这台设备上 AV1 4K 约需 10Mbps、VP9 4K 约需 23Mbps),而以前只凭一个容易虚高的瞬时估计。手动在画质菜单里选 4K 不受影响。
- 还有一个已知但未动的洞:换档(含降档)时会把已下好的缓冲丢掉,新档第一个数据块落地前若超过 8 秒仍会被判死重载。这次没改看门狗,先观察。
- alpha.4/alpha.5 里记的已知项(焦点抢回待复测、转发/专栏动态不渲染、话题/@ 不可点、评论不含楼中楼等)仍未变。