这一版是「取证版」:把两条可疑路线放进同一个构建里对照跑,并加厚日志,好让一次真机测试就能读出结论。
变更
- 同一视频内自动对照两条会话路线(P11-144):同一个视频第一次播放走「采集材料建会话」,被判定失败重试时改走「我们自己的会话」,如此轮换 —— 于是同一视频、同一网络、相隔数十秒就能拿到两条路线的同条件对比,不必再拿不同场次的日志拼结论。
- 服务端提示「需要更新播放令牌」时不再换令牌(P11-144)。此前一收到该提示就把令牌换成新铸的一枚;实测换成的那枚紧接着就被服务端判为无效,整个会话随之报废。现在改为保留当前令牌继续用,并在日志里记下「刻意不刷新」与令牌年龄 —— 这样下一笔请求的结果就能把「换令牌才是祸首」与「提示本身等于终止」两种情况分开。
- 日志加厚:每笔响应新增一行摘要(我们请求的档位 / 服务端真正给的档位 / 可用字节),请求日志新增令牌年龄;这两样把「格式对不上」与「令牌不被接受」两类问题在日志里一眼分开。
进展与已知问题
- 上一版结论保持:用自己的会话播能拿到我们的档位与真实媒体段(两条轨都送到解码器),而用采集材料建的会话两个媒体块都拿不到。
- 代价(刻意):对照轮换意味着每个视频第一次播放会先走采集路线(要吃 9~40 秒采集,且大概率失败),重试后才走自己的会话。
- 仍未修:程序自己铸的令牌呈「每次变长」的异常形态(实测 +65 字节/次,涨到 1300+ 字节),且铸造时缺少网页原生上下文 —— 这两条已有明确修法方向(重建铸造环境 + 补上下文),下一版处理。