2026-05-21-15-50-21 记录系统使用视频配音生成

工程分析/经验记录.md

@@ -1567,3 +1567,21 @@ C. 解决问题方案
 D. 后续如何避免问题
 
 后续同一版本存在多个部署形态、系统架构或环境模板时，优先使用“一个 Release + 多个命名附件”的发布模型；只有当版本号、功能内容或源码状态确实不同，才拆成多个 Release。删除旧 Release 前必须先确认新 Release 的附件数量、名称和大小均已从 Gitea API 读回，避免页面清理造成发布物短暂缺失。
+
+## 2026-05-21-15-50-21 视频配音应以视频流时长对齐而非容器时长
+
+A. 具体问题
+
+用户要求为 5 分钟版和 10 分钟版系统使用视频生成配音版，并明确不能出现视频结束后仍有声音，或声音结束后视频继续播放。原始 MP4 的容器时长与视频流时长存在约 0.1 秒差异，如果直接按容器时长对齐音频，末尾可能出现极短的音频尾巴。
+
+B. 产生问题原因
+
+MP4 容器时长通常取所有流的最大持续时间，原始录屏中音频流和容器时长略长于视频流。配音合成时如果只读取 `format=duration`，会把旁白音轨拉到容器时长；播放器显示上虽然总时长一致，但最后一帧之后仍可能存在很短音频区间，不符合“视频结束不要还有声音”的交付要求。
+
+C. 解决问题方案
+
+先用 `ffprobe` 分别读取视频流时长、容器时长和音频时长，再以 `v:0` 视频流时长作为最终目标。TTS 原始音频与目标时长差距较小时，使用 `ffmpeg atempo` 做小幅伸缩，并用 `apad + atrim` 精确裁定到视频流时长。最终合成时只映射原视频流和新配音音轨，去除原始音轨，并再次用 `ffprobe` 验证视频流和音频流时长完全一致。
+
+D. 后续如何避免问题
+
+后续生成配音、字幕或二次包装视频时，不能只看 MP4 容器总时长；必须同时检查视频流和音频流时长。若目标是避免片尾空声，应以视频流时长为准；若目标是保留完整旁白，则需要明确允许画面补帧或拉伸。大幅时长差不要依赖静音填充，应优先调整文案长度和 TTS 语速，再做细微 `atempo` 对齐。