tamakyi/acfunlive-remake
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
22 Commits 1 Branch 0 Tags
4e8471deea64be977d3887366d5cdb45cb93c761
Commit Graph
6 Commits
Author SHA1 Message Date
tamakyi c26eb4c648 合并任务排队串行，不再互相顶掉进度和杀错 ffmpeg 
审查发现：全局只有一份任务进度状态，但没有任何东西拦住两个合并同时跑。

1. 为什么必须串行
   jobStart() 原来是无条件重置全部字段的。多个主播同时下播（很常见），
   或者自动合并跑着的时候在页面上点一次手动合并，就会有两个任务同时跑：
   后启动的把前一个的输出名、进度、已渲染时长全部清零；更糟的是 jobStop()
   只认最后注册的那个 ffmpeg，点「停止」杀的是别人家任务的进程，
   而自己那个继续跑；两个任务还会互相读到 stopped 标记而提前退出。
   界面上看只是一个进度条乱跳，背后是合并结果可能张冠李戴。

2. 怎么串起来的
   加一把 mergeSlot 锁占任务位：
   - 手动合并用 TryLock，抢不到直接 409 并告诉用户现在谁在跑 —— 它是一次
     HTTP 请求，不能让人干等几十分钟。
   - 自动合并用 Lock 排队等待，它本来就是后台任务，丢掉白录一场。
   jobStart 改成返回 bool：已经有任务在跑时返回 false 且一个字段都不动。
   这样即使以后有调用方忘了先拿任务位，也只是失败而不会互相覆盖。

3. 顺带修「panic 之后卡片一直转」
   原来 jobFinish() 写在 autoMerge / mergeHandler 的正常返回路径上，任务内部
   一旦 panic（外部 safeGo 的 recover 兜在外层）它就永远不会执行，任务会一直
   停在 active，界面上的进度条再也不动，ffmpeg 也失联了。
   现在统一走 runMergeExclusive()：任务位用 defer 释放，panic 翻译成 error，
   保证 jobFinish 一定能跑到。

4. 之前 ban 掉的 jobActive() 接回来了
   它本来就该是这道护栏，写了却没人调用，现在用于判断要不要提示「在排队」
   以及拒绝新任务时报出正在忙的任务名。jobState 的锁改成 RWMutex 供它读。

已验证：
- 新增 4 个用例：TestJobStartRejectsWhenBusy（被拒时 Must 一个字段都不改，
  包括进度必须还是原任务的）、TestMergeSlotTryLockExclusive、
  TestMergeSlotSerializes（4 个并发任务必须全跑完且不重不漏）、
  TestMergeExclusiveReleasesOnPanic（panic 后必须拿到任务位 + 翻出错误）。
- 反向验证：把 jobStart 的占用判断临时改成 `if false && job.active`，
  TestJobStartRejectsWhenBusy 立刻报「应当返回 false」。
- 现有测试跟着走真实链路（progress_test 加了 startJobForTest 统一先收尾、
  manualmerge_test 走 execManualMerge 独占执行）—— 改之前这些用例单独跑过、
  连着跑会失败，正是因为前一个用例把任务状态留在了 active。
- gofmt / go vet / go build / GOOS=linux go build / go test / go test -race 全过。
 2026-09-26 02:41:29 +08:00
tamakyi 7dd2487cb8 合并任务的可视化进度、预计剩余时间与暂停/停止 
用户反馈：合并的进度只体现在日志里（ffmpeg 的 frame=/speed= 行），看不出
百分比、当前环节和还要多久，也没有办法中途暂停或放弃。

1. 新增全局任务状态（progress.go）
   一份状态同时服务自动合并和手动合并，记录阶段、总进度、速度、帧率、
   已处理时长、输入/预计输出/已写出体积、ETA 和速度折线采样点。
   总进度按阶段加权：准备 0.02 / 分段拼接 0.08 / 获取头像 0.10 /
   画面渲染 0.75 / 拼接与落盘 0.05，渲染阶段按「已渲染 ÷ 总时长」折算。
   ETA 在渲染阶段用「剩余时长 ÷ 倍速」，其它阶段按已用时间线性外推。

