acfunlive-remake

tamakyi/acfunlive-remake

Fork 0

Commit Graph

Author	SHA1	Message	Date
tamakyi	6f3c8096b4	修分块渲染的弹幕轨迹：跨块续画 + 文字头像同源，并补失败推送与输出帧率设置 1. 密集弹幕时头像偏离轨迹、弹幕突然加速、之后一段时间屏幕空白分块渲染的固有问题，三个毛病叠在一起： - writeChunkAss 把 \move 的起止时间截断到块边界（End=min(t0+10, chunk.end)），但 x2 写死成 -Width —— 等于把 10 秒的路挤进可见的那零点几秒里，文字直接飞过去。而头像 overlay 的 x 一直是「固定 /10 秒 + 真实 t0」，于是同一时刻文字已经走到左边、头像还在半路，看起来就是「头像掉队（移动变慢）」。 - 块尾还会被单块上限收紧成「下一条弹幕出现的时间」，最极端时窗口只剩 0.01 秒。 - 每块只画「本块新出现」的弹幕，跨块的续画没有：块头屏幕上只剩刚出现的几条，要 10 秒才重新填满 —— 就是「弹幕突然加速，然后一段时间屏幕上什么都没有」。改法：文字层改成按绝对时间算轨迹（danmuTextX / danmuAvatarX / avatarXExpr 同源），任何一块里的文字速度都等于真实速度；分块器改成「续画（起播时间在 start-10 ~ start） + 本块新出现的」，块尾取「下一条弹幕的起播时间」，这样每条弹幕只在唯一一块里算新出现，显示期间跨过的后面几块把它接着画，一帧都不缺。代价是每块要多画一倍多的弹幕，所以顺手把头像一个「绝对路径 + 每人一行 scale」改成「预缩放 + 短相对路径」（prepareAvatarInputs / scaleAvatarFile），每条从实测 241 字符降到约 130，单块上限才能从 120 抬到 200（200 条 ≈ 26600，仍低于自检阈值 30000 和 Windows 的 32767）。 2. 合并失败没有任何通知 notify.go 新增 mergeFail 事件与 notifyMergeFailure()，接在 autoMerge() 和手动合并的失败分支上。正常结束、文件里没有弹幕、以及用户自己点的停止都不算失败，不推 —— 最后一种推「合并失败」会误导。配置项 notifyMergeFail 默认开，且和 notifyEnabled 一样在 Unmarshal 之前预置 true，免得老设置文件升级后被静默关掉。 3. 低帧率录播里的弹幕一格一格跳新增设置项 mergeFps，默认 0 = 跟随源片（什么都不做）。只在目标高于源片帧率时才加 fps 滤镜，而且必须加在字幕/头像之前 —— 加在之后只是把已经画好的几帧复制一遍，看起来还是卡。上限 240。 4. 顺带 - -danmuburn 命令行模式不走 initialize()，exeDir 从来没被赋值：头像缓存会落到「当前工作目录/avatar_cache」，旧版还会把这个相对路径写进滤镜，而 ffmpeg 的工作目录是弹幕目录，报「打不开 avatar_cache\xxx.png」整块失败。 - cleanTempFiles 见到目录就 continue，预缩放头像那个临时文件夹永远清不掉。 - command_len_test 不再用会过期的「每条 241 字符」估算，改成真跑一遍最坏情况；探针的头像路径也改成真实的短相对路径（原来量的是早已不存在的长绝对路径）。 - 新增 TestWebuiSettingFieldsMatchInputs：把页面里 JS 的 settingFields/numberFields 抠出来，跟所有 input/select/textarea 的 id 比对，漏登记的设置项会被抓住。验证 - gofmt / go vet / go test（174 个）/ go test -race / staticcheck / GOOS=linux go build 全过。 - 反向验证 32 项全过：把每个修复临时退回，对应测试确实失败。 - 真实片段实测（2023AcFun 晚会 120 秒高峰段，689 条弹幕，10 秒窗口内最多同时 140 条）：旧 6 块 / 绘制 689 次 / 54.1% 的弹幕文字被加速（中位 2.12x，最差 500x）/ 54.2% 有轨迹缺口（中位缺 5.29 秒）/ 78.3s；新 5 块 / 绘制 984 次 / 加速 0% / 缺口 0% / 98.8s（+26%）。对照帧里旧版在块尾前 0.1 秒屏幕已经全空，块头后 0.4 秒仍然全空；新版一直是满屏。 - 输出帧率：15fps 源配 mergeFps=60，成片 60fps，1 秒内 60 帧哈希互不相同（不是复制帧）；默认设置下成片仍是 15fps。	2026-09-26 16:34:47 +08:00
tamakyi	be8ec5f953	通知推送拆成两个渠道：QQ 机器人和 MeoW，各自带开关和测试连通用户要求两件事：① QQ bot 推送要能测连通、并加一个开关；② 照 MeoW 的接口文档（https://www.chuckfang.com/MeoW/api_doc.html）加一个推送渠道，同样要有测试和开关。确认过的三个决定：QQ bot 就是现有 webhook；事件勾选两个渠道共用、开关按渠道分开；MeoW 只填一个昵称。 1) 通知推送改成「共享事件勾选 + 每渠道一个开关」 - notify.go: notifySetting 扩成两个渠道，新增 qqReady()/meowReady()； sendNotify 按渠道各自起后台 goroutine 分发，事件没勾选、或两个渠道都没启用时什么都不做 - config.go: 新增 notifyEnabled（QQ 机器人渠道开关）、meowEnabled、 meowNickname、meowMsgType、meowHtmlHeight、meowImgUrl - 关掉开关只是暂停推送，地址、昵称这些配置都留着，随时能再打开 2) 老配置的兼容（重要） - notifyEnabled 是普通 bool，老 config.json 里没有这个字段会解成 false，升级后会把已经配好的推送静默关掉 - 解法：loadConfig() 里先置 true 再 json.Unmarshal（Unmarshal 只覆盖文件里出现的字段），默认值里也写 true；文件里显式写 false 的仍然会关掉 - 已加回归测试 TestNotifyEnabledBackwardCompat 覆盖三种写法 3) MeoW 渠道（新增 meow.go） - 按文档走 POST {昵称}，title/msg/url/imgUrl 放 json body， msgType/htmlHeight 是 query 参数（文档明确说这两个不属于 JSON 参数） - 文档自己前后矛盾：响应格式那节写 msg，示例写 message，两个字段都解析 - 空字段一律不放进 body：body 里的 title 优先级高于路径参数，传空串会把 MeoW 的默认标题顶掉 - 业务状态码翻成中文（400 参数错、403 内容被拦、404 昵称未注册、 429 频控、500 服务器错误），失败信息直接显示在页面上 - msgType 为 html 时渲染成 HTML（首行加粗、链接可点、内容转义），高度默认 200、范围 40-2000；事件正文复用 webhook 的那份 text 4) MeoW 的错误昵称会封 IP，所以加了保护（踩出来的） - 实测用不存在的昵称打真实接口，返回的提示是「一天之内累计3次输错对方昵称您的IP将被封禁」。而开播+开始录制+下播+合并完成一天轻松触发 4 次，昵称配错就会把用户 IP 封了 - meow.go: 新增 meowBadNick 记录，pushMeow 收到 404 就记下这个昵称； sendNotify 和测试接口命中记录时直接跳过/拒绝并说明原因，改掉昵称或重启程序即恢复 - 只有 404 触发拦截：429 是频控、400 是参数问题，都应该继续尝试 - 已加测试 TestMeowBadNickGuard（404 要拦、429/400 不能拦、不影响别的昵称） 5) 测试连通 - /api/notify/test 合并成一个接口，用 channel 区分 qq / meow，每个渠道的配置下面各有一个「测试连通」按钮 - 用页面上当前填的值直接测、不用先保存，留空的项自动用已保存的值补齐；测试不受渠道开关和事件勾选影响（本来就是为了打开之前先确认配置） - 成功返回 {ok, detail}，detail 就是页面上的结论：QQ 渠道显示 webhook 的 HTTP 状态码和耗时，MeoW 渠道显示它返回的 status 和耗时； webhook 返回 200 只代表地址口令没问题，能不能收到要看机器人那边，这点也写在结果里 - /api/status 新增 meowBlocked，页面上红字显示「当前推不出去：…」（昵称没填、格式不对、或已被判过未注册） 6) 页面 - 通知区分成「事件勾选 / 渠道一 QQ 机器人 / 渠道二 MeoW」三块，每块用一条带标题的细线隔开，两个渠道各带开关和测试按钮 - 消息类型选 text 时自动收起 HTML 高度那一行另外：README 的通知推送一节重写（两个渠道的对比表、MeoW 的频控与封禁提醒、测试连通的说明），配置文件详解补上新字段；doc/webapi.md 补 /api/notify/test 和 meowBlocked。doc/momoko-acfunlive-notify.py 本来就处理 event="test"，不用改。已验证：新增 notify_test.go，15 个用例全部通过（URL 拼接与转义、昵称校验、消息类型与高度归一、HTML 渲染与转义、接口成功/失败/空字段处理、6 种业务状态码的文案、404 拦截保护、老配置兼容、测试接口各分支），其中 TestSendNotifyFanOut 是端到端分发测试：两个渠道都开→各收到 1 条、关掉任一个→只剩另一个、两个都关→0 条、事件没勾→0 条。真机冒烟两轮：页面控件齐全、老配置默认开启、 QQ 渠道实测本地 webhook 收到完整推送（含 Authorization 和 X-Auth-Token 头与群号）、空值回退到已保存配置、6 种非法输入全 400、开关能落盘且关开关不清地址、 MeoW 真实接口返回的 404 被正确翻成中文。全量 34 个测试通过， Windows/Linux 双平台构建、go vet、gofmt 全干净。	2026-09-25 13:42:49 +08:00

