BiliFlow v0.8.0 发布：我的 B 站下载工具，现在能录直播了
- JARVIS
- 19天前
- 122热度
- 0评论
写在前面：BiliFlow 是什么
今年 5 月我开源了一个 B 站桌面下载工具 BiliFlow，起因很朴素：收藏夹里吃灰的视频越来越多，有些内容平台说没就没，我想把自己有权看的东西归档到本地硬盘。半年迭代下来，它支持了视频、番剧、合集、系列、收藏夹的批量下载，画质从 240P 到 8K，弹幕、字幕、封面、元数据一个不落，还做了 GUI 和 CLI 双模式。
今天发布 v0.8.0，这个版本加上了被问得最多的功能：直播录制。
名字顺带解释一句：Bili + Flow，B 站的"流"。以前这个 Flow 指的是下载媒体流，现在直播流也真的接住了，歪打正着。
一、直播录制怎么用：加房间，剩下的交给它
侧边栏多了个「直播录制」入口。输入房间号、直播间链接、b23.tv 短链都行，点「添加并监控」，工具会把短房间号换成真实房间号并去重。
之后的逻辑很简单：主播开播，它自动开始录；想手动干预，「立即开始」「停止本场」「关闭监控」三个按钮说了算。其中「停止本场」有点意思——保留监控但跳过当前这场，主播下一场开播照常自动录，适合"这场不想留，但人我还要盯"的场景。
画质默认取当前账号能看到的最高档，同档优先 FLV，再往后是 HLS-TS、HLS-fMP4。公开直播间不登录也能添加和监控；登录后按账号实际权限来，账号看不到的清晰度，工具也变不出来。
什么场景会用到它？说几个我自己的：主播深夜播游戏，人熬不动又想看全程；电台区直播当背景音放着，事后想补没回放的那段；还有些直播内容主播自己不留档，错过就是真的错过了。手动蹲开播不现实，交给监控就行。
二、细节控的部分：分段、重连、空间保护
录制这种功能，界面长什么样是次要的，稳不稳才重要。默认值都写死在文档里：
- 开播轮询 60 秒，随机偏移 ±10 秒，避免一窝蜂请求把接口打毛；
- 并发 2 路（可调到 4 路），超出的房间排队；
- 每 30 分钟分段，切割点由引擎在媒体边界确定，可能略晚于设定时间——宁可晚切几帧，不能在帧中间砍一刀；
- 断线重试 2、5、10、30、60 秒递增退避，恢复稳定后重置；
- 触发风控后冷却至少 5 分钟，重新启用监控也不会绕过冷却；
- 磁盘剩余空间不足 2 GiB 自动停录，每 5 秒检查一次，处理完手动恢复。
下播判定也保守：连续两次查询未开播、间隔至少 10 秒，才确认这场真的结束了。宁可多等一会儿，不愿把"主播卡了"误判成"下播了"。
三、任务中心：下载和录制共用一套状态
v0.8.0 顺手把任务中心统一了。下载队列、当前录制、录制历史集中在一个页面，每个房间处于准备、排队、录制、重连还是收尾状态，一眼能看清。
直播页和任务中心共享同一份状态，切页面不会起第二个服务，也不会中断录制。
录制没有百分比进度条——直播不是下载，没有一个"总量"可以算——状态栏显示的是时长、文件大小和实时速度。
录制历史按场次展开。每场录下来是一个独立目录，按「录制目录/主播/真实房间号/开始时间」组织，每次断线重连开一个新的 attempt 子目录，分段清清楚楚。每场还有一份 manifest.json，记着实际清晰度、容器、编码、警告和缺口；异常中断的文件保留在原处，不冒充完整片段——丢了几秒、丢在哪儿，写清楚，不糊弄。想复盘某场直播几点几分说了什么，按目录翻就行。
四、杀手级功能：断线自愈
直播录制最大的敌人不是下播，是断流。主播播到一半网络抖一下、CDN 抽一下风，录制就废一半。
v0.8.0 对此给了一套组合拳：单路播放地址连不上，自动排除这条线路、重新查询其他线路；签名过期自动刷新重取；所有线路都被拒才显示「需要处理」，而且监控本身不中断，主播下一场开播自动恢复尝试。一次性故障不会让整个监控永久躺平。
开发过程中还真踩过一个坑：房间 6963590 这类 HLS-fMP4 直播的子资源走 *.v.smtcdns.net 这个 CDN 域名，最开始被录制引擎直接拒绝，自动录制就这么悄咪咪暂停了。rc6 里 Python 端和原生引擎同步放行了该域名，顺手把"单路被拒就换线"的逻辑补完整。这种 bug，不真挂一晚上直播间根本发现不了——也算半个致敬：感谢主播熬夜，帮我测出了边界 case。
五、为什么录制引擎单独用 Rust 写
老观众可能知道，BiliFlow 主体是 Python + PySide6。但直播录制引擎是基于开源 Mesio 的固定版本构建的 Rust 程序，叫 biliflow-recorder，full 包里直接内置。
原因很实际：录制是个长时运行、不能崩的任务。Python 进程万一 GC 卡顿或出异常，录到一半的流就废了；Rust 引擎作为独立子进程运行，应用和引擎之间用 JSON Lines 管道通信。应用正常退出时引擎完成收尾封口，异常中断也保留文件、记录缺口，不会落下一地半成品。
安全边界也从协议层定死了：媒体子进程通过标准输入拿临时播放地址，不接触 Cookie；数据库、场次清单、应用日志里都不保存完整的签名播放地址。顺便说一句，匿名请求直播接口也要过 WBI 签名，Windows 实测抓过 -352 风控错误，rc3 补齐了签名和密钥缓存，不登录也能正常监控公开直播间。
full 包还内置了从固定源码构建的最小 FFmpeg，负责本地 MP4 转封装：录下来的 FLV/TS 片段可以无损封装成 MP4，普通播放器直接播。转封装保留源文件，失败不会覆盖已有目标文件。
六、合规边界：能看什么，才能录什么
这话放在宣传文里可能不酷，但我还是得写。
BiliFlow 不绕过会员、付费、地区、DRM 或任何账号权限。接口只返回试看、地区受限、DRM 或无完整未加密流时，直接停止；加密、付费直播间不在支持范围内。账号 Cookie 只发给 B 站官方域名，不发往任何第三方服务器。
录下来的内容自己存档没问题，拿去做二次传播就是另一回事了——账号可观看不等于拥有永久复制、传播或商业使用权，工具帮不了你，法律也帮不了你。
七、怎么下载
GitHub Releases 页面提供预构建包：macOS（Apple Silicon）和 Windows（x64）各有 full / lite 两个版本。full 包内置录制引擎和最小 FFmpeg，下载解压就能用；lite 包体积小，需要自己装 FFmpeg。Linux 用户按仓库 README 从源码运行，Python 3.10–3.12 即可。
每个 Release 附带 SHA256SUMS.txt、SBOM 和依赖许可证清单，讲究人可以逐一校验。提醒一句：macOS 包默认未做 Apple 公证，首次打开被拦的话，去「系统设置 → 隐私与安全性」里放行，并确认安装包来自仓库 Release 页面。
八、收个尾
从 5 月到现在，BiliFlow 从一个"自己用的小脚本"长成了带 367 项 Python 测试、双平台发布流水线、SBOM 和完整性校验的正经项目。v0.8.0 的直播录制前后磨了 6 个候选版，今天正式收工。
如果你也有"这个直播间我想一直留着"的时刻，欢迎来试试。觉得好用给个 Star；觉得不好用提个 Issue，最好顺手把复现步骤写上；要是能直接 PR 个修复，那就更好了。
