Bug: 'Input format lavfi is not available' — formatRegexp drops virtual demuxers

[isamu]

Summary

Inputs like inputFormat('lavfi') (used to feed testsrc=… or sine=… virtual sources to ffmpeg) fail with Input format lavfi is not available, even though ffmpeg -formats clearly lists lavfi. The cause is a 1-character mismatch in our formatRegexp — virtual / device demuxers are emitted with a 3-flag column (D d for "demux + device") instead of the standard 2-flag column (D ), and the regex only consumes 2 flags.

Upstream issues

• fluent-ffmpeg/node-fluent-ffmpeg#1282 — Error: Input format lavfi is not available (open since 2024-06, 8 comments)
• fluent-ffmpeg/node-fluent-ffmpeg#1262 — Error: Output format mp4 is not available (sometimes hits the same parser fragility on ffmpeg 7)
• fluent-ffmpeg/node-fluent-ffmpeg#1276 — Open upstream PR with the same one-character regex tweak (since 2024-05, unmerged)

Reproduction

import ffmpeg from "@modernized/fluent-ffmpeg";
ffmpeg()
  .input("testsrc=duration=1:size=320x240:rate=30")
  .inputFormat("lavfi")
  .output("/tmp/out.mp4")
  .on("error", (err) => console.error(err.message))
  .run();
// → "Input format lavfi is not available"

ffmpeg -formats shows the row:

 D d lavfi           Lavfi

The d in column 3 marks the format as a "device". Our formatRegexp (lib/capabilities.ts:19):

const formatRegexp = /^\s*([D ])([E ])\s+([^ ]+)\s+(.*)$/;

expects exactly 2 flag columns, so the d is mis-aligned and the row is silently dropped from the parsed format table.

Fix plan

Allow an optional 3rd flag character (a d for device, or a space):

- const formatRegexp = /^\s*([D ])([E ])\s+([^ ]+)\s+(.*)$/;
+ const formatRegexp = /^\s*([D ])([E ])[d ]?\s+([^ ]+)\s+(.*)$/;

Behaviour-preserving: existing 2-flag rows still match (the [d ]? is optional), and 3-flag rows with d or space are accepted. The capture group indices for name (match[3]) and description (match[4]) are unchanged.

Test plan

A unit test fixture that feeds a captured ffmpeg -formats snapshot containing the D d lavfi … line into parseFormatsOutput and asserts formats.lavfi.canDemux === true.

Caveat

Our local _checkCapabilities then accepts lavfi as a valid input format. The actual virtual-source generation (testsrc=…) still flows through ffmpeg as before — no runtime behaviour beyond the cap check changes.