extract_audio_pcm detects “no audio stream” by matching ffmpeg’s stderr text, so a wording change turns silent clips into hard errors

快速结论：当拼接、裁剪或音频提取流程处理“无音轨”的静音视频（例如 Wan 生成的片段）时，extract_audio_pcm 通过匹配 ffmpeg stderr 中的 “does not contain any stream” 文本来判断“没有音轨”。一旦 ffmpeg 版本或语言环境改变了这句措辞，静音片段就会被当成真失败并抛出 AudioExtractionError。优先确认实际调用的 ffmpeg 二进制来源与版本。

适用环境：InvokeAI 的 invokeai/app/util/video_audio.py；Issue 中已确认的测试环境包括 Windows、内置 FFmpeg 7.1（imageio-ffmpeg 0.5.1 捆绑）以及通过 IMAGEIO_FFMPEG_EXE 指定的 FFmpeg 4.2.2 便携二进制。Python、CUDA、PyTorch、显卡信息未在该 Issue 中给出。

最快修复方案：暂无确认的一步修复方案。Issue 中验证过的候选方案是：在解码失败后增加一次零时长、流复制（stream copy）的 ffmetadata 探测，用输出结构而非错误文本区分“合法但无音轨的容器”和“真正不可读的输入”；该方案已在评论所述范围内通过回归测试，但尚未合入上游。

注意事项：仅改用 -map 0:a:0? 不足以解决问题——评论指出，在捆绑 FFmpeg 7.1 下，零流 WAV/f32 输出仍会失败。候选方案会让静音/错误输入多起一次进程（成功提取时无额外开销），且仅验证了 Windows 上的 FFmpeg 4.2.2 与 7.1，其他平台与 UI 集成未声明验证；仍需抑制非音频自动选择与被复制的元数据，避免恶意元数据伪造 [STREAM] 行。

问题场景

在 InvokeAI 中执行视频拼接（Concatenate Videos 保留音频）、裁剪或帧范围处理时，内部会调用 extract_audio_pcm() 抽取音轨。对于没有音轨的静音片段（Issue 提到 Wan 生成的剪辑就是这种形态），该函数本应返回 None，让调用方按“无音频、继续处理”走。但如果 ffmpeg 报错的英文措辞与代码里的子串不匹配，就会抛 AudioExtractionError，导致对一个完全合法的视频报错。

报错原文

if proc.returncode != 0:
    stderr = proc.stderr.decode("utf-8", errors="replace")
    # ffmpeg's phrasing for an input with no audio track ("Output file #0 does not
    # contain any stream" / newer "does not contain any stream" variants).
    if "does not contain any stream" in stderr:
        return None
    raise AudioExtractionError(...)

核心报错为 AudioExtractionError，触发条件是 stderr 中不再出现 does not contain any stream。

原因分析

最可能的原因：extract_audio_pcm() 用子串匹配 ffmpeg 的英文 stderr 文本来判定“容器没有音轨”。Issue 作者明确指出，这段注释本身就提示措辞曾发生过一次变化。平时之所以稳定，是因为 _ffmpeg_exe() 解析到 imageio_ffmpeg.get_ffmpeg_exe() 提供的固定捆绑二进制；风险在于 IMAGEIO_FFMPEG_EXE 允许用户指向任意版本、任意语言环境的发行版 ffmpeg。一旦措辞不同，静音输入就从正常返回 None 变成硬错误。这是潜在脆弱性，不是已发生的回归。

环境排查

确认 InvokeAI 实际使用的 ffmpeg 来源：是否设置了 IMAGEIO_FFMPEG_EXE，指向的是发行版 ffmpeg 还是 imageio-ffmpeg 捆绑二进制。
确认该 ffmpeg 的版本号与语言环境（stderr 措辞受版本和 locale 影响）。
确认输入视频是否确实没有音轨（属于正常情况），还是文件本身损坏或不可读（应保持报错）。
确认复现路径是否涉及拼接、裁剪或帧范围处理，以判断调用方是否依赖 None 语义。
Python、CUDA、PyTorch、显卡与节点版本未在该 Issue 中给出，不作为排查依据。

解决步骤

先记录当前 ffmpeg 的实际路径与版本，并区分“未设置 IMAGEIO_FFMPEG_EXE（走捆绑二进制）”和“指向外部 ffmpeg”两种情况，缩小是否由措辞差异导致的范围。
可优先尝试临时去掉 IMAGEIO_FFMPEG_EXE，回退到 imageio_ffmpeg 的捆绑二进制，验证静音片段是否恢复正常处理。
若需要根本修复，Issue 建议的方案是探测音轨结构而不是匹配错误文本：例如先用 ffprobe -select_streams a 判断是否存在音频流，或使用可选映射。
评论补充指出，单独的 -map 0:a:0? 在捆绑 FFmpeg 7.1 下对零流 WAV/f32 输出仍然失败，因此推荐结构检查方案：只有在解码失败之后，才执行一次零时长、流复制的 ffmetadata 输出；探测成功、头部有效且无音频流时返回 None；探测失败、输出未知或存在音频流时保留原有解码错误。
实施时需同时抑制非音频自动选择与被复制的元数据，并保持超时与临时文件清理有界；评论中提到的候选提交与回归用例可作为参考，但该修复尚未被上游合入。

验证方法

用静音 MP4/Matroska 走拼接、裁剪或提取流程，应正常返回“无音频”而不报 AudioExtractionError；损坏的 AAC 或不可读输入应仍然报解码错误。评论中给出的验证结果是：候选方案 22 例回归全部通过，而当前上游在同一隔离环境下为 12 失败 / 10 通过；真实媒体辅助测试覆盖静音 MP4、Matroska、恶意元数据、WAV、损坏 AAC、损坏与缺失输入，其中 28 项提取检查、14 项结构分类检查和 2 项元数据伪造对照均通过。这些结果仅限评论所述环境，未覆盖完整应用集成。