tamakyi/acfunlive-remake
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
36 Commits 1 Branch 0 Tags
master
Commit Graph
4 Commits
Author SHA1 Message Date
tamakyi a409c5b4dd 新增「转码」分区与手动合并逐任务配置，修掉 PC 端图表文字被拉扁 
一、PC 端图表文字被拉伸（bug）
.spark 折线图把 viewBox 写死成 "0 0 300 48" 又带 preserveAspectRatio="none"：
移动端元素宽≈300px 时缩放≈1 看不出问题，PC 上卡片宽约 1030px，横轴被放大 3.4 倍
而纵轴仍是 48px，图里的 <text> 被整体拉扁。现在按元素实际宽度算 viewBox 宽度
（取不到时回落 300），并监听 resize 重画；preserveAspectRatio 保留不影响 1:1 显示。

二、新增「转码」分区（transcode.go，第七个 tab）
原来只有「录播 + 弹幕 → 成片」一条路，已有成片想压小、换 HEVC、降分辨率只能手搓命令行。
现在从文件列表多选加入，每个文件一行独立配置：编码器、码率控制（跟随源片 / 目标码率 /
质量 CRF·ICQ / 源片百分比）、编码速度、输出帧率、分辨率（只列不高于源片的档）、
音频（拷贝 / 128k / 192k / 去掉），并实时预估产物大小与整批合计。
 - POST /api/transcode/probe | estimate | transcode，都在既有的口令鉴权之后
 - 目标码率模式按「码率 × 时长」出准数；质量模式用单调系数表插值并标注是粗估
 - 落盘沿用合并那套：先在源文件所在目录生成，完成后再 placeOutput 到输出目录，
   失败或中断删临时文件，不留半成品
 - 与合并共用同一张进度卡片和任务位（mergeSlot），串行排队，可暂停 / 停止

三、手动合并改成「一次排多个任务」
原来一次只能合一场。现在多选视频后按「文件名里的录制时间 + 主体名」自动归组
（相邻两段间隔 2 小时内算同一场），每组一个任务卡，各自配弹幕、偏移、输出名和
合成参数（码率 / 帧率 / 字号 / 编码器），可拆组、可移除；服务端串行跑，逐个回传结果。
请求体从 {videos,danmu,...} 扩成 {jobs:[{...}]}，老的单任务写法继续可用。

四、审阅中一并修掉 / 加固的点
 - 容器总码率含音频，直接当视频码率用会错两处：预估体积时又加一遍音轨（算成双份），
   「跟随源片」时把音轨码率也编进视频里。现在分开记「视频流码率」与「容器总码率」，
   转码侧按「视频流码率 → 容器码率 − 音轨 → 体积 ÷ 时长 − 音轨」三级取值；
   合并的自动码率仍按老口径（容器含音频），单独用 streamOrContainerKbps 锁住
 - 源片本来没有音轨时，预估不再凭空加 128 kbps 音频
 - 目标码率加上界（200 Mbps），单位写错的数在开跑前就被挡住（合并的逐任务码率同理）
 - 探测结果加缓存（ffmpeg + 路径 + 体积 + 修改时间），体积估算跟着输入框重发时不再
   每次都起一个 ffmpeg；文件一变（录制中追加、换了文件）缓存自然失效
 - 只有音轨 / 只有封面图的文件、以及正在写入的文件，排队时就被挡住并说清原因
 - probeMedia / parseMediaInfo 合并了原先重复的两套解析（probeDuration 与
   probeVideoStream 各起一次 ffmpeg 解析同一段输出），burnDanmu 现在一次探测拿全
 - 前端：估算参数非法时把服务端给的原因显示在合计行（原来静默不动，像是没改成功）；
   估算请求加序号，慢的旧回包不再覆盖新结果；转码下拉刷新时保留已勾选项；
   跑完的行标「完成 / 失败」并淡化；删掉没有对应元素、从未使用的 CSS 规则

