「继续观看」也能用自己搭的会话播了 —— 接着上一版那条线收尾。上一版让 YouTube 改走我们自己搭的会话(实测连续播 13 分 24 秒、1080p);这一版补上续播,并修掉两个「放弃得太早」的判据和一个「上限形同虚设」的配置问题。
变更
- 续播失败之一:把好页当坏页(P11-158)。借令牌前要先在一个隐藏浏览器里打开 watch 页。实测那次页面其实已经完整加载(82 万字节),但「8 秒内没收到页面完成信号」就被判成空白页丢弃;而同机成功的那一次,页面完成信号是 8.1 秒才来的 —— 差 0.1 秒。现在改成看证据:文档不是空的就继续等,不再只凭「时间到没到」判死。
- 续播失败之二:只肯等 6 秒(P11-159)。页面放前贴片广告时只发「占位令牌」,真令牌要等内容起播才铸出来。原实现「拿到占位令牌后再等 6 秒」就放弃,而实测真令牌是在 8.5 秒后出现的 —— 差 2.5 秒就漏掉。现在改为等满本轮采集窗口(窗口本身有预算上限,不会无限等)。
- 修「上限形同虚设」(P11-160)。播放请求走的是通用网络配置(15 秒超时,那是给小接口定的),导致我们给播放设的「按清晰度 18 秒 / 40 秒」上限根本轮不到生效:服务端偶发慢启动时(正常首包 3.5~7.2 秒,慢的时候 16.5 秒一个字节都没发),请求会在 15 秒被切断、整个会话重建。现在把播放请求的超时与那个上限对齐。
进展与已知问题
- 实测结果:连续续播 3 场,2 场直接成功、1 场偶发失败后自动重试成功;服务端校验
status=1×32、被拒 0 次,末笔画质升到 1080p / 1440p。新播那边(上一版)是连播 13 分 24 秒。 - 起播仍偏慢:续播实测约 51 秒才出画面(其中借令牌 17.7 秒,前面还有约 22 秒的准备)。下一版做并行化。
- 仍未根治:vp9 系清晰度的「真实平均码率」需要在抓取层补算(取内容长度÷时长)。
- 降档/升档偶有摆动(上一版处理过的「画面定住」那条线的邻居问题),与本版改动无关。
- 本版同时包含并行会话的设置页改动。