urbanescavenger/BiliMT v3.1.1-alpha.6

on GitHub

修一个把「管道能力」算错的记账 bug:38 Mbps 的管子上报 127 Mbps —— 这条读数(sus,持续带宽)
是升档判据里唯一一条「长期扛不扛得住」的证据,虚高会让自动档去尝试它其实喂不动的档位(P11-258)。

变更

• 背景(判读,P11-257):真机问「为什么没升 4K」。日志(logs_live_20261014_212516.log,BRAVIA 4K AE2)
  给出的答案不是「没升」——自动档升上屏了三次(21:09:40 / 21:15:49 / 21:23:08),但每次只撑
  2 分 39 秒 ~ 3 分 18 秒就被水位急救打回 1440p,再等 180 秒顶档冷却才允许重进 ⇒ 一个完整来回
  ≈6.5~7.4 分钟(4K 段与 1440p 段几乎等长)。打回本身是对的:那两段的墙钟有效交付只有
  26.2 / 21.9 Mbps,而 4K 自报实需 21.827.5 Mbps ⇒ 缓冲从 40s 单调漏到 56s,急救开枪没错。
• 问题:同一批样本,升档闸读到的却是 3043 Mbps(est)**和 100127 Mbps**(sus)。
  21:16:07 那一行 sus=127204K 是物理不可能值 —— 同一 60 秒窗口里的字节÷墙钟只有 38.4 Mbps
  (逐笔在途 31~38 Mbps),链路在途上限就是 ~38。
• 根因:sus 的分母是「墙钟跨度 − 需求驱动的停闸空闲」。两个减数各自按自己的记录时刻滚出
  60 秒窗口,而空闲样本记的是 [上次响应结束 → 本次请求发出] 那段、记录时刻却是本次请求完成的时刻
  ⇒ 它覆盖的空闲区间整体落在分母窗口起点之前,等于减掉了不在分母里的时间。本例少掉的 41.4 秒
  正是同一刻那笔 raw=41189ms 空窗。同一根因还有另一面:扣完后跨度不足 10 秒会返回「证据不足」,
  而那个值在升档闸里是放行方向 ⇒ 一个记账缺陷同时制造「虚高的假证据」和「无证据」两类放行。
• 改法(只修记账,不动任何阈值/冷却/口径):①样例带区间(空闲段归集在请求间隔尾部);
  ②窗口滚动单点定义(字节按区间起点滚、空闲按区间结束滚),删掉两处各写一份的漂移源;
  ③分母改成「只扣与窗口有交集的那部分空闲」;④ABR 心跳日志新增 susRaw=(扣减前裸值),
  与 sus= 并排 —— 以后「修好没」不用靠猜。
• 自检(本地无 Android SDK,手算复核):同一时刻旧版模型 125.5 Mbps(日志 127.2,吻合),
  新版 35.6 Mbps(与在途 31~38、est=37394K、cap=35838K 同量级);真滑行样本仍全额扣减,语义没丢。

待验证(真机)

• 日志里 sus= 不再出现比 susRaw= 高 2~3 倍的不可能值,二者同量级;满缓冲真滑行的场次仍应
  看到 sus > susRaw(扣减语义还在)。
• 升降档的时序应与本版无差(本版只改输入量的记账,不改任何门槛)。
• 本版不修横跳:按判读回放,那三处 4K 放行的判决不会翻转(修后 sus≈38M 仍高于 4K 实需 2326M)。
  横跳主因是口径——升档闸量的是「在途吞吐」,不看「在途占空比」(那两段只有 6876%),
  est 还明确把请求之间的空窗排除在外。若修完横跳周期不变,是预期结果。

已知

• 未做:升档判据改用「墙钟有效交付」(口径改动,待拍板);「升进顶档后 60~90 秒观察期若缓冲净漏
  则回退、且不进 180 秒冷却」(治横跳观感);冷却分级(供给 vs 挂死)。
• 判读与算式逐条核对、本次改动的判据链复核与否证线,全部记在
  docs/youtube-sabr-abr-upshift-notes.md §56(判读)/§57(实施)。