2. 用 ffmpeg 的 -progress pipe:1 取结构化进度
   runFFmpeg 拆出带回调的版本：解析 out_time_us / speed / fps / total_size，
   分块渲染时把块内时间折算到整片时间轴，并把已完成块的字节数累计进来。
   ffmpeg 自己的统计行仍在 stderr，单独用命令行时不会少东西。
   预计成片体积先按「（视频码率 + 音频 192k）× 时长 ÷ 8」估，渲染过 5%
   之后换成「已写出字节 ÷ 已完成比例」外推（estimateAudioKbps）。

3. 暂停 / 停止
   Windows 用 ntdll 的 NtSuspendProcess / NtResumeProcess（照任务管理器
   的「挂起」语义），Linux 用 SIGSTOP / SIGCONT，放在带 build tag 的
   jobctl_windows.go / jobctl_unix.go 里。
   非 ffmpeg 环节（下载头像、逐块渲染之间）用 jobGate 闸门生效。
   停止 = 杀掉当前 ffmpeg 并置位，各层返回 errJobStopped：不再回退其它
   编码器、不落成片、清掉分块临时文件，任务以「已停止」结束（而不是失败）。

4. 接口
   GET /api/job 给页面轮询任务快照；POST /api/job/control 接受
   pause / resume / stop，没有任务时 409、未知动作 400。

5. 界面
   监控分区顶部新增「转换任务」卡片：阶段步骤条、总进度条、实时指标、
   预计剩余时间、源片与预计成片的体积对比条、渲染速度折线（每秒一个点、
   最多两分钟），以及暂停/继续/停止按钮；页面最顶上再加一条全局细进度条，
   切到哪个分区都看得到。有任务时每秒轮询，空闲时 4 秒。任务结束后卡片
   再停留 20 秒显示结果。

已验证：
- 新增 progress_test.go 12 个用例：阶段权重和为 1、进度按阶段折算、阶段
  不回退、ETA、体积预估与实测外推的切换、折线采样、暂停/停止的闸门语义、
  控制接口在无任务时报错、speed 字段与 -progress 文本的解析。
  测试里把 errJobStopped 和真失败区分开（jobErrText）。
- 端到端（独立实例 51897 + 独立 config，全程没碰仓库里的实例和
  acfunlive.exe）：跑通完整合并，进度到 100%、预计体积与成片实际大小
  相差 0.4%；暂停后进度冻结且 ffmpeg 的 CPU 时间 5 秒内 0 增长；
  继续后进度恢复；停止后任务以「已停止」结束、没有半成品成片、
  没有残留临时文件、没有残留 ffmpeg 进程。
- 界面（playwright 驱动系统 Edge）：步骤条 5 个阶段且只有一个处于进行中、
  进度条与顶部细条同步、5 项指标（速度/帧率/已处理时长/已用时间/已写出）、
  ETA 文案、体积对比条两段宽度按比例、折线有采样点、界面按钮能暂停/继续/
  停止、结束后按钮隐藏且文案是「已停止」、深色主题与 390 宽移动端无横向溢出。
- 过程中修掉三个真缺陷：停止时残留分块临时文件（part 登记晚于渲染）、
  界面「继续」按钮点不动（onclick 写死了 pause）、停止被当成失败报红
  （现在按 message 区分 已完成/已停止/失败）。
- gofmt / go vet / go build / GOOS=linux go build / go test 全过。
 2026-09-26 02:05:47 +08:00
tamakyi 348e3bd675 档位改成「自动·第二高 + 实际档位」的下拉；手动合并也推送；头像缓存挪到程序目录 
三件事：

