mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-11-11 19:09:20 +00:00
Vance IngallsandClaude Fable 5
905ccfbbd8
The style-7/8/10/15 prod comps never completed a Docker fast render (2x protocolTimeout, then failure). Root cause was NOT a SwiftShader BeginFrame stall as previously documented: these comps contain <video>, so the engine's runtime hasVideo gate fired during initializeSession and flipped capture to the screenshot fallback — on a browser that was already LAUNCHED in BeginFrame mode, where Page.captureScreenshot hangs by design for the full protocol timeout. Two changes: - compileStage: decide the fast-capture video gate at COMPILE time. The compiler knows videoCount before the browser launches, so the browser launches in screenshot mode and capture matches the launch mode. The runtime gate stays as backstop for dynamically-created <video>. HF_FAST_CAPTURE_VIDEO=true bypasses both gates. - probeStage: BeginFrame liveness probe (one bounded BeginFrame, PRODUCER_BEGINFRAME_PROBE_TIMEOUT_MS, default 30s) for sessions launched in BeginFrame mode. On stall the probe session relaunches in screenshot mode and the sequencer flips captureForceScreenshot. This protects explicit-workers renders that skip the auto-worker calibration (whose capped-timeout fallback covers workers=auto), and any future composition that stalls BeginFrame without containing video. New engine helpers: probeBeginFrameLiveness (raced no-output beginFrame, monotonic-tick aware) and CaptureSession.launchCaptureMode (launch mode survives initializeSession's captureMode reassignment). Docker fast results (was: timeout after 3608s, no output): style-7-prod 77.6s 53.7 dB vs baseline style-8-prod 86.7s 55.4 dB style-10-prod 83.4s 53.0 dB style-15-prod 318s 49.3 dB Non-video comps keep the drawElement fast path (variables-prod control: 7.0s, unchanged). Alpha fast path unaffected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>