Author

SHA1

Message

Date

tamakyi

6f3c8096b4

修分块渲染的弹幕轨迹：跨块续画 + 文字头像同源，并补失败推送与输出帧率设置

1. 密集弹幕时头像偏离轨迹、弹幕突然加速、之后一段时间屏幕空白

   分块渲染的固有问题，三个毛病叠在一起：

   - writeChunkAss 把 \move 的起止时间截断到块边界（End=min(t0+10, chunk.end)），
     但 x2 写死成 -Width —— 等于把 10 秒的路挤进可见的那零点几秒里，文字直接飞过去。
     而头像 overlay 的 x 一直是「固定 /10 秒 + 真实 t0」，于是同一时刻文字已经走到
     左边、头像还在半路，看起来就是「头像掉队（移动变慢）」。
   - 块尾还会被单块上限收紧成「下一条弹幕出现的时间」，最极端时窗口只剩 0.01 秒。
   - 每块只画「本块新出现」的弹幕，跨块的续画没有：块头屏幕上只剩刚出现的几条，
     要 10 秒才重新填满 —— 就是「弹幕突然加速，然后一段时间屏幕上什么都没有」。

   改法：文字层改成按绝对时间算轨迹（danmuTextX / danmuAvatarX / avatarXExpr 同源），
   任何一块里的文字速度都等于真实速度；分块器改成「续画（起播时间在 start-10 ~ start）
   + 本块新出现的」，块尾取「下一条弹幕的起播时间」，这样每条弹幕只在唯一一块里算
   新出现，显示期间跨过的后面几块把它接着画，一帧都不缺。

   代价是每块要多画一倍多的弹幕，所以顺手把头像一个「绝对路径 + 每人一行 scale」改成
   「预缩放 + 短相对路径」（prepareAvatarInputs / scaleAvatarFile），每条从实测 241
   字符降到约 130，单块上限才能从 120 抬到 200（200 条 ≈ 26600，仍低于自检阈值 30000
   和 Windows 的 32767）。

