Skip to content

fix: fall back to screenshot mode when any CDP call times out during calibration#567

Merged
miguel-heygen merged 1 commit intomainfrom
fix/566-calibration-cdp-timeout-screenshot-fallback
Apr 29, 2026
Merged

fix: fall back to screenshot mode when any CDP call times out during calibration#567
miguel-heygen merged 1 commit intomainfrom
fix/566-calibration-cdp-timeout-screenshot-fallback

Conversation

@miguel-heygen
Copy link
Copy Markdown
Collaborator

Summary

  • Root cause: shouldFallbackToScreenshotAfterCalibrationError only matched HeadlessExperimental.beginFrame errors. When a composition with many heavy videos (e.g. 7 videos with sparse keyframes) caused Chrome to be unresponsive in BeginFrame mode during calibration, a Runtime.callFunctionOn timed out or Runtime.evaluate timed out error was treated as an opaque failure — not a BeginFrame-mode signal. The render kept BeginFrame mode, spawned 3 workers with captureCostMultiplier=8, and all 3 workers also timed out initialising their sessions (0 frames captured, render fails).
  • Fix: Add Runtime.callFunctionOn timed out and Runtime.evaluate timed out to the screenshot-fallback pattern. Any CDP call timing out during the short-timeout calibration probe now routes the render into single-worker screenshot mode — the safe fallback already used for explicit BeginFrame timeouts.
  • Result: Compositions that overwhelm BeginFrame mode (reported in Running "hyperframs render" on a Linux system, video compositing always fail. #566: 7 videos, 8 audios, 330-second render) now fall back cleanly and complete instead of failing with 0 frames.

Test plan

  • New unit test: falls back to screenshot mode after Runtime.callFunctionOn timeout during calibration — asserts both Runtime.callFunctionOn timed out and Runtime.evaluate timed out return true
  • All existing capture calibration safeguards unit tests still pass
  • Pre-commit hooks (lint, format, typecheck) pass

Fixes #566

…calibration

BeginFrame calibration uses a 30 s protocolTimeout to detect expensive
compositions early. On Linux with chrome-headless-shell, compositions
with many heavy videos (e.g. 7 videos with sparse keyframes) can cause
Chrome to be unresponsive during BeginFrame-mode initialisation — not
just during beginFrame calls themselves, but during any CDP call
(Runtime.callFunctionOn / Runtime.evaluate).

Previously shouldFallbackToScreenshotAfterCalibrationError only
matched HeadlessExperimental.beginFrame errors, so a
Runtime.callFunctionOn/evaluate timeout during calibration was treated
as an opaque failure: the render stayed in BeginFrame mode, spawned 3
workers with a pessimistic cost multiplier of 8, and all 3 workers
then also timed out during session initialisation (0 frames captured).

Fix: extend the pattern to also match Runtime.callFunctionOn and
Runtime.evaluate timeouts. This routes the render into single-worker
screenshot mode — the same safe fallback already used for BeginFrame-
specific timeouts — and the render completes successfully.

Fixes #566
@miguel-heygen miguel-heygen merged commit bcd7230 into main Apr 29, 2026
47 of 49 checks passed
@miguel-heygen miguel-heygen deleted the fix/566-calibration-cdp-timeout-screenshot-fallback branch April 29, 2026 18:03
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.

Running "hyperframs render" on a Linux system, video compositing always fail.

2 participants