hyperframes-issue-repo

Minimal reproduction for a regression in hyperframes@0.6.11: a 1080×1920 portrait composition whose only visual content is a canvas-sized <video> renders with the video element shorter than the canvas for the first ~37 seconds — the bottom edge of the clip sits ~60–100px above the canvas floor, exposing whatever is layered behind it.

The color of the exposed strip depends on the host composition:

• This repro uses #000 for body / #main background → the strip shows as black (RGB averages around #030103).
• The original composition that surfaced the bug uses the same #000 backgrounds → the strip shows as white. The white must therefore be coming from something HyperFrames itself paints behind the video clip, not from the host CSS.

At t≈37s the gap closes and the rest of the clip renders correctly.

Confirmed not to happen in hyperframes@0.6.10.

Layout

repro/                       # blank hyperframes project (npx hyperframes init repro --example blank --resolution portrait)
  index.html                 # minimal composition: one <video> element, no transforms, no object-fit
  generate-sample.sh         # rebuilds assets/video/sample.mp4 with ffmpeg
  assets/video/sample.mp4    # 1080x1920 H.264 CFR 30fps 50s test pattern
renders/
  out-0.6.10-clean.mp4       # rendered with hyperframes@0.6.10 — correct
  out-0.6.11-broken.mp4      # rendered with hyperframes@0.6.11 — shows the bug
  frames/                    # extracted comparison frames at 1s, 10s, 20s, 30s, 36s, 38s, 40s, 45s

Reproduce from scratch

# 1. Scaffold the same blank project (the issue template's required command).
npx hyperframes init repro --non-interactive --example blank --resolution portrait

# 2. Drop in the sample video.
cd repro && ./generate-sample.sh

# 3. Render against both versions.
npx --yes hyperframes@0.6.10 render --output ../renders/out-0.6.10-clean.mp4   # clean
npx --yes hyperframes@0.6.11 render --output ../renders/out-0.6.11-broken.mp4  # broken

What to look at

Open both files in renders/. In out-0.6.11-broken.mp4 you'll see a horizontal gap pinned to the bottom of the frame from t≈0 until t≈37s — in this repro the canvas background is #000 so the gap reads as black. In out-0.6.10-clean.mp4 the green/red/white test pattern fills the canvas the entire way through.

Frame-by-frame proof (renders/frames/), bottom 100px row sampled and averaged to a single RGB value with ffmpeg:

t	v0.6.10 bottom row	v0.6.11 bottom row
1s	#97c198	#030103 ← bug
10s	#97c198	#030103 ← bug
20s	#97c198	#030103 ← bug
30s	#97c198	#030103 ← bug
36s	#97c198	#030103 ← bug
38s	#97c198	#97c198 (recovered)
40s	#97c198	#97c198
45s	#97c198	#97c198

(#97c198 is the green bottom of the source averaged with the 60px white "BOTTOM EDGE" strip the sample paints at the very bottom. #030103 is the canvas background showing through because the video element doesn't reach the canvas floor.)

Environment

OS	macOS 26.5 (Darwin 25.5.0)
Arch	Apple Silicon (arm64)
Node	v22.20.0
Last good	hyperframes@0.6.10
First broken	hyperframes@0.6.11
Still broken in	hyperframes@0.6.31 (latest at filing)

Notes

• The composition has no transforms, no object-fit, no GSAP tweens — just a static 1080×1920 <video> on a 1080×1920 canvas with a 1080×1920 H.264 source. The video element, the canvas, and the source are all identical dimensions.
• The bug does not appear in hyperframes preview (live DOM). It only appears in the rendered MP4, so the symptom lives in the render path.
• The bar disappears at a deterministic ~37s, which is suspiciously like a render-pipeline switchover (encoder warmup boundary? streaming-encode gate? GOP boundary handling?). 37s on a 50s timeline is 74% — does the render path flip a switch around then?