2. 合并失败没有任何通知

   notify.go 新增 mergeFail 事件与 notifyMergeFailure()，接在 autoMerge() 和手动合并的
   失败分支上。正常结束、文件里没有弹幕、以及用户自己点的停止都不算失败，不推 ——
   最后一种推「合并失败」会误导。配置项 notifyMergeFail 默认开，且和 notifyEnabled 一样
   在 Unmarshal 之前预置 true，免得老设置文件升级后被静默关掉。

3. 低帧率录播里的弹幕一格一格跳

   新增设置项 mergeFps，默认 0 = 跟随源片（什么都不做）。只在目标高于源片帧率时才加
   fps 滤镜，而且必须加在字幕/头像之前 —— 加在之后只是把已经画好的几帧复制一遍，
   看起来还是卡。上限 240。

4. 顺带

   - -danmuburn 命令行模式不走 initialize()，exeDir 从来没被赋值：头像缓存会落到
     「当前工作目录/avatar_cache」，旧版还会把这个相对路径写进滤镜，而 ffmpeg 的工作
     目录是弹幕目录，报「打不开 avatar_cache\xxx.png」整块失败。
   - cleanTempFiles 见到目录就 continue，预缩放头像那个临时文件夹永远清不掉。
   - command_len_test 不再用会过期的「每条 241 字符」估算，改成真跑一遍最坏情况；
     探针的头像路径也改成真实的短相对路径（原来量的是早已不存在的长绝对路径）。
   - 新增 TestWebuiSettingFieldsMatchInputs：把页面里 JS 的 settingFields/numberFields
     抠出来，跟所有 input/select/textarea 的 id 比对，漏登记的设置项会被抓住。

