在使用 Qt 的 QProcess 以调用外部 ffmpeg/ffprobe 进行音视频处理时，常见的工作流程是：

1. gatherParams：通过 ffprobe 同步获取媒体文件的参数（分辨率、采样率、声道数、码率等）。

2. reencode：逐个文件调用 ffmpeg -crf 或者 ffmpeg -c:a libmp3lame，异步重新编码到统一格式。

3. concat：生成 concat_list.txt 后，调用 ffmpeg -f concat 将中间文件拼接成最终输出。

在 Debug 模式下一切运行正常，但切换到 Release（尤其是打包到生产环境）后，却经常出现程序卡在“开始拼接…”或无法结束 waitForFinished()，不抛错也不返回的怪异现象。本文将深入剖析其背后的根因，并提供简单可靠的解决方案。

---

一、问题重现

• 视频合并：VideoMerger 在 startConcat() 调用 ffmpeg -f concat 后，永远等不到 finished()，进度条卡住。

• 音频合并：同理，AudioMerger 在拼接阶段也陷入“死循环”。

• Debug 模式：IDE 输出面板能看到 ffmpeg 日志，流程正常结束。

• Release 模式：IDE 不在；也没有 QProcess 输出日志；程序停在那不动。

---

二、为什么会卡死？

操作系统对每个子进程的 stdout 和 stderr 都设有管道缓冲区（通常约 4–64 KB 不等）。当 ffmpeg/ffprobe 输出日志到 stderr（ffmpeg 默认把进度和警告都输出到 stderr）时：

1. 如果 没人读取，缓冲区一旦写满，子进程再写就被阻塞。

2. 被阻塞的子进程卡在写日志上，无论它是否执行到“结束逻辑”，都无法调用 exit()，因此 Qt 收不到 finished() 信号。

3. 程序就好像“挂住”了：既不成功也不报错。

---

三、为什么 Debug 下不出问题？

1. IDE 帮你读管道
   在 Qt Creator、Visual Studio 等调试器中，子进程的 stderr/stdout 会被自动转发到“应用输出”视图——等于在后台不断做 read()。

2. 执行速度慢
   Debug 编译跑得更慢，ffmpeg 输出日志的速度往往跟不上缓冲区填满的节奏；另外，IDE 读缓冲区的效率也帮忙拉低了写入速度。

---

四、两个简洁可靠的解决方案

1. 持续 drain 输出

• 优点：不修改 ffmpeg 参数，兼容所有场景。

• 做法：

  // 对于每个 QProcess，都这样设置并连接：
  proc->setProcessChannelMode(QProcess::MergedChannels);
  connect(proc, &QProcess::readyReadStandardError, this, [=](){proc->readAllStandardError(); // 或者 readAllStandardOutput()
  });
  

• 原理：将 stdout 和 stderr 合并到一条管道，只需持续读取一次就能清空所有日志，避免缓冲区写满。

2. 直接转发到父进程

• 优点：无需在代码里手动读；可以在控制台直接看到 ffmpeg 输出。

• 做法：

• proc->setProcessChannelMode(QProcess::ForwardedChannels);