By my math, one 45-second game trailer is 1,350 frames. Its author says zero were screen-recorded.
The build write-up runs the clock first and the picture second, so a slow laptop has no frame to drop.
> STEP - a script sets the game to time i/30, one tick per frame
> SHOOT - headless Chromium saves a PNG of that exact moment
> ENCODE - the PNGs pipe into libx264 at CRF 16, 1080x1350 vertical
On a 3D browser game, the write-up says, a screen recorder drops frames.
Stepping trades that for failures you can test.
Headless Chromium's software GPU sometimes loses its drawing context and returns white frames, so the fix is a lost-context check after every render and a page reload.
The second trap is one pixel. The encoder rejects odd heights: 1080x675 failed, 1080x674 worked. That's 0.15% between a crash and a clean encode.
Before any long render the author studies 8-12 keyframes, under 1% of the trailer by my count.
The write-up credits that look with 4 bugs. 20 balloons leaned a flat island 22 degrees because the code subtracted their mass. Auto-dropped houses scored without the road check. The tilt gauge followed the camera. A label hid the HOLD ON banner.
No syntax check flags any of them. Each one shows in a single still.
If a model writes your visual code, read a dozen frames after every pass.
I laid the loop out as an editor timeline, the two traps and four bugs surfacing as cards ↓