验证

- gofmt / go vet / go test（174 个）/ go test -race / staticcheck / GOOS=linux go build 全过。
- 反向验证 32 项全过：把每个修复临时退回，对应测试确实失败。
- 真实片段实测（2023AcFun 晚会 120 秒高峰段，689 条弹幕，10 秒窗口内最多同时 140 条）：
  旧 6 块 / 绘制 689 次 / 54.1% 的弹幕文字被加速（中位 2.12x，最差 500x）/
  54.2% 有轨迹缺口（中位缺 5.29 秒）/ 78.3s；
  新 5 块 / 绘制 984 次 / 加速 0% / 缺口 0% / 98.8s（+26%）。
  对照帧里旧版在块尾前 0.1 秒屏幕已经全空，块头后 0.4 秒仍然全空；新版一直是满屏。
- 输出帧率：15fps 源配 mergeFps=60，成片 60fps，1 秒内 60 帧哈希互不相同（不是复制帧）；
  默认设置下成片仍是 15fps。

2026-09-26 16:34:47 +08:00

tamakyi

be8ec5f953

通知推送拆成两个渠道：QQ 机器人和 MeoW，各自带开关和测试连通

用户要求两件事：① QQ bot 推送要能测连通、并加一个开关；② 照 MeoW 的接口
文档（https://www.chuckfang.com/MeoW/api_doc.html）加一个推送渠道，同样要有
测试和开关。确认过的三个决定：QQ bot 就是现有 webhook；事件勾选两个渠道
共用、开关按渠道分开；MeoW 只填一个昵称。

1) 通知推送改成「共享事件勾选 + 每渠道一个开关」
   - notify.go: notifySetting 扩成两个渠道，新增 qqReady()/meowReady()；
     sendNotify 按渠道各自起后台 goroutine 分发，事件没勾选、或两个渠道都
     没启用时什么都不做
   - config.go: 新增 notifyEnabled（QQ 机器人渠道开关）、meowEnabled、
     meowNickname、meowMsgType、meowHtmlHeight、meowImgUrl
   - 关掉开关只是暂停推送，地址、昵称这些配置都留着，随时能再打开

2) 老配置的兼容（重要）
   - notifyEnabled 是普通 bool，老 config.json 里没有这个字段会解成 false，
     升级后会把已经配好的推送静默关掉
   - 解法：loadConfig() 里先置 true 再 json.Unmarshal（Unmarshal 只覆盖文件里
     出现的字段），默认值里也写 true；文件里显式写 false 的仍然会关掉
   - 已加回归测试 TestNotifyEnabledBackwardCompat 覆盖三种写法

