这是 liuchuancong/pure_live 的功能性 fork。项目保留上游的多平台直播聚合能力，本仓库目前只重点维护一件事：替换音频流——用直播间 A 的画面搭配直播间 B 的声音。
为什么要做这个功能，其实也没什么复杂的理由：比赛官方流画质不错，但是想听 6657；开两个网页自己静音、切窗口、对延迟，调完半天图一乐比赛已经打完了。
比如你正在看某个赛事官方直播间：
- 官方直播：有高清画面
- 6657：有 Machine 解说
- 你：两个都想要
- 浏览器开两个窗口：😭
- 手动静音：😭
- 两边自己对时间：😭
- Pure Live 双流解说：😎👍
爽！这才叫直播！
所以干脆：
官方、别的二路（哇肉铺子💤）：出画面。
6657：出声音。
弹幕：讨论祥子。
3.0.23 候选加入 Kick、YouTube 公开直播与弹幕，并修复 Twitch 分区漏主播的问题。支持范围与测试记录见接入说明。
3.1.0 统一整理网页登录、账号退出和实际画质显示。B站保留扫码，其他已有账号的平台优先打开官方登录页，手动 Cookie 收进高级选项；Linux 缺少当前网页组件，只保留B站扫码和高级入口。各客户端云构建与验证状态见3.1.0交付记录，登录不保证平台开放所有画质。
3.1.1 修订B站登录态弹幕凭据恢复，并精简退役登录页面的重复测试。排查与验证记录会区分自动化验证与真实账号测试，不保证所有重连都是同一原因。
3.1.2 为 Windows 和 Mac 加入带弹幕的小窗播放，支持置顶、拖动、缩放和恢复原窗口；斗鱼在每次启动后后台尝试续期 Cookie。首次需在应用内完成斗鱼登录以保留长期凭据，续期失败会在账号页显示状态。本轮还修复虎牙取流签名与 FLV / HLS 凭据混用。画面与侧栏弹幕可单击复制正文，顶部标题栏不再遮挡前两行弹幕的点击。本轮说明与验证记录。
3.1.3 候选同步最新桌面分支的弹幕单击复制与顶部栏透传修复，并补上滚动弹幕的右键菜单；双击仍切换全屏。Mac 小窗自动帧率跟随所在屏幕，默认字号调到 14，窄窗也减少缩字；自定义字号和手动帧率保留。测试与构建状态见本轮记录。
macOS 是目前已经实际验证的目标平台；Windows、iOS / iPadOS 已开放迁移测试。进入直播间 A 后，可以从关注列表选择一个在线直播间 B 作为解说源：A 继续负责画面、标题、画质和线路，B 负责声音。
最典型的用法就是看赛事官方高清流，同时听 Machine 解说。不会因为选择了 B 就突然把画面切成 6657，主播负责嘴就行了，没让主播负责脸。
两个直播间的直播延迟显然不可能一致，因此校准时可以临时查看 B 的画面，对照比赛画面、屏幕时间戳或者实际事件调整偏移。目前支持 10ms、100ms、500ms 三档步长，可以随时重新校准，也可以直接换一个 B。
10ms：我就微调一下。
100ms：感觉差一点。
500ms：哥们你这已经不是音画不同步了，你这是两个平行宇宙。
双流模式下可以选择显示 A 或 B 的弹幕。
选择 A，基本就是正常看比赛：A 在打什么，弹幕聊什么。
正常。
非常正常。
甚至正常得不像直播间。
选择 B 也可以。如果 B 是 6657，那情况可能稍微发生一点变化。
比赛画面：
Spirit vs Falcons
弹幕：
丰川祥子
爆了？
这也能输啊
一进来就看到……
银行业
🏹🏹🏹
主播说主播的。
弹幕聊弹幕的。
互不打扰。
选择 B 时，弹幕时间会跟随当前双流偏移一起调整。比如 B 的声音被延迟了 2 秒，B 的弹幕也会一起延迟 2 秒，主要是为了避免：
弹幕：爆了！！！！
画面：五个人还在家里买枪。
这种提前剧透式残局。
如果 B 连接失败，会自动恢复 A 原本的声音，不至于解说流一炸整个播放器突然进入默片时代。之后可以重新连接或者更换解说源。
双流模式目前不支持录制。
更完整的操作方式、同步逻辑以及各平台测试记录见：双流解说平台调试与移植。
本仓库长期维护目标只有双流解说及其直接相关的播放、同步和弹幕问题。不是 Pure Live Plus，不是 Pure Live Ultimate，更不是“既然 fork 了那顺手把整个软件重新维护一遍”，我的终点就到这里了。
其他问题仍然可以在本仓库提出，我们会先判断到底是这个 fork 自己爆了，还是上游已经爆了：
- 如果有人反馈，并且上游已经存在对应修复，会先确认修改不会顺手把双流功能一起抬走，再合并相关修复。
- 平时不会主动追随上游每一次提交。上下游目前都存在较多 AI 辅助改动，AI 写代码本身没什么，问题是维护者没有时间每天对着几十个 commit 玩扫雷。未经审查地频繁同步，很容易得到“上游修了三个问题，本 fork 新增五个问题”的现代软件工程奇观。
- 范围小、能够稳定复现并明确验证的问题，如果在本仓库完成修复，会尽量把通用部分向上游提交 Pull Request。
- 大型问题、通用功能需求或者和双流完全无关的系统性问题，建议直接提交到 上游 Issues。
所以这里的同步原则基本就是：需要再拿，拿了先测。
而不是：
git fetch upstream
git merge upstream/master
😮哦？
爆了
提 Issue 时请附上平台、应用版本、直播平台和房间号、复现步骤以及相关日志。双流问题最好顺便说明 A/B 分别是什么房间、两边单独播放是否正常、问题出在画面/声音/弹幕哪一侧。不要只留一句“不能用了”，然后维护者和你共同参与大型有奖竞猜。
另外请勿公开 Cookie、Token 或其他账号凭据。GitHub Issue 是公开页面，不要为了证明登录失败把 Cookie 整段贴出来。
这个不是烂梗。
这个是真能爆。
上游项目：liuchuancong/pure_live。本仓库是其衍生版本，不代表上游，也不由上游维护或提供支持。
因此如果这个 fork 的双流功能坏了，请不要跑去上游：
你们这个 6657 模式怎么没声音？
上游维护者：
😮哦？
本仓库根目录的 LICENSE 是 GNU Affero General Public License v3.0（AGPL-3.0） 正文，本 fork 继续以该许可证发布。复制、修改、分发或以网络服务形式提供前，请阅读并遵守许可证原文。
原项目以及各次修改的著作权归相应贡献者所有。本 README 只是说明项目关系和当前仓库状态，不会因为写了几句烂话就改变 Git 提交历史、版权声明或者许可证条款。
仓库中的第三方依赖和内置组件也可能使用各自的许可证，具体以组件目录中的 LICENSE 以及对应上游声明为准。不是根目录写 AGPL，就代表依赖树里所有东西突然一夜之间全 AGPL 了。
License 不是野榜。
本项目是非官方第三方客户端，与各直播平台之间不存在隶属或授权关系。直播内容、平台名称和商标归相应权利人所有，使用本项目时请遵守所在地法律以及对应平台规则。
以上只是项目关系和仓库现状说明，不是法律意见；许可证具体权利与义务以 AGPL-3.0 原文 为准。这段建议真看一下，别“感觉应该没问题”。
- 测试包：本仓库 Releases
- 自动构建：GitHub Actions
- 开发、构建和历史测试记录：文档索引
- 旧维护阶段流程存档：MAINTENANCE_POLICY.md
MAINTENANCE_POLICY.md 中的维护范围已经被当前 README 取代，它现在属于历史文档。不要考古完以后发现两份文件写得不一样，然后开始：
哦？改口了？
项目使用 Flutter，具体工具链版本以 .fvmrc、pubspec.lock 和平台构建配置为准。不要拿一个不知道哪年装的 Flutter SDK 跑炸以后直接宣布项目兵败如山倒。
flutter pub get
flutter test
flutter build macosWindows 构建需要在 Windows 环境执行：
flutter build windows目前没支持“在 macOS 上凭借强烈的主观愿望生成 Windows 构建”。
感谢 Pure Live 上游项目 以及所有原作者、维护者和贡献者。没有上游工作，就没有这个功能性 fork。
这句没什么好玩梗的，是真的。
总之，如果你的需求就是：
我要官方比赛流的画质。
我要 6657 的声音。
那这个 fork 基本就是为了这个需求存在的。A 出画面，B 出声音，延迟自己调，弹幕自己选，B 炸了回 A。
至于为什么为了看一个主播，最后 fork 了一个 Flutter 项目、写了双流同步、弹幕延迟和跨平台迁移……
来都来了。