验证
- gofmt / go vet 干净；go build（windows）与 GOOS=linux go build 均通过
- go test ./... 20.9s 全过；go test -race ./... 26.1s 全过（182 → 206 个用例，
  transcode_test.go 新增 20 个）
- 反向验证 C:\OtherFiles\acf-test\reverse_check.py 从 37 项加到 43 项，全过
- 51899 隔离实例 + 真 ffmpeg 冒烟 29 项全过：401 鉴权、probe 的 hasVideo/hasAudio、
  ts 容器（不带每流码率）探测到的视频码率 = 容器 429 − 音轨 127、
  HEVC 按 0.65 折算、参数非法 400 带原因、只有音轨的文件排队即被拒、
  输出目录不存在被拒、两任务队列真转成功并落到指定目录、缩放成片高度确实是 240、
  日志里带「第 n/N 个」和参数摘要
- 页面 jsdom 冒烟 37 项全过、无 JS 报错（分组 / 拆组 / 逐任务参数 / 转码行渲染 /
  跳过无视频轨文件 / 估算失败提示 / 结果徽标）
 2026-09-27 10:36:29 +08:00
tamakyi a24425e16d 修第三批 P2：除零、停止/暂停的响应与状态一致性、临时文件、带 BOM 的 ASS 
一、弹幕滚动时间不再整数除零
   write() 里拿 (PlayResX+length) 做除数，PlayResX 被配成 0 又收到一条空内容弹幕时
   分母正好是 0，直接 panic 终止整场录制。抽成 scrollMarks 并给分母为 0 的兜底
   （退回半个停留时长，至少让它正常显示出来）。

二、点停止不再要等整个块渲完
   jobAttach 原来只看 paused：停止请求若落在 jobGate 之后、ffmpeg 启动过程中，
   job.proc 还没登记，jobStop 拿不到进程可杀，用户得等整个块渲完（大块要几分钟）。
   现在 attach 时发现任务已请求停止就地把它杀掉，上层拿到 errJobStopped，
   卡片显示的是「已停止」而不是「失败」。

三、暂停没挂住就回滚状态
   jobPause 先把 job.paused 置 true 再调 suspendProcess，挂起失败时状态已经改了：
   界面显示「已暂停」而 ffmpeg 还在跑。失败时回滚（只在 proc 仍是同一个进程时回滚）。
   jobResume 同理：恢复不成放回「已暂停」，免得显示在跑却停着。

四、.ass 还原的临时 jsonl 用完就删
   还原结果写不进录播目录时会退到系统临时目录的固定名文件，原来从不清理，
   每失败一次留一份。新增 danmuSource.tempJsonl 标记 + dropTempDanmu 收尾删除；
   只删标记过的临时文件 —— 正常情况下那个路径是用户录播目录里的同名 jsonl，
   删了就是丢数据。

五、带 BOM 的 ASS 能整份解析
   带 UTF-8 BOM 时首行是 BOM+[Script Info]，一个节都进不去，最后只报
   「可能不是弹幕文件」，跟真实原因完全对不上。解析时剥掉 BOM。

六、头像下载期间暂停/停止不用再干等
   单次超时 30 秒 × 3 次重试，最坏 96 秒才响应暂停/停止。单次超时收到 10 秒
   （头像只有几百 KB），并且每次重试前过闸门：暂停在这里等、停止直接放弃，
   不再把剩下的重试跑完；停止也不再打「头像不可用」的告警。

验证：
- gofmt -l 空；go vet ./... 空；go build 与 GOOS=linux go build 通过
- go test ./... 全绿（10.9s）；go test -race ./... 全绿（14.5s）
- 新增 p2_fixes_test.go 8 个用例；本轮 6 项加上一批 6 项共 12 项反向验证全部通过
  （每项临时退回源码 → 对应测试确实失败 → 恢复）
- 51897 隔离实例上完整复测：e2e.py 37 项全过、smoke_extra.py 33 项全过
 2026-09-26 10:07:30 +08:00
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