Clips that start on the action, not the warm-up

A PageToVid film is built from short browser recordings: the recorder opens the site, scrolls to the right section, hovers, clicks, and the video engine weaves those clips together under the voice. When a viewer says the scroll feels rushed, the natural reflex is to slow the scroll down.

We had done exactly that, twice. The notes kept coming. So instead of turning another dial, we asked a better question: what, frame by frame, is the viewer really seeing? The answer led us to two improvements that make every film calmer and more reliable.

Much of a film's polish comes from ffmpeg, the standard toolkit for audio and video. It masters the narration so the voice sounds unhurried and even, and it turns raw browser recordings into clean video with a steady frame rate that plays smoothly.

Reading the production logs showed that the toolkit was not always present in our container. Our build installs packages without running their setup scripts, a sound default for reproducible images, and that setup script was where this package fetched its binary. The steps that used it were written to carry on politely when it was absent, so films still finished, just without that final polish.

We now install ffmpeg directly in the image, and every call goes through one resolver that always finds a working binary. The mastering pass runs on every voice, and every clip is converted to smooth, constant-rate video. A missing tool can no longer go unnoticed.

With the toolkit in place, one test render reported something odd: a clip that claimed to last about 17 minutes, in a film well under two. That impossible number explained everything.

A browser recording runs for the whole life of the browser session. It holds the blank page, the load, a quick warm-up scroll that wakes lazy-loaded sections, and only then the calm, scripted action. Those recordings also contain gaps in their timestamps, and a simple conversion fills each gap with repeated frames, so a short recording can come out minutes long.

It also answered the original notes. Scenes played their clips from the first frame, so viewers were watching our fast preparation scroll, not the action we had planned. No speed setting could have fixed that.

The fix is to keep only the end of each recording, the window that holds the scripted action. We made that trim exact, in two passes:

1. 1Repackage the recording into a format with a real seek index. It takes milliseconds and changes no pixels.
2. 2Measure its true length, start at the end minus the action window, and cut with a hard length limit, so the result can never grow longer than the action, whatever the timestamps claim.

The recorder also timestamps the action while it films, so the trim follows the measured moment rather than a fixed guess. Every clip now starts on the first frame of what the voice is talking about and ends with it.

We wanted a clip's length to be something the film can always rely on, so we added two independent guards, one in each place that cares:

• In the recorder, every clip carries a length. If measuring fails, it takes the known limit of the trim, and any measurement is held within that limit.
• In the composition, a clip with no known length holds on its last safe frame after a short, conservative window.

When a scene's voice outlasts its clip, the picture simply rests on the final frame. We also gave the video engine's frame cache four times more memory and run one render at a time per machine, so every film has the resources it needs from start to finish.

The changes are invisible as code and obvious on screen. The narration is mastered, so it sounds even and unhurried. The scroll is calm, because the scene shows the scripted movement, not the preparation behind it. And every scene starts on its subject.

The lesson we keep from this chapter is simple: a quality note is a clue, not a setting. Taking an odd number seriously led us further than any dial would have. You can see how the recorder films a site on the features page.