dd7bb7a9eeca9aff821877870434c3e764da0e32
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 ForgQi
|
dd7bb7a9ee |
Refine auth policy and migration compatibility
Centralize authorization into a policy layer so route, field, and user-permission checks all use the same decision point. The frontend now revalidates /v1/me after 403s or dropped connections, and the users page fetches the real role/permission catalog from the backend instead of hardcoding role descriptions. This also tightens field-level protection for sensitive config/template data and avoids exposing user-management controls when auth is off. The backend and migrations are updated to handle LF/CRLF checkout differences in SQL migration checksums, with compatibility reconciliation for older databases and safeguards to prevent silent drift of previously shipped migrations. |
||
|
Noah
|
3ab1a4630b |
feat: live-url 同一房间 5 秒去抖（失败重取带 fresh=1 绕过）；斗鱼网宿直链追加 expire=0，不再每 5 分钟断流 (#1713)
* feat(preview): live-url 同一房间 5 秒去抖，播放失败后的重取带 fresh=1 绕过 每次打开预览都向平台 API 取一条新直链（带 cookie 时消耗登录态配额，B 站接口有频控）。同一房间 5 s 内的重复请求（StrictMode 双调用、连点、同一房间多个小窗）复用上一次结果并标 cached: true， 不再打平台；前端播放失败后的重取传 ?fresh=1 一定拿新 token（抖音某节点 404、直链到期都靠它）。 缓存插入时顺手清掉一分钟前的条目，表不会长。 Part of #1708 * feat(douyu): 网宿直链末尾追加重复的 expire=0，不再每 5 分钟断流切文件 斗鱼网宿 CDN 按直链里的 expire=300 每 300 s 关闭一次连接，stream-gears 录斗鱼因此 5 分钟一个文件。实测网宿的 wsAuth 只校验第一个 expire、连接寿命取最后一个：保留原值、 末尾再追加 &expire=0 能通过校验且不再断开；删掉或改写原值都会 403。 - douyu：只对网宿直链（host 为 ws*.douyucdn.cn 或 fcdn=ws）、且只有一个非 0 expire 时追加； 火山（force_hs）、华为等其它线路与已是 expire=0 的直链不动。 - stream-gears：首连 403 且是追加过的直链时，本次改用原直链再连一次（同一 token 仍有效）， 之后照旧按 300 s 断开续录；每次拉流最多多一次请求，不进外层重试。 - 其它下载器（ffmpeg / mesio / streamlink / 边录边传）与预览直连没有这层兜底，照旧用原直链。 |
||
|
Noah
|
48dc8fd65b |
fix(preview): 中转模式在有 RTT 的链路上频繁缓冲——旁路挪到解析点、掉队原地续播、缓冲分低延迟 2 s / 流畅 5 s 两档 (#1716)
* fix(preview): stream-gears FLV 在解析点旁路，不等写盘循环整 GOP 落盘 httpflv 的写盘循环把 tag 攒在 flv_tags_cache 里，等下一个关键帧到来才把整个 GOP 一起写出——预览的旁路点原来就挂在这个写出循环里，于是预览端每个 GOP 间隔（B 站 常见 2–4 s）收到一次整 GOP 的突发、其余时间一个字节都不来，且整体落后一个 GOP。 播放器拿到的缓冲恰好在下一个突发到达时耗尽，零余量：同机 0 ms 下勉强连上，链路 上稍有 RTT / 抖动就 waiting；GOP 长于 mpegts.js 的追帧阈值时更是每个 GOP 都跳一次 再停一次（实测 GOP 4.2 s 的房间同机也有 85% 时间处于 waiting）。 把旁路挪到 tag 解析完、进缓存之前：预览按 tag 实时收到，与 mesio 路径（在条目进 管线前 tee）一致。写盘循环一个字节不变；旁路仍只是 push，不 await、不返回错误。 实测（arrival-probe，40 s）：同一斗鱼房间直连 CDN 到达连续（最大静默 0.24 s）， 中转修前每 2.0 s 一个 ~940 KB 突发、20 个静默间隙全部 > 1 s。 Refs #1712 #1713 * feat(preview): 快照保留最近 6 s 的 GOP，新订阅者起播就有几秒缓冲 原来快照只含「当前 GOP」：新订阅者从零到一个 GOP 之间的缓冲起步，之后到达 = 消耗， 缓冲永远这么薄，链路上几十到几百毫秒的抖动就 waiting。浏览器直连 CDN 时 CDN 会先 给几秒的 GOP 缓存，中转得给同样的深度。 PreviewSink 里多一个已完成 GOP 的队列（按关键帧到达时刻计，保留 SNAPSHOT_WINDOW = 6 s 以内的），快照 = 文件头 + 序列头 + 队列里的 GOP + 当前 GOP，实际深度在 6 s 到 6 s + 一个 GOP 之间。字节上限 MAX_SNAPSHOT_BYTES = 16 MB（6 s × 20 Mbps），超过先丢最旧的 GOP；单个 GOP 超过 MAX_GOP_BYTES 作废时历史一并放掉（不再连续）；序列头内容变了或 fMP4 换了 init 时历史也放掉（旧 GOP 与新参数不配），内容相同的重发（stream-gears 分段时重放 onMetaData / 序列头）不影响。热路径只多几次 usize 比较与一次 VecDeque push，仍不 await、不返回错误；无订阅者时同样保留（第一个订阅者也要立刻有缓冲）， 每路多占约 6 s 的码率（1080p 2–5 MB）。 `with_snapshot_window(Duration::ZERO)` 给只关心分块判定的测试用。 Refs #1712 #1713 * fix(preview): 客户端掉队时从最近关键帧原地续播，不再断开重连 广播缓冲被覆盖（Lagged）时原来直接结束响应，浏览器看到「连接已断开，2 秒后重连」 的加载态，再花一次 HTTP 往返 + 等下一个关键帧才恢复；带宽长期偏紧的链路上就是 反复「触发加载」。 现在 hub 多一个 `resubscribe(previous, timeout)`：复用原订阅的连接许可（不占第二 个名额），向写入端再要一份从最近关键帧起的快照与新接收端；响应在同一条连接里续 发这份快照——FLV 去掉文件头（`Subscription::snapshot_after_header`，解码器不能中途 再收到文件头；序列头照给，掉队期间可能换过），fMP4 的 init segment 照发（MSE 接受 中途再来一份）。mpegts.js 的 remuxer 会把批次之间的时间戳跳变收平，画面表现为跳 过一段而不是转圈；一次响应最多 MAX_RESYNCS_PER_RESPONSE = 20 次，再多说明客户端 长期跟不上，结束响应交给播放器。每次重对齐 warn 日志带 skipped 与累计次数。 Refs #1712 #1713 * perf(preview): 客户端追赶积压时把广播缓冲里攒着的分块合并写出 实时转发每收到一个分块就写一个 chunked 帧（FLV 一个 tag 几百字节到几十 KB）。 客户端跟得上时缓冲里本来就只有一个，无从合并；追赶积压（起播快照刚发完、链路 抖动之后）时缓冲里攒着几十上百个，逐个写出是几十上百次 socket 写与 chunked 帧。 `coalesce` 在 `recv()` 到手后用 `try_recv` 把已经在缓冲里的后续分块合并成一个 响应块（上限 COALESCE_BYTES = 64 KB），缓冲空着就原样透传不复制，不引入任何等待； 合并途中撞上 Lagged 时把跳过数交回主循环按掉队处理，不吞掉。 Refs #1712 #1713 * fix(ui): 中转模式的播放器维持约 5 s 缓冲，用倍速而不是跳变追帧 mpegts.js 原来对中转、直连一律 liveBufferLatencyMaxLatency 3 s / MinRemain 0.5 s： 缓冲一超过 3 s 就跳到末尾前 0.5 s，等于把服务端刚给的几秒快照直接扔掉，之后只剩 0.5 s 余量，链路一抖就 waiting；GOP 长于 3 s 的流更是每个 GOP 跳一次再停一次。 按取流方式分两套参数（`Players` 新 prop `transport`，LivePreviewPlayer 按实际 source 传）： - relay：liveSync 倍速追帧——落后 > 9 s 用 1.1× 追到 5 s 附近，≤ 5 s 恢复 1×； 只在落后 > 20 s（长时间暂停后）才直接跳到末尾前 5 s。与服务端 6 s 的快照窗口配合， 播放器起播就有约 5 s 缓冲并一直保持。 - direct：沿用原参数（CDN 自带 GOP 缓存，ForgQi 实测异地直连不卡，不动）。 fMP4 的 MediaSource 播放器（只在中转路径上）同样改成：起播对齐到末尾前 5 s、 落后 > 9 s 用 1.1× 追、> 20 s 才跳；另加空洞跳过——服务端掉队重对齐后分片时间戳 前跳，缓冲区出现空洞，停在空洞前沿时跳到下一段起点，不再原地转圈。 Refs #1712 #1713 * style(preview): cargo fmt 与 clippy（len_zero） * feat(preview): /live 支持 snapshot_ms，起播快照按播放器要的缓冲深度回溯 新订阅者拿到多深的快照，播放器就有多深的起播缓冲，也就是多长的中转延迟。之前一律给整个 6 s 保留窗口，只适合「流畅」档；低延迟档要 2 s 就只该拿 2 s，而不是拿 6–10 s 再用 1.1 倍速追 40 s。 - PreviewHub::subscribe_with_depth(depth)：从当前 GOP 往前取，取到第一个关键帧到达时刻早于 「现在 − depth」的 GOP 为止（含），起播缓冲落在 depth 到 depth + 一个 GOP 之间；Some(ZERO) 只给当前 GOP，None 给整个窗口。Subscription 记住 depth，Lagged 重新对齐沿用。 - GET /v1/streamers/{id}/live?snapshot_ms=2000；不带参数行为不变。「开始直播预览」日志多一个 snapshot_ms 字段。 - 保留窗口 SNAPSHOT_WINDOW 仍是 6 s，服务端内存不变；热路径只在有订阅请求时多一次 VecDeque::make_contiguous（历史只有几个 GOP）。 - 单测 +2：深度切分的边界（零 / 跨线 / 大于全部历史 / 空历史）、带深度订阅与重对齐沿用深度。 Refs #1713 #1716 * feat(ui): 中转预览分「低延迟 / 流畅」两档，默认低延迟 2 s，卡了自动升档 ForgQi 在 #1713 下问「中转有办法不延迟 5 s 也不卡顿吗」。主因（整 GOP 成坨下发）修掉后 5 s 是 过度配置：同一条模拟链路（60 ms RTT ± 16 ms、丢包重传停顿、20 Mbps）上四路真实房间扫 1 / 1.5 / 2 / 3 / 5 s 目标缓冲各播 180 s，三路 FLV 从 1 s 起就 0 次 waiting；只有 HLS 来的 fMP4 要盖住一个分片（B 站 1–3 s），3 s 起 0 次、4 s 余量最低约 1–2 s。 - app/lib/live-buffer.ts：缓冲控制统一到一处（原来 mpegts.js 的 liveSync 管 FLV、fMP4 播放器 自己一套 chase）：起播跳到「末尾 − target」，快照落地那几秒里超了再对齐（慢链路上几 MB 要 几秒才到齐，每对齐一次多看 2 s、最多 15 s），稳态超 max 倍速 / 超 hard 跳 / 跳过重对齐留下的 空洞，稳态里缓冲耗尽一次报 onStall。档位：low = FLV 2 s / fMP4·TS 4 s，smooth = 5 s （目标与原 0d41140 相同，倍速阈值 9 → 7）。mpegts.js 在中转模式下关掉自己的追帧，直连一行未动。 - /live 请求带 snapshot_ms = 目标缓冲，起播就是目标深度，不再从 6–10 s 追回来。 - 低延迟档在稳态里卡一次 ≥ 1 s 或 60 s 内两次，本次播放升到流畅档重连（更深的快照起播）， 角标「卡顿，已切到流畅档」；换房间或改偏好即复位。 - 弹层标题栏与监视器工具栏各一个「低延迟 / 流畅」开关，记 localStorage biliup.preview.latency， 默认低延迟；直连模式下不显示。 实测（同一模拟链路，180 s，hub 最新时间戳 → 已渲染）：低延迟档三路 FLV 延迟中位 2.1–2.4 s、 fMP4 2.8–3.7 s，四路 0 次 waiting；流畅档 5.1 s。每 18 s 停 2.5 s 的链路上低延迟档卡两次后 自动升档，之后 130 s 0 次。 Refs #1713 #1716 |
||
|
Noah
|
486676db29 |
feat(ui): 直播预览阶段三——录制中房间实时码率折线图 (#1714)
* feat(api): GET /v1/live-rates 录制中房间的每秒写盘速率瘦端点
/v1/streamers 每次查全表、拼齐全部字段，10 s 一次的节奏不适合调快；码率曲线需要 1 s 粒度，
新加一个只读内存的瘦端点：扫一遍 worker，对每个 Working 的房间读一次阶段一 RateMeter 的窗口均值，
返回 [{id, bytes_per_sec, ts}]。与 /v1/streamers 的 live_bytes_per_sec 同源同值；不新增采样任务、
服务端不存历史、Cache-Control: no-store；注册在 router() 内，--auth 时同一道登录校验。
Part of #1708
* feat(ui): 实时码率数据层与 uPlot 折线组件
- app/lib/use-live-rates.ts：页面内唯一的一份采样源。有订阅者时每秒拉一次 /v1/live-rates，
全部卸载 / 标签页隐藏即停；历史放模块级环形缓冲（每房间最近 3 分钟），组件卸载不清，
切走再切回曲线还在；帧里没有的房间补 null 成断口。useSyncExternalStore 订阅，无新帧不重渲染。
- app/ui/RateChart.tsx：uPlot 折线，full（带时间轴 / Y 轴，单位按窗口最大值自动选 KB/s / MB/s，
Y 从 0 起）与 sparkline（无坐标轴，hover 读数）两种形态；实例在 effect 里建 / 销毁，渲染期不碰 ref，
StrictMode 双次 effect 不留多余 canvas；配色每次绘制时读 Semi CSS 变量，深浅色切换不重建。
无采样 / 未录制只显示「—」占位，不画空图。
- app/ui/LiveRateChart.tsx：next/dynamic 懒加载入口 + 当前 / 峰值 / 均值统计条；
uPlot 与其 CSS 打进独立 chunk（约 23 KB gzip），首屏不含。
- 新依赖 uplot ^1.6.32（本 PR 唯一新依赖）。
Part of #1708
* feat(ui): 三处接入码率折线——弹层可折叠折线、卡片与监视器 sparkline
- 卡片弹层底部新增「写盘速率 · 最近 3 分钟」可折叠区（默认展开，折叠态记 localStorage
biliup.preview.rateChart）：标题行带当前 / 峰值 / 均值，展开时才轮询与加载 uPlot。
- 控制台 / 直播管理页录制中卡片：名称行下一条 60 s sparkline（28 px，hover 显示时刻与数值）。
- 历史记录页「实时监视」：工具栏新增「码率图」开关（默认关，记 biliup.monitor.rateChart），
开启后每路小窗下方一条 60 s sparkline；所有小窗共用同一次每秒请求。
Part of #1708
* style(api): live_rates 测试按 rustfmt 换行
* fix(ui): sparkline 的 hover 读数浮在折线上方，不再被容器裁掉
* docs(readme): 功能列表补充直播预览（封面 / 播放器 / 弹幕 / 码率曲线）
#1708 三个阶段至此完整，在 README 的功能列表里加一条说明。
Closes #1708
* feat(api): GET /v1/ws/live-rates 用 WebSocket 每秒推送码率帧
review 1（ForgQi）：复用现有的 WebSocket 机制推送而不是每秒轮询。WebSocket 不占浏览器对同一主机
HTTP/1.1 的六个并发连接（监视器 4 路视频 + 1 条弹幕 SSE 已用掉五个，这正是当初不用 SSE 的原因），
与日志页 /v1/ws/logs 同款：Origin 与 Host 同源校验、进程内连接数上限（16）、Ping 回 Pong、Close 即止。
连上立刻发一帧，之后每秒一帧，形状与 GET /v1/live-rates 相同；HTTP 版保留给 WebSocket 连不上时回退与 curl 核对。
两个路由都在 router() 内，--auth 下同一道登录校验。单测用手写的最小 WebSocket 客户端走完握手 + 两帧，不引新依赖。
* feat(ui): 码率数据改走 WebSocket；卡片 sparkline 加开关并叠在封面上
review 1（ForgQi）：
- use-live-rates.ts 首选一条 WebSocket /v1/ws/live-rates（服务端每秒推一帧，所有图表共用），
一帧都没收到就断开（反代没放行 upgrade、401）时回退到每秒 GET /v1/live-rates 轮询；中途断开退避重连，
标签页隐藏时断开、可见时重连；快照新增 transport: 'ws' | 'poll'。
- 控制台「进行中」区块头与直播管理页工具栏新增「码率图」开关（默认关，记 localStorage biliup.cards.rateChart，
两页共用）；开启后录制中卡片的 sparkline 叠在封面底部（深色渐变垫底、读数条在图区内；点击仍冒泡到封面打开预览），
封面没有 / 加载失败时退到名称行下方。
* test(api): 码率 WebSocket 连接上限测试改用独立信号量
CI 上与同一二进制里并发跑的 WebSocket 推送测试争用进程级信号量（后者占着一个许可），
上限测试拿不满 16 个而失败；改为像 ws.rs 的日志连接测试那样传入独立的 Semaphore。
|
||
|
Noah
|
072604eed5 |
feat: 直播预览阶段二——内置播放器复用录制流（卡片弹层 + 历史页监视器） (#1712)
* feat(downloader): 直播预览 hub 与写盘旁路（httpflv / hls / mesio） 每路录制任务一个 PreviewHub（寿命 = 整场 execute()，跨分段与断流重试），下载器开始拉流时 attach 一个写入端，在写盘点旁边把同一份媒体字节 push 给它：httpflv 在关键帧写出循环、 stream-gears/hls 在分片 chunk 循环、mesio 在条目进入修复管线前。fMP4 分片流与 HEVC 序列头 标为不可预览；ffmpeg / streamlink / yt-dlp / 边录边传明确不可预览并给出原因。 写入端热路径只做三件事：GOP 缓冲追加、try_recv 订阅请求、broadcast::send。没有 .await、 没有锁等待、没有 ?；订阅请求由写入端在下一次推送时回应，快照（文件头 + 序列头 + 当前 GOP） 与随后的实时分块严格衔接。GOP 快照上限 8 MB，广播缓冲 256 槽 × 64 KB 且无订阅者时不占用， 每路订阅者数由信号量限制；慢订阅者收到 Lagged 后由端点断开让其重连。 Part of #1708 * feat(api): GET /v1/streamers/{id}/live 与列表的 preview 字段 新增 chunked 视频流端点：先发关键帧对齐的快照再接实时分块，Content-Type 按容器为 video/x-flv 或 video/mp2t，Cache-Control: no-store。房间不存在 / 未录制 404，下载器不能 旁路 415（带原因），连接数超限 429（每路 4、进程 16），尚未开始拉流或正在重连 503 + Retry-After。慢客户端 Lagged 或写入端换代时结束响应，由播放器重连。注册在 router() 内， --auth 时与 /v1/streamers 同一道登录校验。 GET /v1/streamers 每项新增 preview: { available, format: "flv" | "mpegts" | null, reason }， 未录制为 null。 Part of #1708 * feat(preview): fMP4 分片流也能预览——init segment 快照、按分片广播、解出 codecs mesio 的 HLS 会话拿到 fMP4 分片时不再标为不可预览：init segment（ftyp + moov）作为文件头 进快照，每个 moof + mdat 分片作为一个关键帧分块广播，新订阅者拿到 init + 最近一个完整分片， 端点 Content-Type 为 video/mp4，列表字段 preview.format 为 "fmp4"。 从 init segment 的 moov/trak/…/stsd 解出 RFC 6381 编码串（avc1.PPCCLL、hvc1.…、mp4a.40.N、 av01 / vp09 / ac-3 / ec-3 / opus / flac）放进 preview.codecs，供前端 MediaSource.isTypeSupported() 校验后 addSourceBuffer；解析只在 attach 后收到 init 时做一次，不在逐分块路径上。 stream-gears 的 HLS 路径没有下载 #EXT-X-MAP 初始化分片，遇到非 TS 分片时标为不可预览并说明原因。 按 ForgQi 在 #1708 的要求把 fMP4 纳入阶段二。 Part of #1708 * feat(ui): 直播间卡片的「预览」弹层——复用录制流的内置播放器 Player.tsx 加 isLive / muted / autoplay / type / codecs 与 onEnded / onError：flv 与 mpegts 走 mpegts.js（直播模式：不攒缓冲、追帧、自动清理 SourceBuffer），fmp4 走一个轻量 MediaSource 播放器（fetch ReadableStream → appendBuffer 串行队列，首个缓冲对齐播放位置，落后 > 3 s 追到 末尾，定期 remove 30 s 之前的缓冲），都以 Artplayer customType 挂载保持 UI 一致； type 未知时用一次 GET 读 Content-Type 再起播。MediaSource.isTypeSupported 不通过时报错并显示 封面 + 原因，不转圈。 StreamerCard 录制中加「预览」图标按钮（不可预览时禁用，tooltip 显示后端给的原因），封面可点 即打开预览；弹层（LivePreview.tsx）关闭即卸载播放器、断开连接。服务端断开（掉队 / 换直链） 自动重连 3 次，之后交给用户手动重试；不可恢复错误 Toast 提示一次。零新依赖。 Part of #1708 * feat(ui): 历史记录页「实时监视」Tab——多路同屏监视器 <LiveMonitor /> 是独立组件：所有正在录制的直播间以小窗网格展示，可预览且在同屏路数内的 直接播放（默认静音），超出的显示封面、点击替换最早开始的一路（先进先出），下载器不能旁路 的显示封面与原因。同屏路数默认 DEFAULT_MONITOR_TILES = 4（可选 1/2/4/6/9，localStorage 记住）， 每路小窗占对应直播间的一个预览连接。正在播放的列表由「用户选择 + 当前可预览房间 + 路数」 纯推导，不在 effect 里 setState。 历史记录页改为两个 Tab：「录制文件」（原表格）与「实时监视」，keepDOM=false 切走即卸载全部 播放器。要把监视器挪到别的页面只需换挂载点。 Part of #1708 * test(preview): 让旁路测试不依赖调度时机 rolling 测试先把订阅请求 poll 进写入端队列再开始写盘，源数据按 2 ms 一块限速送入而不是瞬间灌完 （瞬间灌完时订阅者必然掉队，那是慢订阅者测试覆盖的场景）；慢订阅者测试只断言 「收到 + 被告知跳过 = 全部」与写入端不等待，不再对读取任务在负载下的吞吐做假设。 * fix(ui): mpegts.js 的 MSE 解码失败给出可读提示 典型来源是 TS 的 PES 没按访问单元对齐（如 Twitch 的 HLS），mpegts.js 拆出的帧不完整、浏览器拒绝 解码；原文 "Failed to execute 'appendBuffer'…" 对用户没有信息量，改为说明原因并强调录制不受影响。 * fix(preview): fMP4 与 TS 的快照从关键帧起，而不是从分段边界起 B 站 hls_fmp4 的分段（约 1 s）各含多个 moof/mdat 分片、且分段边界不对齐关键帧（实测 10 次冷启动 只有 1 次首帧是 I 帧）：写入端现在把每个分段按 moof/mdat 切开，读 init 里的视频轨 ID 与 trex 默认 flags、trun 的 first_sample_flags / 首样本 flags / tfhd 默认 flags，视频首帧为同步样本的 分片才作为 GOP 起点。TS 分片起点则嗅探第一个视频 PES 的 NAL 类型（IDR/SPS → 起点，只有普通片 → 追加到上一 GOP，说不准 → 按起点处理）。FLV 路径本来就按关键帧 tag 切，未变。 单测覆盖：分片切分（前导 styp、非同步 / 同步 / trex 默认 / 无视频轨）、跨分段边界的快照、 TS 嗅探（跨包的 PES、音频 PES 在前、非 TS 输入）；另有 #[ignore] 的 B 站真实抓样核对。 * feat(danmaku): 预览播放器的实时弹幕——录制中的弹幕客户端旁路一份到 SSE danmaku crate 的 RecorderConfig 新增可选的 live_tx（tokio broadcast）：每解出一条事件，在写 XML 之前 send 一份（不等待，无订阅者即丢弃），XML 录制路径不变。DownloadTask 按 stream.danmaku 是否存在建一条 256 槽的广播，传给 danmaku_client；新增 GET /v1/streamers/{id}/danmaku（SSE， 每条 event 为 danmaku / gift / super_chat / guard_buy，data 为 {kind, text, name, color, ts}， 进场消息不进；掉队跳过不断开；进程上限 32 路，超出 429；无弹幕客户端的平台 415）。 /v1/streamers 的 preview 字段新增 danmaku: bool，前端据此启用 / 禁用弹幕开关。 Part of #1708 * feat(ui): 预览弹层装载实时弹幕（开关控制），监视器默认关 Player.tsx 新增 danmaku: { url, enabled }：装 artplayer-plugin-danmuku（新依赖，Artplayer 官方弹幕 插件，5.3.0），开关打开时用 EventSource 连 /v1/streamers/{id}/danmaku，每条事件 emit 进弹幕层 （普通弹幕滚动、礼物 / 醒目留言 / 上舰置顶描边），关闭时断开 SSE 并隐藏弹幕层，不重建播放器。 弹层标题栏加「弹幕」Switch，默认开、记在 localStorage（biliup.preview.danmaku）；平台没有弹幕 客户端时禁用并 tooltip 说明。监视器工具栏加同名开关，默认关（biliup.monitor.danmaku）， 对全部小窗生效。localStorage 偏好统一走 useSyncExternalStore（app/lib/use-local-pref.ts）， 同屏路数也改用它。 Part of #1708 * fix(preview): FLV 广播缓冲扩到 1024 槽，装得下 CDN 的整 GOP 突发 斗鱼 CDN 把整个 GOP（~4 s、~320 个 tag、~2 MB）一次突发送达，httpflv 解析器 1 ms 内推完； 刚建立的订阅者还没读到第一个实时分块，256 槽的缓冲就已被覆盖，收到 Lagged 被断开，重连后 又赶上下一个突发——冷启动 10 次只有 1 次播起来。FLV 分块是单个 tag，小而多，缓冲按格式分开： FLV 1024 槽（实测均值 ~10 KB → ~10 MB），TS / fMP4 沿用 256 槽（分块大而少，16 MB 上限）。 回归测试：请求在关键帧回应后紧跟 600 个 tag 同步推完，订阅者仍逐个读到。 Part of #1708 * fix(ui): 弹幕开关禁用时说明是平台不支持还是未开对应 *_danmaku 配置 * feat(danmaku): 多个直播间的实时弹幕可复用一条 SSE（GET /v1/danmaku?ids=…） 浏览器对同一主机的 HTTP/1.1 并发连接只有 6 个：监视器同屏 N 路视频已占 N 个，弹幕若每路再开 一条 SSE，N=4 时就把列表轮询也饿死。新增 /v1/danmaku?ids=1,3,9 把若干路合成一条，事件 JSON 带 id 供前端分发；没有弹幕 / 未录制的 id 静默跳过，一个都没有时 404；一条最多 16 路，占 1 个 连接许可。原 /v1/streamers/{id}/danmaku 保留，走同一实现（事件同样带 id）。 Part of #1708 * feat(ui): 弹幕连接由页面持有并复用，监视器路数按 HTTP 协议限制 浏览器对同一主机 HTTP/1.1 只有 6 个并发连接，监视器 4 路视频 + 每路一条弹幕 SSE 就把列表轮询 饿死；9 路时也只有 6 路能播（实测）。改为 DanmakuFeed：页面（弹层 / 监视器）持有一条 /v1/danmaku?ids=… 连接，各播放器按 id 订阅；构造无副作用、open() 后有订阅者才连，StrictMode 下重复构造无害。同屏路数选项在 HTTP/1.1 下为 1 / 2 / 4，页面经 h2 / h3 加载时放开 6 / 9。 小窗弹幕字号 15px，弹层 22px。 Part of #1708 * fix(ui): 解码失败后关闭弹层必须断开拉流连接 <video>.error 非空时 mpegts.js destroy() 里清 SourceBuffer 的 remove() 抛 InvalidStateError， 后面的 transmuxer.close() 跑不到，连接留在服务端占着该路的预览许可直到刷新页面——真实 Twitch TS 房间（mpegts.js 放不了）连开 4 次弹层第 4 次就 429。销毁前先把 MediaSource 从元素上摘下 （load() 使其 closed，mpegts.js 对 closed 的 MediaSource 跳过清理），destroy 仍抛则直接关 内部 transmuxer 兜底。 Part of #1708 * fix(ui): mpegts.js 换用可中止的自定义 loader，弹层关闭一定断开拉流 上一提交把 MediaSource 从元素上摘下只避免了 destroy() 抛异常，连接仍未断开：mpegts.js 自带的 FetchStreamLoader 在 Chrome 上处于 buffering 状态时 abort() 不调 AbortController.abort()， 而是等下一个 read() 回来再 reader.cancel()——解码出错后读取链已断，那一次永远等不到，连接留在 服务端占着该路许可（真实 Twitch TS 房间：关闭弹层后用 4 条 curl 探，1 条 429；再开一次 2 条 429， 直到浏览器退出才释放）。改为 customLoader：每次 open() 一个 AbortController，abort() 直接调它， 其余与原 loader 一致（直播不需要 Range）。 Part of #1708 * fix(ui): 忽略 Artplayer 在实例销毁后的自动重连，杜绝孤儿拉流连接 真正的泄漏来源：Artplayer 收到 video:error 后每隔 1 s 重设 art.url 最多 5 次（RECONNECT_TIME_MAX）， 不检查自己是否已 destroy。弹层在解码失败时立刻卸载播放器，1 s 后 Artplayer 仍在已销毁的实例上 重设 url → customType 再建一个 mpegts.js 实例、再拉一路流，没有任何人持有它——每次打开泄漏 最多 5 条连接，直到刷新页面。mpegts / fMP4 两个 customType 入口对 art.isDestroy 直接返回； fMP4 入口同时复用上一次的 dispose（同一实例重设 url 时先清掉旧的 MediaSource）。 mock 上用循环发送的 Twitch 坏样本复现：修前每开一次多 1 条连接（1→2→3），修后开关 4 次始终 0。 Part of #1708 * fix(ui): 自动播放重试前确认播放器还活着 * fix(preview): 最后一个订阅者走后释放广播缓冲 tokio broadcast 的缓冲只在被新数据覆盖时丢旧分块，而没有订阅者时写入端不再 send——最后一个 订阅者走后，缓冲里最后 N 个分块就一直挂着（FLV 1024 槽约 10 MB / 路；7 路真实短测中 RSS 在 一轮预览后从 95 MB 停在 117 MB）。写入端发现订阅者归零且缓冲里有数据时换一条新通道，旧缓冲 整个释放；之后的 subscribe() 拿新通道，对订阅者透明。 Part of #1708 * feat(preview): 直播预览取流方式配置（relay / direct）与浏览器直连的能力判定、直链端点 后端与浏览器不在一台机器时，浏览器直接向 CDN 拉一路能省服务器出口带宽（ForgQi，#1712 review 2）。 全局配置新增 preview_transport：relay（默认，复用录制流经 biliup 中转）/ direct（浏览器直连 CDN）， JSON 配置里可选字段，不需要迁移。/v1/streamers 的 preview 新增 direct: { capable, reason }，按 review 1 实测的平台表判定：B 站 / 抖音 / 虎牙 FLV 能直连；斗鱼一 token 一连接、直连会挤掉录制； Twitch CDN 无 ACAO；HLS（TS / fMP4）本版本回落——mpegts.js 放不了 m3u8，直连需 hls.js；其它平台 未验证按不能。新增 GET /v1/streamers/{id}/live-url：当前录制中那条流的直链、容器、平台与过期时间 估计（B 站 expires / 抖音 expire 十进制 Unix 秒，虎牙 wsTime 十六进制；斗鱼的相对秒数不算）， Cache-Control: no-store，与 /live 同在登录校验之内。DownloadTask 随每次 check_stream 刷新直链。 Part of #1708 * feat(ui): 直播预览取流方式——全局设置下拉，direct 模式下浏览器直连 CDN、失败自动回落中转 空间配置 → 全局设置新增「直播预览取流方式（preview_transport）」：经 biliup 中转（默认）/ 浏览器直连 CDN，文案说明两者区别与适用场景。LivePreviewPlayer 按（房间, 配置, 能力）派生取流方式：direct 且 平台能直连时先 GET /v1/streamers/{id}/live-url 拿直链（https 页面下 http 直链换 https），mpegts.js 以 cors / 不带凭据拉 CDN；出错或断开时重取一次直链再播，仍失败回落中转；平台不能直连的房间在 direct 模式下直接走中转。播放器左上角角标：「直连 CDN」或「已回落中转：<原因>」。监视器小窗共用 同一组件。异步结果与回落都带 sourceKey，配置切换时不在 effect 里同步 setState。 Part of #1708 * fix(ui): 直连模式下弹层脚注说明取流方式 * feat(preview): 直连模式向平台另取一条直链，不复用录制那条；斗鱼由此也能直连 ForgQi（#1712）：走直连就不要复用链接，直接获取新链接。/v1/streamers/{id}/live-url 改为对该房间的 平台插件再调一次 check_stream，把新拿到的 raw_stream_url（新 token）给浏览器；平台返回未开播或 出错时 503，前端回落中转。实测新 token 的斗鱼 / 虎牙直链各读 25 s 稳定，同时录制那条连接无重试 ——review 1 观察到的「斗鱼一 token 一连接」「虎牙第二条连接只给 GOP 缓存即断」都是同一直链两条 连接的问题，另取一条就绕开了。能力表：B 站 / 抖音 / 斗鱼 / 虎牙 FLV 能直连；Twitch 无 ACAO、HLS 需 hls.js 仍回落。Monitor 新增 PluginFor 消息按房间 URL 取插件。 Part of #1708 * fix(ui): 直连播够 60 s 后再断按直链到期处理，重取直链继续直连 斗鱼 CDN 的 token 每 5 分钟切一次连接（录制那条同样如此，日志里每 5:01 一次 StreamEnded → 重连）， B 站直链 1 h 过期。之前直连只允许重取一次，第二次到期就回落中转；现在区分「刚起播就失败」 （重取一次仍失败 → 回落）与「播了一阵才断」（视为到期，照常再取）。 Part of #1708 * feat(preview): HLS 直连——直链是 m3u8 时走 hls.js（按需加载），B 站 hls_fmp4 等也能直连 ForgQi（#1712）：HLS 直连也支持一下。新依赖 hls.js ^1.7（动态 import，只在直连模式打开 HLS 房间时 才下载那一个 chunk，首屏包不变）。live-url 的 format 按新直链后缀给 flv / hls；direct_capability 只看平台的跨域放行，不再因容器排除——B 站 .m4s 分片的 CDN 同样 ACAO: *。Player 新增 hls 分支： 跟到最后 3 个分片、后向缓冲 30 s、分片请求不带凭据；清单 / 分片 404、CORS、解码等致命错误报给 LivePreviewPlayer 走重取直链 / 回落中转，清单变为非直播视为断开。Twitch 仍因无 ACAO 回落。 Part of #1708 * feat(preview): live-url 同一房间 5 秒去抖，播放失败后的重取带 fresh=1 绕过 每次打开预览都向平台 API 取一条新直链（带 cookie 时消耗登录态配额，B 站接口有频控）。同一房间 5 s 内的重复请求（StrictMode 双调用、连点、同一房间多个小窗）复用上一次结果并标 cached: true， 不再打平台；前端播放失败后的重取传 ?fresh=1 一定拿新 token（抖音某节点 404、直链到期都靠它）。 缓存插入时顺手清掉一分钟前的条目，表不会长。 Part of #1708 |