1) 主播列表的录制档位
- 一律是下拉，不再有手填输入框。第一项「自动 · 第二高」（值 0）= 按这次读到的
  档位排序自上往下取第二高（只有一档就用它，读不到档位表才退回最高档）；
  后面依次列出实际档位。选最高/最低/中间某一档直接点它，手动选过之后
  「自动」仍留在列表里，随时能改回去。
- 语义变化：0 不再被写死成某个具体码率。原来记录档位时会把「没选过」的主播
  按第二档定下来（写进 config.json），现在只在取流时解析，所以主播换了档位表
  也能跟着走；app 启动时的补齐逻辑（applyCachedDefaultQualities）随之去掉。
- 解析规则统一到 resolveQualityBitrate：0 = 第二高，>0 = 不超过它的最高档，
  都比它高时退回最低档；「自动」项会把解析到的档位名带出来
  （自动 · 第二高（当前 = 蓝光 4M））。/api/status 和档位接口都多了 qualityBitrate。
- 点「档位」按钮时先给一句「正在读取码率档位…」：主播没开播时服务端要重试三次
  才放弃，约 5 秒，之前这段时间界面没有任何反应。

2) 手动合并完成也推送（这就是「MeoW 只在测试时成功」的原因）
- 原来只有自动合并调 sendNotify，手动合并从头到尾没推过，所以事件开着、渠道也通
  却一直收不到。现在手动合并完成后同样按 mergeDone 事件推送两个渠道。
- 手动合并没有 uid，会拿成片名（再退到视频名）去对已有主播名，只有一个能对上时
  才在文案里带上主播名，对不上就用「手动合并完成」。

3) 头像缓存挪到程序所在目录
- 原来存在「录播目录/avatar_cache」，换一次保存目录（甚至换盘）就要把同一批观众
  的头像重新下一遍（一个头像可能 0.5MB）。现在统一放程序目录下的 avatar_cache。
- 旧位置作为只读回退：命中就搬过来（同盘改名，跨盘退回复制），不重复下载；
  没被用到的旧文件留在原地，用到哪个搬哪个。

验证：
- 新增 avatar_test.go 两个用例（缓存路径、旧位置搬家）和 notify_test.go 的
  TestManualMergeSendsMergeDoneNotify（真跑一次合并，断言 webhook 与 MeoW 各收到
  一条 mergeDone，且从文件名认出主播）；qualities_test.go 改成新语义，新增
  resolveQualityBitrate（7 种档位/码率组合）和 guessUIDByFileName。
- 端到端：把旧位置的头像缓存放在录播目录、头像地址指向连不通的端口，合并仍然成功
  且画面里有那张头像（纯红像素 400 个），证明是搬来的而不是重新下载的；文件也从
  录播目录搬到了程序目录。
- 浏览器：verify_streamer_br.py 重写成档位下拉的 20 项断言，verify_qualities.py
  更新为新语义，两个都全过；verify_settings.py / verify_pick.py / verify_danmu_match.py
  无回归；go test ./...、gofmt、go vet 干净。
 2026-09-25 20:03:24 +08:00
tamakyi a891094f29 合并默认改用 HEVC、码率按「源片 + 500」自动算；手动合并自动匹配同名弹幕 
两件事：

1) 合成码率与编码器
- `mergeBitrate` 填 0（默认）时不再是 ICQ 质量模式，改成「源片视频码率 + 500 Kbps」：
  烧进去的文字和头像都是高频细节，和源片同码率会糊，所以留一点余量；探测不到源片
  码率时才退回质量模式（QSV 用 ICQ 22、软编用 CRF 18），下限 800 Kbps。
- 编码器默认换成硬件 HEVC：候选顺序 hevc_qsv → h264_qsv → libx264，QSV 可用性按
  编码器分别探测（原来只探 h264_qsv）。HEVC 在 mp4 里打 `hvc1` tag，Apple 系
  （QuickTime / Safari / iPhone）才认 —— ffmpeg 默认写的是 hev1。
