Chapter 6 of 7

The same frames on every machine

Scaling AI Video Production · 3 min read

What is deterministic video rendering?

Deterministic video rendering means the same description of a video gives the same frames, bit for bit, every time and on every machine. Everyframe's motion renderer is built for it, and it draws on the processor, with no web browser and no graphics card. Each release is checked against stored fingerprints of 195 test cases, and the same frames come out on Intel servers and on Apple laptops.

The same core also runs in a browser tab as WebAssembly, the format browsers use to run compiled code. A preview in the tab gives the bytes a server would, as long as both processors are of the same class.

Everyframe's own demo clips show the same property from the outside. When the engine was rebuilt on 28 October, the 36 clips Everyframe already showed were made again on the same laptop, and every file came out byte for byte the same as before.

How fast is it next to a browser-based renderer?

Popular tools for programmatic video rendering, such as Remotion and HyperFrames, capture each frame from a Chrome browser. We compared ours with HyperFrames, an open-source renderer from HeyGen. It describes a video as a web page, opens it in a Chrome browser with no window, captures each frame and encodes the frames with FFmpeg. HeyGen added it to its Video Agent in July 2026.

Both ran on one server, on the processor only, with the same FFmpeg and the same encoder settings. We rendered three test videos at 1080p and 4K. Two are text and shapes, and one is mostly images.

The two tools' videos matched closely, with a median SSIM between 0.9992 and 0.99999. SSIM is a standard score for how alike two images look, and 1 means identical.

Launch to the first frame on disk, 1080p, one rendering process, nothing loaded beforehand, fastest of three runs.

VideoHyperFramesOur renderer
hello (3 s)1.57 s0.024 s
storm (8 s)1.96 s0.046 s
cards (12 s)2.80 s0.061 s

Start-up matters most to an agent, because an agent looks at its work many times. It checks a still for the layout, watches a short preview, then renders the final cut. Each look pays the start-up again.

Twenty looks add 30 to 55 seconds on HyperFrames and about one second on our renderer. Keeping a browser open between jobs would save only the launch, about 0.3 seconds. Building the web page takes longer, and it happens again every time the animation changes.

From launch to a finished MP4, our renderer was 2.3 to 8.3 times faster when each tool ran as many rendering processes side by side as suited it best, and 1.4 to 3.5 times faster with one process each. On a batch of 40 product videos it was 2.5 times faster.

The test has limits. It used one server that other jobs shared, so we report the fastest of three runs on each side. HyperFrames on a graphics card was not measured, and the HyperFrames pages were generated from our own descriptions, so someone writing them by hand might make them faster. We plan to repeat the test on an idle server and publish the scenes, the scripts and the results.

Next · Chapter 7 of 7

Where it runs and where it works

2 min read →

6 / 7 The same frames on every machine Chapters

Stay in the loop

Don't miss the next one.

One email when we publish something worth your time.

No spam. Unsubscribe in one click.