urbanescavenger/BiliMT v3.1.3-alpha.1

on GitHub

SABR 交付面重构（A）+ 按需抢占（C 第一步）+ runway 驱动 margin（B1）。 目标是把“请求段到手”
从“整笔响应结束”提前到“该段 MEDIA_END”，减少 4K 弱链路下的额外等待。

• 交接面（P11-315）：读循环移出 loader 调用栈，会话级 readerScope 后台读；getNextSegment 只等
  请求段落地，margin 后继段继续读进缓存；单流串行语义不变（fetchMutex + 等上一笔 drain），
  同轨远距离 seek 才取消旧响应；段缓存改 ConcurrentHashMap；MediaSource 释放时取消后台读。
• 热修：移除“顺序请求 join 1.5s 超时取消”（会 cancel 另一路在途响应，造成 1.5s 取消风暴）；
  streamNeedSatisfied 计入 bufferedSegments（否则早交付后永不早停）；init 请求后的首笔媒体
  请求不再误判 far seek。
• 按需抢占（P11-316）：视频缓冲 <10s 且挡路的是音频请求、音频已跑 ≥800ms 时，取消音频 drain
  让视频先走；不做并发第二条 POST（避免破坏服务端游标）。真机尚未触发该路径，待观察。
• runway 驱动 margin（P11-317）：用实测带宽 + 该 itag 平均段字节估每段墙钟；水位覆盖不了
  “margin+1 段”的预估耗时（×1.2 + 1s）就逐级降 margin，最低 0（只等请求段）。
  实测：4K 场 42/43 笔早停为“请求段本身”，单笔响应 2444MB → 1018MB。
• 验证：dev.r2302/2304/2305 真机；4K 弱链路（2030 Mbps）无重载，卡顿由“单段下载 59s >
  缓冲 37s”的带宽瓶颈决定；交接面每笔省 1.75.8s。详细判据见 docs/youtube-sabr-streaming-refactor.md。