如何对拆分到不同Blob的音频进行流式转码？

1. 服务器端以流式模式初始化FFmpeg #

核心是让FFmpeg从启动时就获取编解码上下文，后续只需要喂入裸帧数据即可：

• 先解析第一个Blob的编解码参数（比如采样率、声道数、编码格式，如Opus、PCM等）
• 启动FFmpeg进程，用标准输入（stdin）作为流式输入源，指定匹配的输入格式和参数：
  例如录制的是Opus裸音频帧时，启动命令如下：

  ffmpeg -f opus -ar 48000 -ac 2 -i pipe:0 -f mp3 pipe:1
  

  其中-f opus指定输入格式为Opus裸帧，-ar设置采样率，-ac设置声道数，pipe:0表示从标准输入读取数据，pipe:1将转码后的输出定向到标准输出（可直接转发到接收设备）。

2. 持续向FFmpeg喂入帧数据 #

• 第一个Blob发送到服务器后，先提取其中的编解码头信息完成FFmpeg初始化，再将Blob中的帧数据写入FFmpeg的stdin；
• 后续的小Blob直接作为裸音频帧数据，持续写入FFmpeg的stdin管道。由于初始化阶段已经传入了编解码上下文，FFmpeg可以正常解析处理，不会再出现"Codec not found"报错。

3. 适配RecordRTC的输出格式 #

如果RecordRTC默认输出带容器的格式（如WebM），可以简化处理流程：

• 直接以容器格式作为FFmpeg的输入，启动命令改为：

  ffmpeg -f webm -i pipe:0 -f mp3 pipe:1
  

  此时第一个Blob包含的WebM头信息会被FFmpeg解析，后续的Blob（WebM的Cluster帧块）可以直接流式输入，FFmpeg会自动持续处理。

4. 流式转发到目标设备 #

将FFmpeg的标准输出（转码后的音频流）实时转发：

• 服务器端实时读取FFmpeg的stdout数据，通过WebSocket、TCP等网络协议发送到目标设备；
• 接收设备使用MediaSource API或AudioContext对接收到的流数据进行实时播放。

5. 异常与状态维护 #

• 监听FFmpeg进程状态，若进程崩溃，需重新用第一个Blob的头信息初始化进程；
• 处理网络中断重连场景，重连时需重新发送第一个Blob的头信息，确保FFmpeg重建编解码上下文。

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