稳定版:YouTube 播放链路大修 —— 「自己搭的会话」打通(新播与续播都走通),并连根修掉四类「画质掉下去就回不来」;TV 播放器 UI 全面对齐官方客户端、三源底栏统一;移动端会员角标补齐。 本版整合 v3.0.13-alpha.1~25 全部改动。
变更
YouTube 播放
- 「自己搭的会话」真正打通(alpha.3, 11
17, 2324,P11-118/139/140/156/158160,§5.11):YouTube 的播放令牌此前一直用我们自己铸的那一枚,服务端始终当成"临时占位"处理,十几秒后就拒绝并要求换令牌。逐层取证(身份、材料、令牌形态、超时)之后定位到令牌的来源不对 —— 改成「会话仍是我们自己的(所以服务端供给我们要的清晰度),只把播放令牌换成页面上自己铸的那一枚」,并补上两个"放弃得太早"的判据与一处形同虚设的超时上限。真机实测:连续播放 13 分 24 秒、服务端校验 108 次全部通过、281 个分段、零卡顿零重载,画质正常升到 1080p;「继续观看」的续播同样走通。中途走过一段「借用浏览器材料」的弯路,实测它只提供浏览器当时选中的那两档(我们要的档拿不到),该路线已整段停用。docs/youtube-web-sabr.md§5.9 - SABR 续播「满缓冲黑屏死锁」根治(alpha.1,P11-96,
docs/youtube-sabr-abr-upshift-notes.md§31/§32):续播点落在分段中间时读取被永久锁死 —— 缓冲显示已满、解码器却不喂帧、永远到不了 READY。按官方实现补全协议后,死锁位 5.5 秒起播。 - 画质「掉下去就回不来」的四类原因(alpha.20~22, 25,P11-151/152/153/164/167/168):①降档冷却一刀切 180 秒且不分原因(拖动进度、切换来源造成的降档也被当成"这个清晰度扛不住")→ 按原因定时长,供给不足 180→90 秒、拖动 / 手选只锁 20 秒,缓冲恢复即提前解除;②**「只在服务端给过的档位里选」这条约束被静默套用到所有会话** ⇒ 不去请求 1080p 就永远拿不到 1080p,死锁在 720p(手机端「停在 144p 不回升」同源)→ 该约束改为只对采集会话生效;③**「缓冲满就试探升档」跳到了远超实测容量的档**(自报 18.6 Mbps、实测容量约 9 Mbps),切过去喂不动 ⇒ 画面定住、声音靠缓冲继续 33 秒 → 试探升档不得超实测容量的 1.5 倍,且 1080p 及以下的单请求等待上限从 40 秒收到 18 秒;④开关字幕 / 暂停 / 满缓冲的排空段被误判成"带宽不足" → 分别修成「选档重建时继承当前档」「长时间需求性空闲不计入带宽估计」「带宽撑得住当前档就不开水位急救这一枪」。
- 音轨可切 + 字幕覆盖三条取流路(alpha.4,P11-119/120):过去点选音轨毫无变化(主链的签名里根本没有这个参数),并且恒播英语配音轨;字幕整块下线后改为懒加载挂载 —— 每条字幕轨在 prepare 期零读取、失败即弃,字幕的任何网络问题都够不到主源。
- 播放稳定性三项(alpha.8,P11-133/134/135):水位急救降档改为「一次冻结只降一档」;移动端补回 stall 看门狗与 SABR 请求的整调用超时;YouTube 解码器拆成自己的值域(含 VP9),梯子锚点跟随。
- 修「无效流量」(alpha.9/10,P11-136/137):升档预取会占用服务端响应的预算,把正在播放的那一档的数据挤掉(实测白下 8MB 又整段丢弃、连续 25~33 秒拿不到画面)→ 预取在缓冲变薄时立即撤销。
- 一次约 99 秒的静默卡顿(alpha.25,P11-162)、慢启动不再白等 18 秒(alpha.25,P11-166):逐行核对了 FreeTube 的实现补上三处缺失的超时(其中最长的一处是自己代发请求时没设连接 / 读取超时);「多久没有新字节」的阈值从 18 秒收到 8 秒 —— 实测这种停顿重试只要 4 秒就能成功。
界面与交互
- TV 播放器 UI 全面对齐官方客户端 + 三源底栏统一(alpha.6,P11-124):B站 版式重排为顶部三行(标题 / 元信息 / 动作行),三连从底栏搬到标题下方;新增刷新、画面旋转(顺 90→180→270,旋转态铺满整屏)、播放序列(列表播放 / 单视频循环)三个入口;画质显示改
HD、字幕改CC图标;YouTube 底栏对齐同一套,影视库 / IPTV / 红果 统一为 8 项。 - 移动端会员角标补齐(alpha.5,P11-121 + alpha.25,P11-169):新增共用组件
SourceBadge(粉底胶囊),卡片角标从左上裸白字改为右上胶囊(首页 / 推荐 / 搜索 / 动态 / 收藏 / 历史 / 直播等所有出口一并生效);在线播放列表行的「已看完」让位到左下;自定义播放列表行与播放器「播放列表后续」行补上此前完全没有的角标;频道页与 UP 空间投稿列表的视频行也补上(此前从来没画过)。 - TV 设置页遥控器丢焦点(alpha.18,P11-148):在设置里上下选择时焦点框消失、方向键全部失效,列表深处的 WebDAV「备份」按不到、弹窗里也选不中任何项。根因是滚完只等一帧就抢焦点,而离屏的行根本没组合 → 改为「滚到目标进入布局后按帧重试」,预算用尽则就近把焦点交给可见行,绝不留空焦点树。
- YouTube 设置独立分组 + 解码器 / 默认倍速拆成两份(alpha.7/18,P11-127~131):解码器与默认倍速此前 B站 / YouTube 共用一份,改一边会互相影响;现在各自独立,并新增「YouTube 设置」专区(全移动身份、起播锁高、清晰度菜单、升档预加载);随后按真机反馈把折叠组改成二级面板(与首页分区、日志、关于同一套机制)。
- 频道页 / 播放列表返回丢焦 + 网格 D-pad 导航(alpha.2,P11-98/98b/98c):返回时按记录位置恢复焦点(滚动定位 + 等待布局 + 重试);网格顶行 ↑ / 首列 ← 的边界按键不再逃逸到侧栏头像。
进展与已知问题
- 起播仍偏慢:走「借页面令牌」这条路时要先在一个隐藏浏览器里打开 watch 页(约 17.7 秒),整段起播实测约 51 秒。上一版承诺的并行化已实测回退(3 场里只有 1 场成功,并出现协程作用域被提前取消的报错),起播提速改由「静默超时 8 秒」拿回一部分;这仍是下一轮的主要目标。
- 部分清晰度的声明码率是假的(vp9 系回落成 VBR 峰值:144p 报 4.7 Mbps、720p60 报 18.6、2160p 报 71.6,真值约 0.1 / 2~3 / 25)。本版已止血(升档基准按实测容量夹住)并留下诊断日志,根因(在抓取层按「内容长度 ÷ 时长」补算真实平均码率)尚未处理。
- 1440p / 2160p:默认这条路的清晰度天花板实测为 1080p(服务端该场只提供 6 个高度);更高档位的路径状态与上一版结论一致,不在本版改动范围内。
- 弱网下「带宽闸」的另一侧尚未取到证据:目前的真机回归只覆盖「带宽充足时不该降档」;真实带宽不足时是否照旧降档,需要在低带宽场次复测。
- 本版包含两条并行会话的改动:TV 设置页焦点修复(alpha.18)与「YouTube 设置」二级面板。