176 lines
4.3 KiB
Markdown
176 lines
4.3 KiB
Markdown
我现在已经跑通了a2f，能够将音频转化成csv格式文件，我想让你帮我实现一个项目：用py写实现两个函数，文字转音频文件/音
|
||
频文件转csv文件/csv文件转52个形态键/ 最后在暴露出一个文字输入的接口，输出52个形态键的数据
|
||
python_services项目你可以作为参考，# Babylon.js + A2F 低延迟实时嘴型方案设计文档
|
||
|
||
## 1. 文档目的
|
||
|
||
本文档用于指导在 **Babylon.js（Web）** 环境下，基于 **Audio2Face（A2F）** 实现“尽可能低延迟”的数字人嘴型驱动方案。目标并非严格意义上的零延迟实时，而是在 Web 约束下实现 **准实时（400–600ms 首帧延迟）** 且稳定可上线的工程方案。
|
||
|
||
---
|
||
|
||
## 2. 设计约束与前提
|
||
|
||
### 2.1 技术约束
|
||
|
||
* A2F 本身为 **非严格流式模型**，需要一定音频前瞻（lookahead）
|
||
* Babylon.js MorphTarget 为 **CPU 驱动 + GPU 顶点更新**，性能敏感
|
||
|
||
|
||
|
||
## 3. 总体方案概述
|
||
|
||
### 3.1 核心思想
|
||
|
||
* **文本按句拆分**，缩短首帧等待时间
|
||
* **句级流水线处理**，而非整段阻塞
|
||
* **音频与嘴型数据流式推送**
|
||
* 前端仅负责 **插值播放**，不做重计算
|
||
|
||
### 3.2 总体架构
|
||
|
||
```
|
||
文本输入
|
||
↓
|
||
句子拆分（强停顿标点）
|
||
↓
|
||
句子队列（Pipeline）
|
||
↓
|
||
┌──────────────┐
|
||
│ 流式 TTS │
|
||
└──────────────┘
|
||
↓ PCM chunk
|
||
┌──────────────┐
|
||
│ A2F（句级） │
|
||
└──────────────┘
|
||
↓ BlendShape Frames
|
||
┌──────────────┐
|
||
│ 二进制传输 │
|
||
└──────────────┘
|
||
↓
|
||
Babylon.js 插值播放
|
||
```
|
||
|
||
---
|
||
|
||
## 4. 文本拆句策略
|
||
|
||
### 4.1 拆分规则
|
||
|
||
* 仅按 **强停顿标点** 拆分：
|
||
|
||
* `。` `！` `？` `；`
|
||
|
||
|
||
|
||
### 4.3 句尾处理
|
||
|
||
* 每句音频结尾 **补 150–300ms 静音**
|
||
* 用于嘴型自然回到 neutral
|
||
|
||
---
|
||
|
||
## 5. 后端处理流程
|
||
|
||
### 5.1 流水线调度
|
||
|
||
* 同时最多处理 **2–3 句**
|
||
* 始终保证：
|
||
|
||
* 当前句播放中
|
||
* 下一句已 ready
|
||
|
||
### 5.2 TTS 要求
|
||
|
||
* 必须支持 **流式 / chunk 输出**
|
||
* chunk 大小建议：100–200ms PCM
|
||
|
||
### 5.3 A2F 调用策略
|
||
|
||
* 不等待整段文本
|
||
* 以 **句为最小单元**调用
|
||
|
||
---
|
||
|
||
## 6. 数据格式设计（替代 CSV）
|
||
|
||
### 6.1 为什么不用 CSV
|
||
|
||
* 文本解析慢
|
||
* 数据冗余大
|
||
* 不支持流式 append
|
||
|
||
### 6.2 推荐二进制结构
|
||
|
||
```
|
||
Frame {
|
||
uint16 timestamp_ms;
|
||
uint8 shape_count;
|
||
uint8 shape_indices[shape_count];
|
||
int8 shape_values[shape_count]; // -127 ~ 127
|
||
}
|
||
```
|
||
|
||
### 6.3 优点
|
||
|
||
* 数据量减少 60–80%
|
||
* WebSocket 直传
|
||
* JS 解析成本极低
|
||
|
||
---
|
||
|
||
## 7. 前端（Babylon.js）播放方案
|
||
|
||
### 7.1 核心原则
|
||
|
||
* **不用 onBeforeRender 逐帧 setInfluence**
|
||
* 使用 **Animation / AnimationGroup**
|
||
* 前端只负责：
|
||
|
||
* buffer
|
||
* 时间对齐
|
||
* 插值
|
||
|
||
### 7.2 帧率与形态键
|
||
|
||
| 项目 | 建议 |
|
||
| ------------ | --------- |
|
||
| 嘴型帧率 | 15–20 fps |
|
||
| 形态键 | 20–30 个 |
|
||
| Morph Normal | 关闭 |
|
||
|
||
### 7.3 句间过渡
|
||
|
||
* 句尾：morph → neutral（100ms lerp）
|
||
* 句首：neutral → first frame（100ms fade in）
|
||
|
||
---
|
||
|
||
## 8. 延迟评估
|
||
|
||
| 环节 | 典型延迟 |
|
||
| --------- | ---------- |
|
||
| 流式 TTS | 100–200 ms |
|
||
| A2F 计算 | 200–300 ms |
|
||
| 网络 | 20–50 ms |
|
||
| 前端 buffer | ~100 ms |
|
||
|
||
**总首帧延迟：≈ 400–600 ms**
|
||
|
||
---
|
||
|
||
## 9. 风险与边界
|
||
|
||
* A2F 不适合 <200ms 的强实时场景
|
||
* 高并发时需限流（TTS / A2F GPU）
|
||
* 超长文本必须强制拆句
|
||
|
||
---
|
||
|
||
## 10. 结论
|
||
|
||
* **拆句 + 流水线** 是 Web + A2F 的最优解
|
||
* CSV 必须淘汰，二进制流是必选项
|
||
* 在 Babylon.js 中可实现稳定、可上线的准实时数字人嘴型系统
|
||
|
||
---
|
||
正常流式传输逻辑是后端将文字拆分成句，每个句调用TTS生成音频，再调用A2F生成blendshape数据，最后将blendshape数据发送给前端。要有并发处理能力，能够同时处理多句。优先将当前句的blendshape数据发送给前端，等下一句blendshape数据 ready 后再发送。FLASK后端可以使用异步处理，用FlaskAPI库的asyncio支持。前端可以使用WebSocket接收blendshape数据，实时播放。 |