实时数字人音频特征计算

livetalking开源地址：https://github.com/lipku/LiveTalking
国内镜像地址:https://gitee.com/lipku/LiveTalking

在数字人嘴型驱动的技术流程中，核心环节是将原始音频信号转化为模型可识别的特征向量（embedding），再依据视频帧的时长特性对这些音频特征进行分组（即chunk处理），最终将每个特征组输入数字人模型，实现精准的嘴型驱动效果。

一、离线与实时数字人的音频处理差异

离线数字人系统具备完整的音频数据优势，通常会先对整个音频文件进行一次性特征提取，再完成后续的分组操作。这一设计的核心原因在于，音频特征模型在计算过程中需要依赖当前音频帧的前后上下文数据来构建相关性，完整输入音频文件能够让模型充分利用长时序的上下文信息，提升特征提取的准确性。

而实时数字人系统面临的是流式输入的音频数据，无法像离线系统那样获取完整音频信息。为了在保证交互低延时的前提下构建上下文相关性，系统会采用“前后缓存”策略——仅缓存当前音频帧前后的部分数据用于相关性计算，且缓存数据量会严格控制以降低延时。在livetalking技术框架中，这一缓存机制通过stride_left_size（前向缓存帧数）和stride_right_size（后向缓存帧数）两个参数精准定义。

二、实时系统的队列初始化与数据流转机制

以典型参数配置为例：设stride_left_size=6、stride_right_size=8，音频特征处理的批次大小（batch）为16。在livetaking系统启动阶段，baseasr模块的预热（warmup）流程会完成两个核心队列的初始化——音频计算队列（frames）与输出队列（output_queue），这两个队列是保障音频驱动嘴型与音频播放时序对齐的关键。

初始化时，frames队列会插入6+8=14个音频帧，output_queue队列则插入8个音频帧。这一设计的深层逻辑是：前6个音频帧仅作为上下文参与相关性计算，不直接用于嘴型驱动，而8个后向缓存帧则用于衔接后续流式数据，确保时序连续性。

2.1 单批次音频数据的处理流程

当一个批次（16帧）的音频数据输入系统后，frames队列的总帧数变为初始14帧加新输入16帧，共计30帧。系统会对这30帧音频数据进行完整的特征计算，但为了匹配嘴型驱动需求，仅提取第6至第22帧（区间[6,22)）的16帧特征用于实际驱动。

特征提取完成后，frames会执行“左移16帧”操作，丢弃已完成处理的前16帧数据。需要特别注意的是，本次输入的16帧音频数据中，最后8帧并未参与本次嘴型驱动，而是作为后向缓存保留，将在下次批次数据处理时发挥上下文作用，这一设计进一步强化了时序连续性。

三、音频特征与视频帧的匹配策略

音频模型生成特征向量（embedding）后，需先完成特征与音频帧的映射对齐：通过embedding中与音频帧数量相关的维度进行切分，以该维度长度除以输入音频帧总数，即可得到单个音频帧对应的embedding片段。

在数字人嘴型驱动场景中，采用“一帧视频对应两帧音频”的映射规则，因此会提取对应两帧音频的embedding片段作为基础特征。为进一步强化特征的上下文关联性，系统会以该基础特征为中心，截取长度为winsize的特征窗口——相当于在embedding维度上执行滑动窗口操作，最终将窗口内的特征组合作为当前视频帧的最终音频输入特征。

四、主流音频模型的参数配置

不同音频模型的特征输出特性存在差异，对应的视频帧匹配参数也有所不同，具体配置如下表所示：

音频模型	一帧视频对应embedding维度长度	特征窗口长度（winsize）
mel	80/25	16
whisper	2	10
hubert	2	10