播放稳定性三项:ABR 水位急救「一次冻结只降一档」(P11-135)、移动端补回 stall 看门狗 + SABR 请求整调用超时(P11-134)、YouTube 解码器拆成自己的值域(含 VP9)+ 梯子锚点跟随(P11-133)。
变更
- ABR:一次冻结只降一档(P11-135)。真机实测一次 5.7 秒的缓冲冻结里连降四级(720p→480p→360p→240p→144p),落到 144p 后 112 秒再也升不回去,而带宽、持续带宽、缓冲水位全部远超上一档的门槛(缓冲峰值 34.8s、多次 ≥30s)。原因有二:①水位急救的「仍在下漏」判据每次评估重新判一遍、且没有降档后宽限,同一段冻结被算了四次账;而每次降档自身还要 1.5~3.4 秒去拉新档首个数据,期间水位继续漏,于是逐级穿到地板(对照:冻结结束后只要不再降档,缓冲 4 秒就回满);②级联沿途把 720p/480p/360p/240p 逐档各记一笔 180 秒冷却,而升档只允许逐级爬,下一级(240p)被锁住等于唯一出口被封 180 秒。现在同一段冻结只降一档,水位回到阈值以上才允许下一次;真饿仍由带宽估计通道兜底逐级下探,不受影响。
- 服务端要求的退避不计入带宽统计(P11-135)。服务端有时会要求客户端等待(如 2 秒)后再请求,这段等待此前被当成「链路没供上数据」计入带宽估计,把估计值往下拽(实测 23752K→17926K→13836K)。现改为原样剔除,既不算供给损失也不算需求空闲。
- 移动端补回 stall 看门狗 + SABR 请求整调用超时(P11-134)。此前移动端遇到「请求发出去既不返回也不报错」的挂死时,三条兜底(报错重试、看门狗、请求超时)一条都不会触发,播放会一直冻着直到手动退出(实测冻了 54 秒)。现补回与 TV 端同阈值的看门狗(卡顿 8 秒 / 起播 25 秒 / 视频冻结 12 秒),并给 SABR 请求加 40 秒整调用上限。
- YouTube 解码器拆成自己的值域(P11-133)。此前 YouTube 与 B站 共用同一套解码器选项,而 YouTube 大量使用 VP9——旧选项里根本没有 VP9。现 YouTube 有独立的解码器菜单(自动 / VP9 / AV1 / H.264),选中的解码器会同时决定升档时走哪一族轨道(整场不跨族切换,避免切档撞解码器重建卡顿)。H.265 从 YouTube 菜单移除:实测本应用的 YouTube 身份从不收到 HEVC 轨道,留着等于挂一个永远无效的项;B站 侧不受影响。
- 升级兼容:存量用户此前选过的 H.264 / AV1 会原样映射到新的 YouTube 解码器设置,不会因换菜单而降级成「自动」。
已知问题
- 升档预加载(P11-130)仍未生效:候选档只写进了请求的候选列表第二位,服务端每个响应只推主格式,升档仍是现拉(720→1080 约 2.9s、1080→1440 约 6.6s、1440→2160 约 14.3s)。继续跟进。
- 服务端偶发改推其它清晰度、数据被整段丢弃:实测播放中请求某个视频分段时,服务端改推了另一个清晰度的数据,而白名单只认已选中的轨道,于是每次完整下载约 8MB 后整段丢弃、连续 32.8 秒拿不到可用视频数据——这正是上面第一项那次冻结的起因。本轮改动不会阻止第一次降档(那是正确反应),只让它止步一档;服务端行为本身待单独处理。
- 移动端播放器不读「默认播放倍速」:
MobilePlayerScreen把起播倍速写死 1.0x,该设置在移动端一直失效,单独跟进修复。