3) MeoW 渠道（新增 meow.go）
   - 按文档走 POST {昵称}，title/msg/url/imgUrl 放 json body，
     msgType/htmlHeight 是 query 参数（文档明确说这两个不属于 JSON 参数）
   - 文档自己前后矛盾：响应格式那节写 msg，示例写 message，两个字段都解析
   - 空字段一律不放进 body：body 里的 title 优先级高于路径参数，
     传空串会把 MeoW 的默认标题顶掉
   - 业务状态码翻成中文（400 参数错、403 内容被拦、404 昵称未注册、
     429 频控、500 服务器错误），失败信息直接显示在页面上
   - msgType 为 html 时渲染成 HTML（首行加粗、链接可点、内容转义），
     高度默认 200、范围 40-2000；事件正文复用 webhook 的那份 text

4) MeoW 的错误昵称会封 IP，所以加了保护（踩出来的）
   - 实测用不存在的昵称打真实接口，返回的提示是「一天之内累计3次输错对方
     昵称您的IP将被封禁」。而开播+开始录制+下播+合并完成一天轻松触发 4 次，
     昵称配错就会把用户 IP 封了
   - meow.go: 新增 meowBadNick 记录，pushMeow 收到 404 就记下这个昵称；
     sendNotify 和测试接口命中记录时直接跳过/拒绝并说明原因，
     改掉昵称或重启程序即恢复
   - 只有 404 触发拦截：429 是频控、400 是参数问题，都应该继续尝试
   - 已加测试 TestMeowBadNickGuard（404 要拦、429/400 不能拦、不影响别的昵称）

5) 测试连通
   - /api/notify/test 合并成一个接口，用 channel 区分 qq / meow，
     每个渠道的配置下面各有一个「测试连通」按钮
   - 用页面上当前填的值直接测、不用先保存，留空的项自动用已保存的值补齐；
     测试不受渠道开关和事件勾选影响（本来就是为了打开之前先确认配置）
   - 成功返回 {ok, detail}，detail 就是页面上的结论：QQ 渠道显示 webhook 的
     HTTP 状态码和耗时，MeoW 渠道显示它返回的 status 和耗时；
     webhook 返回 200 只代表地址口令没问题，能不能收到要看机器人那边，
     这点也写在结果里
   - /api/status 新增 meowBlocked，页面上红字显示「当前推不出去：…」
     （昵称没填、格式不对、或已被判过未注册）

6) 页面
   - 通知区分成「事件勾选 / 渠道一 QQ 机器人 / 渠道二 MeoW」三块，
     每块用一条带标题的细线隔开，两个渠道各带开关和测试按钮
   - 消息类型选 text 时自动收起 HTML 高度那一行

另外：README 的通知推送一节重写（两个渠道的对比表、MeoW 的频控与封禁提醒、
测试连通的说明），配置文件详解补上新字段；doc/webapi.md 补 /api/notify/test
和 meowBlocked。doc/momoko-acfunlive-notify.py 本来就处理 event="test"，不用改。

已验证：新增 notify_test.go，15 个用例全部通过（URL 拼接与转义、昵称校验、
消息类型与高度归一、HTML 渲染与转义、接口成功/失败/空字段处理、6 种业务状态码
的文案、404 拦截保护、老配置兼容、测试接口各分支），其中 TestSendNotifyFanOut
是端到端分发测试：两个渠道都开→各收到 1 条、关掉任一个→只剩另一个、
两个都关→0 条、事件没勾→0 条。真机冒烟两轮：页面控件齐全、老配置默认开启、
QQ 渠道实测本地 webhook 收到完整推送（含 Authorization 和 X-Auth-Token 头与群号）、
空值回退到已保存配置、6 种非法输入全 400、开关能落盘且关开关不清地址、
MeoW 真实接口返回的 404 被正确翻成中文。全量 34 个测试通过，
Windows/Linux 双平台构建、go vet、gofmt 全干净。

2026-09-25 13:42:49 +08:00