 tamakyi
|
eda83dd1e3
|
主播列表的码率改为直播实际档位下拉，没选过时默认第二档
原来是一个手填的码率上限（Kbps），现在改成直播的实际档位（蓝光 8M / 高清…）：
- 读到档位后，主播那一行渲染成下拉，选完立即生效；正在录制时换档会自动重录。
- 没手动选过（bitrate 0）的主播按**自上往下第二档**定下来（如
蓝光 8M / 蓝光 4M / 高清 就选蓝光 4M，只有一档就用那一档），不会一上来就吃满
最高档；已经手动选过的永远不动。
- 档位要开播后读直播源列表才知道，读到以后（录制开始时、或页面点「档位」按钮）
缓存进 config.json 的 qualities，所以没开播也能看和改；启动时会把「有缓存但还
没定过码率」的主播按第二档补齐。
- 从来没读过档位的行仍然是手填输入框，旁边多了个「档位」按钮去直播间接一次。
后端：新增 `GET /api/streamer/qualities?uid=…`（同一主播 10 秒内只读一次），
`/api/status` 的每个主播多了 `qualities`（按码率从高到低）和 `qualityName`；
抽出 `newStreamInfo()`/`fetchStreamQualities()`，`getStreamURL()` 取流时顺手缓存
档位，并在 bitrate 为 0 时改用刚定下来的默认档位（否则还是最高档）。
档位相关的纯逻辑放在 config.go：`sortQualitiesDesc` / `defaultQualityBitrate` /
`qualityNameFor` / `sameQualities` / `setStreamerQualities` / `applyCachedDefaultQualities`。
测试：qualities_test.go 7 个用例（排序、默认第二档的 5 种档位数、档位名匹配、
写配置时不覆盖手动选择、启动补齐、JSON 存取往返）；浏览器实测 5 组断言全过
（下拉选中当前档位、换档服务端立即变、无档位时保留输入框+按钮、启动默认第二档、
手填仍可用），verify_streamer_br.py / verify_pick.py / verify_settings.py 无回归；
go test ./...、gofmt、go vet 干净。
|
2026-09-25 19:42:47 +08:00 |
|
|
tamakyi
|
a891094f29
|
合并默认改用 HEVC、码率按「源片 + 500」自动算；手动合并自动匹配同名弹幕
两件事：
1) 合成码率与编码器
- `mergeBitrate` 填 0（默认）时不再是 ICQ 质量模式，改成「源片视频码率 + 500 Kbps」：
烧进去的文字和头像都是高频细节，和源片同码率会糊，所以留一点余量；探测不到源片
码率时才退回质量模式（QSV 用 ICQ 22、软编用 CRF 18），下限 800 Kbps。
- 编码器默认换成硬件 HEVC：候选顺序 hevc_qsv → h264_qsv → libx264，QSV 可用性按
编码器分别探测（原来只探 h264_qsv）。HEVC 在 mp4 里打 `hvc1` tag，Apple 系
（QuickTime / Safari / iPhone）才认 —— ffmpeg 默认写的是 hev1。
- 日志现在会打印编码器优先顺序和实际用的码率。
实测（90 秒真实素材，源片 3217 kbps，密集弹幕）：日志「按源片 3217 kbps + 弹幕
余量 500 kbps 取 3717 kbps」，成片 codec=hevc、tag=hvc1、实际 3.71 Mbps。
之前同样是这份素材：h264 + ICQ22 会飙到 7386 kbps（79 MB），改成自动码率后
43.7 MB，体积小了 45% 画质还更稳。
2) 手动合并自动匹配弹幕
- 新增 `GET /api/merge/danmu?video=…`：按视频名找同目录下的同名弹幕，依次试
`.jsonl`、`.ass`、`.nick.ass`；同目录没有就拿文件名去录播目录再找一次。
- 页面在「手填/粘贴视频后失焦」「多选弹窗选完」「从文件列表多选后」「点预览或
开始合并时弹幕框还空着」这几种情况下都会自动匹配并提示；弹幕框里已经有内容时
绝不动它，找不到也保持为空让用户自己选。
- 填回框里的写法与浏览弹窗一致：录播/成片目录下的只写文件名，别处的写绝对路径。
测试：新增 encode_test.go（编码器顺序、参数与 hvc1、自动码率、ffmpeg 输出解析）
和 TestFindDanmuForVideo（7 个子用例：优先级、录播目录回退、绝对路径、找不到返回空）；
仓库外的 verify_danmu_match.py 4 组断言全过，verify_pick.py / verify_settings.py 重跑
无回归；go test ./...、gofmt、go vet 干净。
|
2026-09-25 19:23:44 +08:00 |
|
|
tamakyi
|
e8b455dfe8
|
合并时把弹幕坐标系统一到视频分辨率；修「改设置会删掉正在合并的临时文件」
用户手动合并一场竖屏录播（视频 720x1280，弹幕文件 960x540、字号 30）时发现：
字号改大以后文字变大了，但头像还是小小的，而且越往下的弹幕头像和文字错得越远。
原因：弹幕文件里的 PlayResX/PlayResY 是录制当时的画面尺寸，和现在的视频对不上时，
libass 会按「视频高 ÷ PlayResY」缩放文字和它的坐标（这里 1280/540 ≈ 2.37），
而头像叠加用的是视频像素坐标（头像直径 = 字号×4/5、行位置 = 字号×弹道号），
两者不在同一个坐标系里。实测同一帧（720x1280 竖屏）：
修复前：文字墨迹高 54px、头像直径 24px，第 4 行文字在 y=226 而它的头像在 y=92
修复后：文字墨迹高 54px、头像直径 56px，头像与对应文字行一一对齐
做法是合并前探测视频分辨率，不一致就把 PlayRes 改成视频宽高：跟随弹幕文件时字号
按高度比换算（占画面的比例不变），用户填了 danmuFontSize 就按成片像素直接用 ——
因为用户看到的本来就是成片上的像素。只在有视频时做，透明头像层模式不变；
探测不到分辨率就保持原样。坐标系一致时（1920x1080 配 1920x1080）完全不改动，
所以正常录播的合并结果和以前一样。验证方式是拿一份「原生就对」的弹幕文件做对照，
自动统一后的成片与它在文字行位置、头像直径和位置上逐项相同。
顺带修一个真 bug（上一轮引入）：checkConfig() 里清了合成临时文件，而改设置会重新
读取配置并调用 checkConfig()，于是合并途中改任何设置都会把正在用的分块字幕/临时
成片删掉，合并当场失败（日志：清理上次留下的临时文件 acfunlive_chunk_single.ass
→ Unable to open ...）。清理挪到只在启动时执行的 cleanLeftoverTempFiles()。
新增 config_test.go（改设置不能删掉在用的临时文件，反向验证过：把清理塞回
checkConfig 会让它失败）和 unifyDanmuSpace / 分辨率解析的用例。
|
2026-09-25 19:03:21 +08:00 |
|
|
tamakyi
|
ed4e47e305
|
init
|
2026-09-25 13:16:54 +08:00 |
|