技术文章转换成口播视频，表面上是“输入一段文字，输出一段视频”，实际上包含几条不同的技术链：文字怎样读出来，人物怎样跟随声音说话，字幕怎样对齐，画面怎样组合。如果一开始就把它们全部接起来，出现问题时很难判断是声音、口型还是后期合成造成的。
我的研究方向先收窄到两个问题：能否得到稳定的中文声音，以及能否用照片或视频得到可用的口播人物。文章整理、分镜和竖屏布局放在后面。这篇记录选型过程与验证方法；目前没有一组统一条件下的对比样片，因此结论属于技术路线判断。
一、先将目标拆成可以分别验证的模块
目标画布是竖屏，中间承载横屏技术内容，上方放标题，下方或留白区域放口播人物。人物素材可能是一张照片，也可能是一段本人视频；声音希望具有固定音色，并正确朗读中文、型号、单位和英文缩写。
这几个条件决定了模块分工。TTS 将已确认文字变成音频；数字人模型使用音频驱动人物；字幕模块从最终音频取得时间位置；合成模块负责缩放、布局、标题与编码。文字生成模型可以组织讲解，但它预测的每句时长只能用于规划，不能替代真实音频的时码。
先验证声音有一个实际好处：数字人候选可以使用完全相同的音频。若两个样片的声音、停顿、长度都不同，观感差异很难归因到人物模型。同样，人物素材也应保持固定，避免用不同清晰度、姿态或光线的素材比较模型。
二、人物路线：已有视频与单张照片解决的问题不同
1. MuseTalk：保留源画面，重点处理口型
MuseTalk 的路线是在音频条件下处理面部局部区域，再融合到已有画面。源视频可以提供头部运动、姿态和背景，模型主要承担嘴部跟随声音的任务。这适合先准备一段清晰、姿态自然的素材，再用于不同讲解稿。
输入质量会直接影响结果。原素材若存在严重侧脸、遮挡、快速运动或模糊，局部口型修改不保证修复这些问题。脸部裁剪范围也影响嘴、下巴与融合边缘，不能仅靠提高输出分辨率解决。
预处理和人物准备可能复用，适合重复生成的流程，但缓存必须绑定对应人物素材与处理版本。更换素材后继续使用旧区域信息，可能导致局部位置错误。验证时同时看闭口、爆破音、连续静音和轻微转头，单张截图不能反映时序质量。
2. EchoMimicV3-Flash：照片还需要生成连续运动
只有照片时，系统除了口型，还需要补出时序画面中的运动与表情。EchoMimicV3-Flash 属于这一候选路线，与已有视频口型不能只按“哪个嘴更清楚”比较。身份稳定、自然运动、面部边缘、背景与分段连续性都需要观察。
项目给出的显存需求和演示说明可以帮助确定试验范围，但它们对应特定实现和条件。本机能否完整运行，还要核对精度、注意力算子、分辨率、帧数和峰值。减小输入可能降低资源需求，也可能改变质量，二者需要成对记录。
| 路线 | 可以复用的条件 | 重点验证 | 适合先做的试验 |
|---|---|---|---|
| 已有视频口型 | 原姿态与背景、人物预处理 | 嘴部连续、裁剪融合、同步 | 固定素材与短音频 |
| 单照片动画 | 人物参考照片 | 身份、运动、边缘、长片漂移 | 固定照片与同一短音频 |
因此，素材选择比简单罗列模型更靠前。能够录制合适视频时，优先把视频口型路线跑通；必须从照片开始时，单独评估照片动画的运动质量。这是测试顺序，并不是预先认定某个项目胜出。
三、声音路线：CosyVoice 与 GPT-SoVITS
声音侧先比较 CosyVoice 与 GPT-SoVITS。它们各自提供的参考音频、零样本或训练方式，以具体版本说明为准。研究时不把“能克隆音色”直接理解为每种技术稿都读得准确。
我将声音质量分成四项：文字有没有读错，音色是否一致，停顿和重音是否自然，长段是否稳定。一个短句非常像原声音，仍可能把数字、型号或中英文缩写读错；一个长段没有明显中断，也可能出现句尾拖长或停顿不合逻辑。
参考素材应来自获授权的录音，尽量减少混响、背景音乐和忽高忽低的音量。对比时使用同一段参考、同一稿件与同一采样约定，保留实际生成的完整音频。不要为每个候选分别挑选最好的示例，这样无法复核。
可使用以下测试结构，不涉及私人声音样本：
1
2
3
4
短稿：中文普通句 + 数字 + 单位 + 英文缩写
长稿：多段技术说明 + 标点停顿 + 段落衔接
记录：文本错误、音色、韵律、音频长度、生成耗时、资源峰值
复测：相同稿件再次生成，观察结果是否稳定
先把发音错误处理好，再将音频交给人物模型。人物口型再自然，也不能纠正配音里已经读错的数字。
四、资源验证：双卡总容量不是单请求可用容量
如果使用两张 V100，不能直接把两个显存数相加，当成任何一个项目都可以使用的连续空间。框架必须实际支持对应的分配或分片，且某些组件可能仍集中在一张卡上。
V100 的计算能力为 7.0，项目若依赖其它架构才支持的精度或注意力内核，需要先确认替代路径。安装成功和主权重加载成功都没有覆盖全部运行条件；真正的峰值可能出现在音频编码、视频生成、解码或首次准备阶段。
资源记录可以从每卡状态开始：
1
nvidia-smi --query-gpu=index,name,memory.total,memory.used,memory.free --format=csv
这只是状态查询。峰值还需在生成过程中持续观察，记录使用的项目版本、输入尺寸、音频长度与处理阶段。先做约15秒短片，再扩展到约90秒口播，这里的时长是试验条件，不是已经达到的性能结果。
逐步扩大试验能回答三个问题：基础输入能否跑通，长片是否产生漂移或资源问题，重复生成是否稳定。若短片都没有通过，就先定位依赖与素材，暂不接入整套自动发布流程。
五、时间轴和合成在最终音频之后
声音确认后，字幕模块根据最终音频定位词句，保存文字与起止时间。预估字幕可以用于脚本规划，最终时码不能只按字数平均分配。数字、英文与停顿容易造成识别或对齐误差，需要抽查。
横屏内容放进竖屏画布时，先计算可用区域，再等比缩放。标题、人物与字幕各自留空间，避免人物遮住图表，或字幕与平台界面重叠。合成统一帧率和音频采样约定，输出后从手机尺寸检查读字与音画同步。
1
2
3
4
已确认稿件 → TTS音频 → 发音检查 → 锁定音频
同一音频 → 视频口型 / 照片动画 → 人物检查
最终音频 → 时间对齐 → 字幕
横屏内容 + 人物 + 字幕 + 标题 → 竖屏合成
若后来修改配音，时间轴与人物结果可能都需要重做，因此应先确定音频版本。每个生成产物关联素材与配置，能减少后期拿错版本的问题。
六、这轮研究的结论
目前可以确定的是模块顺序：先独立验证声音与人物，用同一音频比较人物路线，再接字幕时间轴和竖屏合成。人物选型由可提供的素材决定，声音选型由实际稿件读音和长段稳定性决定。
MuseTalk 1.5 与 EchoMimicV3-Flash 可以进入不同素材路线的候选，CosyVoice 与 GPT-SoVITS 可以进入中文声音对照。官方演示和技术说明支持它们值得测试，不能证明本机效果、长片吞吐或最终成片质量。
下一步的有效证据是一组统一素材、统一音频和完整资源记录的样片。没有这些证据之前，结论保持在候选范围与测试优先级，不将选型研究写成已经完成的系统交付。
参考资料
- MuseTalk 项目：实现、模型与版本说明
- EchoMimicV3 项目：照片动画与 Flash 版本
- CosyVoice 项目：中文语音生成与参考条件
- GPT-SoVITS 项目：声音训练与推理说明
