Context
#89 / #90 added capability probing for the eight video base-chain filters, failing fast with an actionable message when a minimal ffmpeg build lacks one. The audio side of the render graph has the identical gap: none of its filters are probed, so a minimal build missing one still reaches ffmpeg and surfaces the same raw parser error class #89 eliminated for the video chain.
Unprobed filters the render graph can emit
Unconditional for every audio segment (src/render.ts, audio chain):
atrim, asetpts, adelayanull (single audio segment) or amix (multiple)
Conditional on draft content:
atempo (speed != 1 within single-stage range), volume (vol != 1), afade (fade in/out set)
Proposed fix
Extend FfmpegCapabilities/probeFfmpegCapabilities with the audio filter names (same single -filters probe, zero extra spawns). Fail fast in renderDraft for the unconditional ones, same message style as #90. For the conditional ones, either fail fast only when the built plan actually uses them, or degrade gracefully the way drawtext/overlay already do; leaning fail-fast-when-used, since silently dropping audio retiming/fades changes output.
Guard test
Add a test that builds a plan from a representative draft (speed, volume, fades, captions, overlay, multiple audio tracks), extracts every filter name from the generated filter_complex, and asserts each one is covered by the probe (or an explicit allowlist). That keeps chain and probe from drifting apart again, for both video and audio, without anyone having to remember this issue exists.
@Kubaklibre natural follow-up to #90 if you want it, no pressure.
Context
#89 / #90 added capability probing for the eight video base-chain filters, failing fast with an actionable message when a minimal ffmpeg build lacks one. The audio side of the render graph has the identical gap: none of its filters are probed, so a minimal build missing one still reaches ffmpeg and surfaces the same raw parser error class #89 eliminated for the video chain.
Unprobed filters the render graph can emit
Unconditional for every audio segment (
src/render.ts, audio chain):atrim,asetpts,adelayanull(single audio segment) oramix(multiple)Conditional on draft content:
atempo(speed != 1 within single-stage range),volume(vol != 1),afade(fade in/out set)Proposed fix
Extend
FfmpegCapabilities/probeFfmpegCapabilitieswith the audio filter names (same single-filtersprobe, zero extra spawns). Fail fast inrenderDraftfor the unconditional ones, same message style as #90. For the conditional ones, either fail fast only when the built plan actually uses them, or degrade gracefully the way drawtext/overlay already do; leaning fail-fast-when-used, since silently dropping audio retiming/fades changes output.Guard test
Add a test that builds a plan from a representative draft (speed, volume, fades, captions, overlay, multiple audio tracks), extracts every filter name from the generated
filter_complex, and asserts each one is covered by the probe (or an explicit allowlist). That keeps chain and probe from drifting apart again, for both video and audio, without anyone having to remember this issue exists.@Kubaklibre natural follow-up to #90 if you want it, no pressure.