电视端看 YouTube 4K 视频时「清晰度在 4K 与 1440p 之间反复横跳、频繁卡顿、最后自动重载」修掉了。
变更
- 自适应码率按「编码」分组,不再把「换个编码的同一分辨率」当成降档之外的免费选项(P11-192)。现象是看 4K 视频时画面反复在 4K 与 1440p 之间切换、频繁卡顿,十几分钟后卡死并自动重载。真机日志(
FL8-Sw8PjJA,14 分钟)显示:清晰度升到 4K → 缓冲被吃空、降到 1440p → 缓冲回满、又升回 4K,这样来回 6 轮,分辨率切换 11 次,最密的一段 37 秒切了 4 次;最后一轮升上 4K 后,那一段的请求零字节挂了 40 秒,看门狗才判定卡死并整场重载。根因不是带宽不够(同期实测吞吐 43~72 Mbps,1440p 档只需 11 Mbps):饥饿降档时给「刚降下来的那一档」加的 3 分钟冷却只锁一个 itag,而同分辨率的另一个编码版本(VP9 ↔ AV1)照常可选 —— 于是每次饥饿都顺手换了一次编码,而换编码意味着解码器重建,是最贵的一种切档(日志里两种编码的交替时刻与各自冷却到期时间逐一吻合)。改法是把 itag 按编码族分组,自适应码率平时只在当前组内升降档(组内换分辨率 = 同解码器,便宜);换组变成一次独立、显式的决定,只在当前组确实不合适时发生(该组在可选集合里一档都没有,或该组在 10 分钟内被判「扛不住」两次而另一组在同一分辨率上有更省的档),换出后原组冷却 3 分钟。选择逻辑用「同组优先」的排序而非硬性过滤,避免出现「本组没有这一档 ⇒ 无档可选 ⇒ 卡死不降」的死锁。
已知
- 本条已云编译通过,待真机复测。判据:不再出现「4K 的 VP9 被冷却后 19 秒内又升到 4K 的 AV1」这类同分辨率跨编码跳跃;若 VP9 反复扛不住,应只出现一条换组日志,此后分辨率切换全部落在同一编码内(4K↔1440p)。
- 顺带发现一处未修的判据缺陷:顶档保护(4K 的升档门槛、重载后 3 分钟禁爬 4K)用的是「解码组里第 0 档的分辨率是否 ≥ 4K」,而该组第 0 档实际是本会话的默认档(720p/480p)⇒ 这些保护在 Auto 起播的会话里可能整场不生效。已在 docs/youtube-sabr-abr-upshift-notes.md §38 记录,待单独一轮处理。
- alpha.4 里记的已知项(焦点抢回待复测、转发/专栏动态不渲染、话题/@ 不可点、评论不含楼中楼等)仍未变。