tamakyi/acfunlive-remake
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
32 Commits 1 Branch 0 Tags
3c17503a21357eadd91a82f3b5f270f87997a2f5
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 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 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 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