HyperFrames: Solving Deterministic HTML-to-Video Rendering

Converting HTML into reproducible video sounds simple until asynchronous rendering breaks everything. HyperFrames solves the problem HeyGen faced in production: dropped frames, race conditions, and font-loading chaos. The framework enforces determinism through strict constraints that turn browser unpredictability into reliable output.

Featured Repository Screenshot

You want to render HTML as video. You grab a headless browser, point it at your markup, and start capturing frames. For the first test file—static text, a single web font—it works. Then you try something dynamic: a timestamp, a loading spinner, an animated chart. Suddenly the same input produces different outputs. Fonts appear two frames later on one render than another. A Date.now() call makes every export unique. The preview looks perfect, but the final video drops frames.

Browser rendering is asynchronous by design, and that design assumption breaks when you need pixel-perfect reproducibility. HyperFrames is HeyGen's answer to that problem—a framework that trades browser flexibility for determinism, built because their production video pipeline demanded it.

The deceptive simplicity of HTML-to-video

The pitch sounds reasonable: HTML, CSS, and JavaScript already describe visual layouts and animations. Browsers already render them at 60fps. Capturing that rendering as video should be a matter of wiring up the right APIs. But browsers optimize for interactivity, not reproducibility. They load assets asynchronously, resolve fonts when they arrive, and execute JavaScript whenever the event loop allows. None of that matters when you're scrolling a webpage. All of it matters when you're trying to export frame 247 of a 10-second animation and get identical output every time.

A Hacker News thread illustrates how common this pain point is—developers describing their own HTML5 Canvas-to-MP4 pipelines, each one wrestling with the same core challenge: making the browser behave predictably.

Where the problems start

Dropped frames happen when the browser hasn't finished compositing before your capture tool grabs the next frame. Race conditions appear when one render loads a webfont in 40ms and another takes 120ms, shifting every element that follows. Preview-versus-render drift occurs because your live preview runs in a normal browser environment with network access and system time, but your headless export runs in a different context. A Math.random() call that looks fine during preview generates different values during export.

These aren't edge cases. They're what happens when you use a tool designed for one purpose (interactive web browsing) to solve a different problem (reproducible video generation).

Enforcing determinism through constraints

HyperFrames solves this by eliminating nondeterminism at the framework level: no Date.now(), no unseeded Math.random(), no network fetches during rendering. Authors work within a constrained runtime where every call to a random number generator uses a seeded PRNG, where time is a fixed input rather than a system query, and where all assets must be loaded before the render loop begins.

These aren't arbitrary limitations—they're the minimal set of constraints needed to make browser rendering reproducible. You can still build complex animations, dynamic layouts, and data-driven visuals. You just can't rely on side effects that vary between runs. The tradeoff is explicit: accept these rules, and HyperFrames guarantees that the same input will produce the same output every time.

Production lineage and adoption

This didn't start as an experiment. HeyGen uses HyperFrames in production, and the framework reflects the constraints they needed to ship reliable video at scale. The repository has gained attention from other teams hitting the same problems. Adopters include tldraw and TanStack, plus a desktop application for 2D cartoon shows that renders exports through HyperFrames.

With 49 open issues and 111 pull requests, the project is actively working through the kind of feedback you'd expect from a tool addressing a real production need. The core problem it addresses isn't speculative. If you've tried to turn dynamic web content into reliable video, you've already encountered the race conditions and nondeterminism HyperFrames was built to eliminate.

Who should care about this

If you're building video rendering pipelines, systems where agents generate visual content, or programmatic animation tools, HyperFrames solves a problem you've either already faced or will face soon. The constraints feel restrictive until you consider the alternative: a rendering system that works 95% of the time and fails unpredictably for reasons you can't reproduce. HeyGen needed determinism badly enough to open-source the framework that gave it to them.


heygen-comHE

heygen-com/hyperframes

Write HTML. Render video. Built for agents.

56.8kstars
5.1kforks
ai
animation
ffmpeg
framework
gsap