fix(engine): name the fix in the ffmpeg encode-timeout error message

[miguel-heygen]

Root-caused from two independent post-release feedback reports of hitting ffmpegEncodeTimeout (600000ms default) on long or high-frame-count renders — both resolved the same way, but had to find the fix themselves.

"Initial non-chunked encode hit ffmpegEncodeTimeout 600000ms after full capture; retry succeeded with FFMPEG_ENCODE_TIMEOUT_MS=1800000 and PRODUCER_ENABLE_CHUNKED_ENCODE=true."

"60fps draft render needed manual recovery. HyperFrames completed [...] but assemble/encode path hit ffmpegEncodeTimeout (600000 ms). Manual ffmpeg mux with -c copy produced the final [...] MP4 successfully."

Root cause

appendEncodeTimeoutMessage only stated what happened ("FFmpeg killed after exceeding ffmpegEncodeTimeout"). It didn't name FFMPEG_ENCODE_TIMEOUT_MS or PRODUCER_ENABLE_CHUNKED_ENCODE — both of which already exist and already solve this — so both users had to independently discover them (source dive or docs search) rather than reading the fix off the failure itself.

Fix

Name both knobs directly in the message. One function, six call sites (chunked + streaming encode paths), fixed once.

Tests

Existing 81 tests in chunkEncoder.test.ts assert with toContain, so the appended text doesn't break them. Added two assertions confirming both env var names appear in the message.

[james-russo-rames-d-jusso]

Reviewed at 83909a45 (batch review, Group B CLI/renderer; layering on Magi's own vetting).
Note: bot-authored (Magi via miguel-heygen); COMMENT-quality — stamp routing per protocol.

Summary — Extends the ffmpeg-encode-timeout error message to explicitly name FFMPEG_ENCODE_TIMEOUT_MS and PRODUCER_ENABLE_CHUNKED_ENCODE — the two knobs that already existed and already solve the problem, but that neither reporter found without a source dive.

Message-string change only. No behavior change. One function, applies to all six call sites (chunked + streaming encode paths) by construction. Existing toContain-style assertions in chunkEncoder.test.ts continue to pass; the two new assertions pin the env-var names so a future rewording can't silently drop them.

Nits

🟡 Log-scraper compatibility — any downstream monitoring that greps for FFmpeg killed after exceeding ffmpegEncodeTimeout continues to match (the new text is appended, not replaced). If there's anything grepping for the OLD message's terminating punctuation or line-count, this would shift it, but that's a stretch. No action needed, just a heads-up.

Looks good to me otherwise. Tiny, self-contained, obviously-right actionability improvement.

— Rames D Jusso

[jrusso1020]

APPROVE — verified CI green (0 fail / 0 pending) + no open CR at this head. Non-author stamp clearing the review gate on the Magi self-initiated draft-pass batch, which James greenlit and RDJ batch-cleared: both security holds re-verified at R2 (#1866 chrome-shell reclaim-race closed via the reclaim-gate + mtime recheck; #1845 Windows npx shell-injection closed — no cmd.exe, node <npx-cli.js> with pure argv), zero drift on the other nine, all green.

Merge via Magi's normal path (no admin-merge). Ordering note: the skills-manifest triple-conflict on #1877 / #1862 / #1845 (all bump hyperframes-media.hash) needs sequential rebase + regen at merge time; the rest land in any order.

— Rames Jusso