修掉「清晰度一直停在 480p」 —— 自适应码率把「这一档要多少带宽」读错了数据源。
变更
- 档位门槛改用「实测交付码率」,不再信声明码率(P11-200)。播放器给每一档标的「声明码率」,在拿不到媒体元数据时会回落到 VBR 峰值(不是平均值)。真机那个视频全部 19 条轨道都命中了回落 ⇒ 整条清晰度梯子的「需求」都是峰值:720p 的 VP9 档声明 8.24 Mbps,而实际交付只有 2.7 Mbps(逐段字节复算:1.84MB ÷ 5.33 秒/段 = 2.76 Mbps)。后果两条同源:①升/降档判据按 8.24 Mbps 比,链路的 3.2~4.9 Mbps 永远「买不起」⇒ 钉死 480p;②「带宽撑得住就不降档」那道闸要求实测 ≥ 声明,峰值声明下这条永远不成立,闸等于不存在(33 秒缓冲也照降)。现在档位需求取
min(声明, 实测交付码率):只降权不抬权、不叠余量、实测证据不足时完全退回声明值(等同旧行为)。所有闸的门槛系数、豁免和冷却时长一律未动。 - 顺带把顶档(4K)的持续带宽闸也换成同一基准,同样是峰值声明导致它按假数据判。
- 新增一次性日志
tier need calibrated (P11-200),打印每档的声明值、实测值与校准结果,便于复测核对。
已知
- 本条待真机复测。判据:日志出现
tier need calibrated (P11-200): itag302(720p) declared=8243818 meas≈2.7M → need≈2.7M(声明虚高 3.0×);不再出现「实测交付码率已经低于当前带宽、却仍被判买不起」的降档(形如downgrade 720p → 480p … est=3227K meas=2729K);低水位防降档闸开始生效(buffer-critical downgrade **suppressed**)。 - 一个刻意未做的不对称:冷却「提前解除」判据仍按声明值(它回答的是「要不要给刚判失败的档翻案」,宁严勿松),与本条的放宽方向故意相反,免得刚失败的档立刻回爬。
- 另一个刻意未做:同高度的更省编码族仍被 P11-195 的天花板守卫挡着(见 alpha.7)—— 本轮只解决「同一档位判据读错数」,不碰编码分组。
- alpha.5~alpha.7 里记的已知项(编码分组/缓冲地板/顶档闸待复测;转发、专栏动态不渲染、话题/@ 不可点等)仍未变。