[miguel-heygen]

Every render with audio failed at the audio mix on FFmpeg 4.4 (Ubuntu 22.04's apt install ffmpeg, the install the docs give): setts_bsf: Option 'duration' not found, reported as audio_processing_failed / ffmpeg_unsupported. The segmented AAC encode (0.8.170) joins its segments as ADTS, which carries no end, and ends the stream with setts=duration=...; that option arrived in FFmpeg 5.0. The segmented path runs for every audio render, not only long ones.

encodeAac now asks the FFmpeg it will use whether setts has a duration option (once per binary). If it does, nothing changes: same segments, same bytes. If it does not, the audio is encoded in one pass, which ends the stream at the duration itself. That is slower on long mixes (one encoder, about 60x real time) and only affects FFmpeg older than 5.0. No minimum FFmpeg version is declared anywhere, and the docs point Ubuntu users at apt install ffmpeg, so 4.4 is supported in practice.

Verified on a real FFmpeg 4.4.2 (Ubuntu 22.04 container on the devbox) with the CLI: a 2 s composition with one AAC clip, render --fps 24 --workers 1. On main it fails with the reported error; with this change it renders, audio and video both 2.000 s. On the current FFmpeg the same render still takes the setts path.

Tests: with a stub FFmpeg that rejects setts=duration and prints no duration in its help, encodeAac succeeds and the stream ends at the same tick as the normal encode (fails on main). The existing byte-identity and segment tests pass unchanged (9/9).

[github-actions]

Edit accuracy: accurate 271 (base branch 271), smooth 176 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (0)

[heygengenesis]

Verdict: APPROVE · 0 blocker · 1 important · 1 nit · head e397d1d0

• important (pre-existing, but this PR's new test depends on it) — on FFmpeg 5.1 (Debian 12's default) setts has duration, so the segmented path runs, but the stream doesn't end at the duration. Locally with 5.1.9, encodes a long mix in parallel segments… fails on main (7224288 vs 7224000). The new test fails the same way at aacEncode.test.ts:227: one-pass gives 120000 (exactly 2.5 s), the segmented reference gives 120816. Your one-pass output is the correct one. Comparing to 2.5 * 48000 instead of the segmented reference would make the test pass on any host's FFmpeg. The 5.x end overshoot deserves its own follow-up.
• nit — aacEncode.ts:83: the one-pass encode drops -cpuflags 0, so on FFmpeg < 5 the bytes (and anything hashed from them) can differ between machines. Adding it keeps the property the MAX_SEGMENTS comment relies on.

Scope

The probe is cached per binary and fails open: on a probe error the segmented path runs and reports its own error. A missing setts (pre-4.4) also prints no duration, so those builds take the one-pass path too. The setts=duration in aacEncode.ts is the only setts use in packages/, and both callers (audioMixer.ts:1362, audioPadTrim.ts:598) go through encodeAac. Required CI was still running at review time.

[heygengenesis]

Verdict: APPROVE — 0 resolved, 2 open (non-blocking), 0 new · e397d1d0 → 7f15da85. Patch is identical to the approved head apart from dropping export on supportsSettsDuration, which has no other callers; the rest is the rebase.