- 日志现在会打印编码器优先顺序和实际用的码率。

  实测（90 秒真实素材，源片 3217 kbps，密集弹幕）：日志「按源片 3217 kbps + 弹幕
  余量 500 kbps 取 3717 kbps」，成片 codec=hevc、tag=hvc1、实际 3.71 Mbps。
  之前同样是这份素材：h264 + ICQ22 会飙到 7386 kbps（79 MB），改成自动码率后
  43.7 MB，体积小了 45% 画质还更稳。

2) 手动合并自动匹配弹幕
- 新增 `GET /api/merge/danmu?video=…`：按视频名找同目录下的同名弹幕，依次试
  `.jsonl`、`.ass`、`.nick.ass`；同目录没有就拿文件名去录播目录再找一次。
- 页面在「手填/粘贴视频后失焦」「多选弹窗选完」「从文件列表多选后」「点预览或
  开始合并时弹幕框还空着」这几种情况下都会自动匹配并提示；弹幕框里已经有内容时
  绝不动它，找不到也保持为空让用户自己选。
- 填回框里的写法与浏览弹窗一致：录播/成片目录下的只写文件名，别处的写绝对路径。

测试：新增 encode_test.go（编码器顺序、参数与 hvc1、自动码率、ffmpeg 输出解析）
和 TestFindDanmuForVideo（7 个子用例：优先级、录播目录回退、绝对路径、找不到返回空）；
仓库外的 verify_danmu_match.py 4 组断言全过，verify_pick.py / verify_settings.py 重跑
无回归；go test ./...、gofmt、go vet 干净。
 2026-09-25 19:23:44 +08:00
tamakyi e35a4f7cef 合并先在本地做完再落到成片目录；头像支持 gif 和静态 webp 
起因是核查合并落盘和头像处理时发现的两处问题：

1) 成片落盘：ffmpeg 原来是直接写目标目录（automerge.go 里那句注释「不再事后再
   移动一次」）。成片目录可能是网络盘或外接盘，写到一半失败会在那里留下一个
   看起来正常的半成品。现在改成先本地合成、完成后再落盘：
   - 输出先写到弹幕文件所在目录（本地）的 acfunlive_chunk_merging_*
   - 写完后由 placeOutput 落盘：同盘直接 os.Rename（瞬时），跨盘退回拷贝；
     拷贝中途失败留下的是 *.acfunlive.part，一眼看得出不是成品
   - 成功或失败都会清掉本地临时文件，失败时两个目录都不留东西
   - 临时文件沿用 chunkTempPrefix，不再出现在文件管理的列表里（listFiles 过滤）
   - 启动时清理上次残留；删不掉时提示一句 —— 强杀程序不会连带杀掉 ffmpeg
     子进程，它可能还在写这个文件，这种情况下次启动会再清一次

2) 头像：downloadAvatar 只注册了 jpeg 和 png 解码器，AcFun 上的 gif 头像必然
   解码失败，静态 webp 同样。加上 _ "image/gif"（多帧取第一帧）和
   _ "golang.org/x/image/webp"（x/image 本来就是直接依赖，零新增模块）。
   动画 webp 两条路都解不开（x/image 报 invalid format，ffmpeg 5.0 也不行），
   保持只烧文字。解码失败时错误信息带上 Content-Type，方便排查是哪张图。

在隔离实例上用真 ffmpeg 跑了真合并验证：gif 头像和 webp 头像都进了缓存并烧进
画面（抽帧确认圆形头像）；日志里 ffmpeg 的输出是 record 下的临时文件，完成后
才出现在 merged；坏视频合成失败后成片目录没有半成品、录播目录零残留；合并
中途强杀留下的临时文件在下次启动时被清掉。

新增 output_test.go（7 个）和 avatar_test.go（3 个）；go test ./...、gofmt、
go vet 干净。
 2026-09-25 17:34:31 +08:00
tamakyi ed4e47e305 init 2026-09-25 13:16:54 +08:00