0.7.0 init overhead causes ~2x capture_avg_ms regression vs 0.6.42 in headless server rendering

[yahelshiran-rvr]

Describe the bug

After upgrading from @hyperframes/producer 0.6.42 to 0.7.0, capture_avg_ms roughly doubled at p50.
The per-frame capture path (prepareFrameForCapture) is byte-identical between versions ‚ the regression is new init-time work that runs inside the stage4Start ‚Date.now() timing window and gets amortized per frame.

The new init-time costs are:

1. GSAP proxy queue draining via rAF (HF_EARLY_STUB_IIFE) ‚100 ops per tick at 33ms intervals, blocks readiness via __hfTimelinesBuilding
2. __renderReady no longer set by bridge‚ duration getter returns 0 until runtime sets it after proxy drains, adding 100ms+ polling delay
3. armStaticDedup verification‚ up to 400 seek+screenshot captures at init before any real frame is captured
4. pollImagesReady + decodeAllImages‚ unconditional image readiness checks

These are all valuable features for browser/editor use. The issue is they run unconditionally in headless Puppeteer where the tradeoffs are different (no UI to keep responsive, short renders where init cost dominates).

Setting HF_STATIC_DEDUP_VERIFY=false improved p50 by ~16%. The remaining gap is primarily #1 and #2.

Link to reproduction

Steps to reproduce

1. Render any template with @hyperframes/producer 0.6.42, note captureAvgMs from output
2. Upgrade to 0.7.0, render the same template
3. captureAvgMs is ~2x higher, uniform across all templates

Expected behavior

captureAvgMs should be comparable between 0.6.42 and 0.7.0 for the same template, since the per-frame capture code is unchanged.

Actual behavior

captureAvgMs doubled at p50 across all 39 benchmarked templates. In production (125-frame renders): pre-0.7.0 p50 ~153ms, post-0.7.0 p50 ~129ms (with HF_STATIC_DEDUP_VERIFY=false workaround, was higher before).

The metric includes init overhead because stage4Start = Date.now() is set before file server creation and session initialization, and captureMs = Date.now() - stage4Start captures everything.

Environment

✓ Version          0.7.0 
✓ Node.js          v22.16.0 (linux amd64)
✓ FFmpeg           ffmpeg version 5.1.9-0+deb12u1
✓ Chrome           Chromium 149.0.7827.53 (bundled: /usr/bin/chromium)

Additional context

No response

[miguel-heygen]

Thanks for the detailed report. We merged #1657 and released it in the current stable @hyperframes/producer@0.7.2 / v0.7.2.

That change does not disable the new 0.7.x correctness work. It fixes the metric attribution first:

• stages.captureMs remains the broad Stage 4 wall time for compatibility.
• stages.captureSetupMs is the setup/init portion: file server, calibration, readiness/session init, strategy resolution.
• stages.captureFrameMs is the actual frame-capture phase.
• captureAvgMs now uses captureFrameMs / totalFrames instead of amortizing setup into every frame.

Could you rerun one representative affected template on 0.7.2 and share the render perf summary, or at least these fields?

{
  "version": "0.7.2",
  "totalFrames": null,
  "compositionDurationSeconds": null,
  "workers": null,
  "captureAvgMs": null,
  "stages": {
    "captureMs": null,
    "captureSetupMs": null,
    "captureFrameMs": null
  },
  "captureCalibration": null,
  "staticDedup": null
}

Also useful if you have it:

• whether HF_STATIC_DEDUP_VERIFY=false is still set
• image/video/audio counts for that template
• fps, resolution, and whether workers are auto or explicitly configured
• Node/Chrome/FFmpeg versions if they changed from the original report

With the split fields, we should be able to tell whether any remaining regression is setup/calibration/readiness/dedup work or actual per-frame capture cost, and avoid guessing at a headless-specific workaround.

[yahelshiran-rvr]

Reran on 0.7.3 with the template audio-wave-full (pure CSS+JS waveform, no images/video/audio assets, 6s composition, 90 frames).

Solo render (no concurrent load)

{
  "version": "0.7.3",
  "totalFrames": 90,
  "compositionDurationSeconds": 6,
  "workers": 4,
  "captureAvgMs": 174,
  "stages": {
    "captureMs": 15705,
    "captureSetupMs": 64,
    "captureFrameMs": 15641
  },
  "captureCalibration": null,
  "staticDedup": {
    "enabled": true,
    "armed": false,
    "predictedFrames": 0,
    "reusedFrames": 0,
    "skipReason": "ineligible"
  }
}

Full stage breakdown:

Stage	ms
compileOnlyMs	12
browserProbeMs	431
compileMs	444
captureSetupMs	64
captureFrameMs	15,641
captureMs (total)	15,705
encodeMs	3,886
assembleMs	4
renderDurationMs	20,049
uploadDurationMs	251
totalDurationMs	20,300

Environment

• @hyperframes/producer@0.7.3
• Node.js v22.16.0 (linux amd64)
• Chromium 149.0.7827.53 (bundled)
• FFmpeg 5.1.9-0+deb12u1
• AWS c6a.4xlarge (16 vCPU, 32 GB)
• fps=15, resolution=1920x1080, workers=4 (explicit)
• HF_STATIC_DEDUP_VERIFY — unset (default)
• HF_EARLY_STUB_IIFE — unset (default)
• videoCount=0, audioCount=0, peakRssMb=282

Comparison with 0.6.42

Same template, same instance type, solo render (no concurrent load):

Producer	captureAvgMs	captureFrameMs	captureSetupMs	renderMs
0.6.42	64	N/A (not split)	N/A	12,937
0.7.3	174	15,641	64	20,049

The metric fix from #1657 is working — captureSetupMs is only 64ms, so setup isn't being amortized into captureAvgMs anymore.

However, captureAvgMs is still 174ms vs 64ms on 0.6.42 a ~2.7× per-frame regression that appears to be in the actual frame-capture path, not init/setup overhead.

staticDedup was ineligible for this template (audio-only waveform, no static frames), so that's not a factor. captureCalibration is null.

audio-wave-full.html