Skip to content

fix: bound legacy ffmpeg frame-extraction calls with a timeout - #65

Closed
Praveen Kumar Mittal (mittalpk) wants to merge 1 commit into
microsoft:mainfrom
mittalpk:fix/ffmpeg-extraction-timeout
Closed

fix: bound legacy ffmpeg frame-extraction calls with a timeout#65
Praveen Kumar Mittal (mittalpk) wants to merge 1 commit into
microsoft:mainfrom
mittalpk:fix/ffmpeg-extraction-timeout

Conversation

@mittalpk

Copy link
Copy Markdown

Fixes #14.

What's wrong

extractLegacyWindow/extractLegacySingle in electron/frames/extractor.ts run the system ffmpeg binary via execFileAsync(ffmpegPath, [...], { maxBuffer }), with no timeout. If ffmpeg stalls (corrupt input, codec edge case, stuck pipe), the promise never settles and frame extraction — and the describer/analysis pipeline behind it — hangs indefinitely for that session.

Fix

Added a LEGACY_FFMPEG_TIMEOUT_MS (60s) constant and passed it as timeout on both execFileAsync calls. On timeout, Node kills the child and the call rejects, which both call sites already route into their existing catch (log a warning, return an empty/null result) — the same handling as any other ffmpeg failure, so no new error-handling path was needed.

How I tested it

  • extractLegacyWindow/extractLegacySingle are private and resolve their ffmpeg binary through a module-level, cached which/where lookup that isn't test-injectable without expanding this fix's scope. Instead, added a test that exercises the same mechanism directly: a genuinely hung child process (node -e "setInterval(...)"), asserting execFileAsync with a timeout kills it and rejects well within the bound rather than hanging.
  • npm test: 155/158 pass; 2 failures + 1 cancelled, all confirmed identical on unpatched main with none of this PR's changes — unrelated (a pre-existing debug-bundle.test.ts/archiver typing issue and a flaky microphone-controller test).
  • npm run typecheck: pre-existing, unrelated failures in debug-bundle.ts also confirmed identical on main; no new errors from this change.

extractLegacyWindow/extractLegacySingle ran the system ffmpeg binary
with no timeout, so a stalled ffmpeg (corrupt input, codec edge case,
stuck pipe) hung frame extraction indefinitely. Adds a bounded timeout
to both execFileAsync calls; on timeout the child is killed and the
call rejects into the existing catch/log/return-empty handling.

Fixes microsoft#14
@adilei

adilei commented Aug 24, 2026

Copy link
Copy Markdown
Collaborator

Thanks for tackling this and for highlighting the unbounded ffmpeg call. We fixed #14 for 0.6.0 in #69 by removing the legacy system-ffmpeg fallback entirely: captured-frame manifests have shipped in every tagged release since v0.1.0, so deleting the unreleased compatibility path also eliminates timeout and partial-output failure modes. Closing this PR as superseded by #69.

@adilei adilei closed this Aug 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Medium] Frame-extraction ffmpeg calls have no timeout (can hang indefinitely)

2 participants