master
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 报错（分组 / 拆组 / 逐任务参数 / 转码行渲染 /
跳过无视频轨文件 / 估算失败提示 / 结果徽标）
|
||
|
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。
|
||
|
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 干净。 |
||
|
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 全干净。 |