Drive a real browser from a script. A fixed clock, so frames never drift.
This clip is Reel's own output. Three shots, nine actions, a fixed clock — 314 frames at exactly 24 fps while real work took 76.6 ms per frame. The first cut scored 98 and named its own defect: jump-cut at 7.5s in terra, reads as a cut, not a move. That was the WebGL scene arriving after the scroll had started. It gets 3.8 s to be up now, and the critique is clean.
Screen recorders drop frames when the machine is busy, so the same run looks different every time and you cannot tell a real change from a slow laptop. Reel runs the clock itself: frame 91 is frame 91 on any machine. Record the same script tomorrow and you get the same frames.
{
"name": "studio-tour",
"viewport": { "width": 1440,
"height": 900 },
"fps": 24,
"shots": [
{ "id": "land",
"actions": [
{ "type": "goto", "url": "/" },
{ "type": "hold", "ms": 1100 },
{ "type": "scroll", "to": 620,
"ms": 1500 }
] }
]
}
An agent can write, diff and review a shot list before anything runs. Imperative code has to be executed to be understood.
$ npx @mrkt_frwd/reel recordings/studio-tour/script.json --dry-run RECORD studio-tour ──────────────────────────────────── ok script is well formed ok every selector resolves OK dry run — nothing was recorded real 4.06s
Both are counting frames. Put the machine under load and watch which one starts skipping.
A capture dies four minutes in on a renamed selector. --dry-run catches it in four seconds, without recording a frame.
Needs Chromium and ffmpeg. The other three run on a bare Node install; this one does not.