urbanescavenger/BiliMT v3.1.0-alpha.12

on GitHub

YouTube 续播 / 切清晰度不再从片子开头重新拉 —— 一次 POST 回来的那几十 MB 里，不再有一半到全部是播放头之前的内容。

变更

• 续播与切档的首包带上「我播到哪了」（P11-213 / P11-215 / P11-216）。真机证据：手动切 2160p（从 14620ms 处续播）时，服务端推回来的是 seq=1,2,3,4（全片开头 → 覆盖 0~21.6 秒、共 49.9MB），其中只有 25.2MB 落在播放头之后（日志里 bufS=6.9 正好对上）；续播到 301276ms 的那一场更极端，整包一点没用上。原因是 SABR 的第一个请求是 init/bootstrap，它的 playerTimeMs 按定义是 0 —— 等于告诉服务端「我在开头」。现在把「本次播放的续播位置」在建会话时种进去（TV 与移动端对称），init 请求带上真实位置。
  • 真机验证（dev.r2155）：首包推的段从 seq=1,2,3,4 变成 seq=3,4,5,6（正是含锚点的那一段），首包字节 49.9MB → 7.99MB。
  • 音视频两条轨各发一次 init，所以这个位置一直保留到「播放头第一次有效」为止 —— 否则音频那条会把位置用掉、视频那条又从头拉。
  • 只动 init 这一笔：中段请求本来就对齐（实测请求 seg=72 → 推 seq=72,73），一行没碰。
• 修「首帧出来了却一直播不出」（P11-210）。真机日志里有过一次：渲染了首帧，却从未进 READY（同场只有一个 ExoPlayer 实例、onPlaybackStateChanged 每次状态变化都打，8.2 秒里一次都没打），位置钉在 seek 落点一动不动 —— 那一帧只是 seek 之后的 preroll 渲染。看门狗据此把宽限从 25 秒档掉到 8 秒档，而开枪前 1.4 秒其实刚收到一笔 36.5MB。现在起播判据改用 playerState=3(READY)，不再拿「出没出首帧」当凭证；日志行同时打 startup= 与 frame= 两个字段。
• 切清晰度后的 WEB 会话不再回落「自铸 token」（P11-208）。采集窗口（45 秒）内第二次建会话时，此前会把刚采到的材料丢掉、改用我们自己铸的 token —— 真机上那条路首笔必被服务端当占位级，第 4 笔就整会话判死（33 秒卡死 + 一次整场重载）。现在窗口内直接复用那份材料。真机验证：切 2160p 时复用 40.3 秒前的材料 → 首笔 status=1 → 4K 正常起播。

已知

• 4K 起播仍可能在慢窗口里失败（本轮未修）。真机实测那一笔响应最大 64.95MB / 31 秒（16Mbps），而启动看门狗是 25 秒 —— 问题不在「拉错了内容」，而在「一次收太多、收完才肯用」。下一步做边收边解、拿够就停。
• 单笔请求的超时上限仍是固定值（饥饿档 ≥1440p 为 12 秒），会大于小缓冲场景下的可用缓冲（实测缓冲 6.9 秒），于是「挂一笔就等死」；待改成随缓冲余量收缩。
• pot-less 会话仍会概率性被服务端判 status=3（与 token 无关，见 docs/youtube-web-sabr.md §5.11.21）。
• alpha.5~alpha.11 里记的已知项仍未变。