流式传输

需求.md

@@ -0,0 +1,176 @@
+我现在已经跑通了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数据，实时播放。