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.
| Video | HyperFrames | Our renderer |
|---|---|---|
| hello (3 s) | 1.57 s | 0.024 s |
| storm (8 s) | 1.96 s | 0.046 s |
| cards (12 s) | 2.80 s | 0.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 →
More in this vein
Our Claude Code Workflow: How We Ship Software
Our Claude Code workflow rests on plans kept in git, rules the agent reads first, a typed stack that rejects mistakes and in-house tools that feed each other.
14 min read · Toni
Type-Safe HTML in TypeScript: Wrong Markup Won't Compile
Type-safe HTML in TypeScript turns a misspelled route, a wrong HTMX target or an impossible view state into a compile error. This is how fluent-html does it.
10 min read · Toni
Olimpijski Kviz: a live TV quiz without WebSockets
Olimpijski Kviz, a live TV quiz on RTV Slovenija, ran 16 Olympic broadcasts with zero critical errors. Built for 10,000 concurrent players, with no WebSockets.
14 min read · Toni
Stay in the loop
Don't miss the next one.
One email when we publish something worth your time.