acfunlive-remake

9 Commits 1 Branch 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
tamakyi	9c94a72c4d	合并前重排弹道并支持自定义弹幕字号用户反馈两件事：弹幕想再小些；某场合并的 1:19:25 处弹幕糊在一起（把成片抽帧出来一看，是同一弹道上两条弹幕追尾叠字）。重叠的根因：弹幕从上游原版的 .ass 还原成 jsonl 时，lane 是按「只有内容」的宽度反推的（原格式的 x/y 就是这么摆的），而渲染用的是「昵称(uid)：内容 + 头像」的完整宽度 —— 后者占位时间长得多，照搬原弹道必然追尾。用用户那份 3011 条的真实 jsonl 验过：按渲染公式统计，重排前 960 条（31.9%）追尾，重排后 0 条。 - 新增 relayoutLanes：渲染前按最终字号统一重排弹道并重算宽度，公式和录制时的 placeLane 完全一致，所以录制下来的 jsonl 重排后弹道不变（已加用例覆盖）。 - 空弹道用 math.MinInt64 占位：placeLane 的条件是「本条出现时间晚于上一条的让位时刻」，零值下 0 > 0 不成立，第一条弹幕（还原出来的时间可能正好是 0）会占不上弹道、占用状态丢失，后面又跟着乱排。录制的弹幕时间总大于 0，所以原逻辑没暴露。 - 弹道全满（100 条都占着）时退到最早让出来的那条：录制时是直接不写这条，合并时丢一条等于凭空少一句弹幕，压一点也比丢了强。 - 新增 danmuFontSize 设置（合并分区，0 = 跟随弹幕文件）：覆盖渲染字号，头像按同一比例缩放；改了字号会在重排时一并生效，不会因为宽度变了又追尾。验证：layout_test.go 5 个用例；用新 ffmpeg（用户已自行升级到 n9.0.2）在隔离实例上跑了真合并 —— 字号 95 以上的对照（60px → 42px：抽帧量到的弹幕墨迹高度 48px → 36px）、按 1:19:00 裁出的 130 秒片段合并前后追尾 25 条 → 0 条；重跑 verify_settings.py （新增第 8 节覆盖字号字段）、verify_pick.py、verify_streamer_br.py 无回归； go test ./...、gofmt、go vet 干净。	2026-09-25 18:18:30 +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

Author

SHA1

Message

Date

tamakyi

9c94a72c4d

合并前重排弹道并支持自定义弹幕字号

用户反馈两件事：弹幕想再小些；某场合并的 1:19:25 处弹幕糊在一起（把成片抽帧
出来一看，是同一弹道上两条弹幕追尾叠字）。

重叠的根因：弹幕从上游原版的 .ass 还原成 jsonl 时，lane 是按「只有内容」的
宽度反推的（原格式的 x/y 就是这么摆的），而渲染用的是「昵称(uid)：内容 + 头像」
的完整宽度 —— 后者占位时间长得多，照搬原弹道必然追尾。用用户那份 3011 条的真实
jsonl 验过：按渲染公式统计，重排前 960 条（31.9%）追尾，重排后 0 条。

- 新增 relayoutLanes：渲染前按最终字号统一重排弹道并重算宽度，公式和录制时的
  placeLane 完全一致，所以录制下来的 jsonl 重排后弹道不变（已加用例覆盖）。
- 空弹道用 math.MinInt64 占位：placeLane 的条件是「本条出现时间晚于上一条的让位
  时刻」，零值下 0 > 0 不成立，第一条弹幕（还原出来的时间可能正好是 0）会占不上
  弹道、占用状态丢失，后面又跟着乱排。录制的弹幕时间总大于 0，所以原逻辑没暴露。
- 弹道全满（100 条都占着）时退到最早让出来的那条：录制时是直接不写这条，合并时
  丢一条等于凭空少一句弹幕，压一点也比丢了强。
- 新增 danmuFontSize 设置（合并分区，0 = 跟随弹幕文件）：覆盖渲染字号，头像按
  同一比例缩放；改了字号会在重排时一并生效，不会因为宽度变了又追尾。

验证：layout_test.go 5 个用例；用新 ffmpeg（用户已自行升级到 n9.0.2）在隔离实例上
跑了真合并 —— 字号 95 以上的对照（60px → 42px：抽帧量到的弹幕墨迹高度 48px → 36px）、
按 1:19:00 裁出的 130 秒片段合并前后追尾 25 条 → 0 条；重跑 verify_settings.py
（新增第 8 节覆盖字号字段）、verify_pick.py、verify_streamer_br.py 无回归；
go test ./...、gofmt、go vet 干净。

2026-09-25 18:18:30 +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