Tobatsu · 视频二次编辑
现状 · 我们的疑问 · 能不能做 · 怎么做 —— 一份给产品 / 前端 / 后端对齐的总结。
能做,而且两个重渲引擎都已经在线上(不用新建)。 出片时把"重渲所需的原材料"全挂在最终成片这一个结果下面,成片卡就成了一个自包含的"可重编辑工程";用户选中它,前端就能拉出全部输入做预览和重新生成。
发配置,不发 ASS。断句用 line-groups。字号 / 行数一律以后端为准。
| 产物 | 是什么 | 对重渲的作用 |
|---|---|---|
out_primary | 最终带字幕成片 | 工程入口(卡片) |
out_pip_composite | 无字幕合成视频(主视频+数字人,已混音) | 字幕重烧的底片 = noSubtitleVideoURL |
out_subtitle | SRT 字幕文件 | = srtURL |
out_digital_human | 数字人口播原片(开抠像就是透明 webm) | 画中画重合成的 pip 路 —— 已经返回了 |
out_audio | 口播音频 | — |
out_anchor | 锚图 | — |
out_primary 现在已经用一个透传袋(canvas_extra)把 srtURL / noSubtitleVideoURL 挂在自己下面 —— "原材料挂成片下面"这个机制已经有雏形了,只是材料还没挂全。
main_video_url + pip_video_url + 布局参数(layout / 浮窗位置大小形状 / 分屏比例 / 取景 / 音量 / 抠像 / 描边),给两路视频就能重新合成。Q1发 ASS 还是发配置? → 发配置。ASS 是渲染产物,前端没法编辑;配置(line-groups + 几个样式字段)是干净 JSON,改起来轻松,还能保留预设和智能定位。
Q2断句(拆句/合并)怎么做,会不会很难? → 最简单的部分。断句就是改 line-groups 里的 page_index / word_indices 分组;每屏时间 = 该屏所有词的 min(start)~max(end),前端一行不用算时间。
Q3字号 / 最大行数怎么对齐? → 一律以后端为准。字号是真实渲染像素(不是预览 px),后端给基线、前端按比例缩;最大行数后端定(默认同屏 ≤2 行,超出走滚动)。前端预览必须读后端返回的规格,不自己猜。
Q4"重做"是拿哪个视频做输入? → 这个框架本身要纠正:不能拿"已烧字幕的成片"去重做画中画(字幕烧死了会带进新合成)。正确是按流水线分层,改哪层就从哪层往下重跑(见第 4 节)。
Q5pip 和 burn 拆成两个独立下游,组合场景是不是就不好做? → 不会。引擎拆开是对的;组合场景别让前端去拼两步,用一个后端重渲任务把 compose→burn 串起来、按需只跑需要的那段(见第 4 节)。
| 能力 | 引擎 | combo 是否已返回重渲输入 | 要补 |
|---|---|---|---|
| 字幕重编辑 | subtitle_burn_in ✅ | 无字幕底片 ✅ / line-groups ❌ | ① 把 line-groups 挂到成片下 ② subtitle_burn_in 开结构化入口 |
| 画中画重编辑 | video_pip_compose_mai ✅ | 数字人 ✅ / 主视频≈原始输入 / 合成参数 ❌ | 把"合成参数快照"挂到成片下(数字人已有,引擎现成) |
两侧缺口都不大。字幕侧最轻(就差 line-groups 返回 + 一个结构化入口);画中画侧因为数字人本来就返回了,现在主要差一份"这次用了哪些 PIP 参数"的快照,好让前端恢复状态。
你说得对:把重渲要的东西都挂在 out_primary 下面,选中成片就能重编辑。扩展现有的 canvas_extra 透传袋即可:
绿色 = 现在已经返回 / 已挂;红色 = 要补挂的。补齐后,成片卡自带全部重渲输入。
引擎拆开(可复用),但面向"统一编辑器"的提交,落到一个后端重渲任务:PIP 变了就 compose、字幕总要 burn、只改字幕就跳过 compose。"改 PIP 必带重烧"这个硬依赖在后端内部处理,前端只交一次配置。combo 的 runner 本来就有 compose + burn 两段,复用现成代码。
字号 / 行数归后端后,前端预览必须用后端返回的规格去画,不能自己猜:每种画幅的真实字号基线、按视频尺寸算好的安全边距 + ≤2 行换行结果、四个预设的视觉定义、位置锚点公式、PIP 几何。这样"预览 == 重生成结果"才成立。