16KB/s音频推流异常及ffmpeg动态切换音频流需求咨询

核心问题：FFmpeg内部缓存积压 #

当你以16KB/s速率推送时，推送速度超过了FFmpeg编码/向RTP服务器发送的速度，导致FFmpeg内部缓存了大量音频数据。停止推送后，FFmpeg会继续播放缓存内的内容直至耗尽，这就是延迟数十秒才停止的原因；而8KB/s的推送速度刚好匹配FFmpeg的处理节奏，缓存无堆积，所以停止后声音立即终止。

当前代码的错误点 #

1. 固定推送节奏与实际处理速度不匹配：手动设置await delay(125)和固定读取16*128字节，没有对齐FFmpeg受编码、网络影响的实际处理速度，导致数据持续积压在FFmpeg输入缓冲区。
2. 流切换逻辑不严谨：previousStream的循环判断重复且无效，切换音频时未主动终止旧文件读取流（fileP），可能导致旧流数据继续被推送。
3. 手动push引发缓存失控：直接调用stream.push(chunk)而非通过可读流_read方法响应下游需求，容易造成上游推送速度远快于下游处理，加剧缓存堆积。

解决方案 #

1. 限制FFmpeg内部缓存大小 #

在FFmpeg推流命令中添加以下参数，强制缩小缓存容量：

# 限制RTP发送缓冲区大小（单位：字节），匹配你的推送块大小设置
-rtpbufsize 2048
# 关闭最大延迟，减少内部缓存
-max_delay 0
# 若使用编码音频，添加低延迟编码器参数（以Opus为例）
-acodec libopus -vbr off -compression_level 10 -application lowdelay

2. 改进流推送逻辑，匹配下游处理速度 #

抛弃固定延迟的推送方式，改为通过下游的drain事件控制推送节奏，或自定义可读流让FFmpeg主动请求数据，从根源避免缓存积压。

修改后的代码示例：

const { Readable } = require('stream');
const fs = require('fs');

// 自定义可读流，响应下游需求推送音频数据
class AudioStream extends Readable {
  constructor() {
    super({ highWaterMark: 2048 }); // 高水位线匹配你的推送块大小
    this.currentFileStream = null;
  }

  // 切换音频流的核心方法
  switchAudio(inputPath) {
    // 终止当前活跃的文件读取流
    if (this.currentFileStream) {
      this.currentFileStream.destroy();
      this.currentFileStream = null;
    }
    // 启动新的文件读取流
    this.currentFileStream = fs.createReadStream(inputPath);
    this.currentFileStream.on('data', (chunk) => {
      // 若push返回false，说明下游缓存已满，暂停读取
      if (!this.push(chunk)) {
        this.currentFileStream.pause();
      }
    });
    this.currentFileStream.on('end', () => {
      this.push(null); // 标记当前流结束
    });
    // 监听drain事件，下游缓存空闲后恢复读取
    this.on('drain', () => {
      this.currentFileStream?.resume();
    });
  }

  _read() {
    // 无需额外逻辑，依赖currentFileStream的data事件推送数据
  }
}

// 使用示例
const audioStream = new AudioStream();
// 将audioStream传入FFmpeg作为输入...

// 切换到新音频时调用
audioStream.switchAudio('new-audio-source.raw');

3. 流切换的注意事项 #

• 切换时必须销毁旧文件读取流，杜绝旧数据继续推送。
• 确保新旧音频流的参数（采样率、通道数、编码格式）一致，避免FFmpeg报错。
• 若需无缝切换，可在切换前推送几帧静音数据，避免爆音或中断。

内容的提问来源于stack exchange，提问作者Hexona