I wanted a shorter path from a product change to a video worth showing.
The finished film, rendered with HyperFrames. A fictional concept, not a recording of a live agent workflow; no audio.
Watch the 22-second sample film on our showcase page, with MP4 and WebM downloads.
Our agents already work with web interfaces. Asking them to explain a change through HTML, CSS and animation code felt like a reasonable extension of that work. I wanted to keep the composition editable, review changes in Git, and adjust a line of copy without starting another bespoke screen-recording exercise.
That led us to HyperFrames, HeyGen's open-source video-authoring and rendering stack. We used it to make a 22-second film about a fictional event-page concept called AFTER HOURS.
The first demo was technically valid and creatively wrong. Getting from that to the live showcase taught me more than the successful render did.
The frame is an address, not a moment to catch
HyperFrames turns an editable web composition into rendered video through Chromium and FFmpeg. The part that caught my attention during our source review on 21 October was the frame-addressable runtime.
With a screen recording, you're catching the animation as it happens. The machine's timing becomes part of the production process. HyperFrames can ask the composition for a particular frame, capture it, and move to the next one.
That changes how I think about review. If a title enters badly halfway through a clip, I want to inspect that point directly rather than repeatedly playing the whole animation and trying to pause at the right instant. I also want the source change that fixes it to remain visible beside the rest of the work.
The composition has to cooperate. Animation state must support seeking, assets need to stay fixed, and the runtime versions matter. A page that depends on live time or changing network content gives the renderer a moving target. For this kind of workflow, those are authoring decisions to make before rendering.
Why a web canvas was worth trying
The attraction for our OpenClaw agents was a familiar medium. We could describe layout and typography in the same language used for a web page, then add timing and motion.
For a product explainer, that creates some useful possibilities. A copy revision can stay a text revision. A layout change can stay a source diff. A design-token pattern can carry the visual language from a site into a short film, with adjustments for the camera rather than assuming a webpage will automatically read well in motion.
HyperFrames' researched design patterns include a frame.md layer for that translation. Reusable motion components offer another starting point, provided we review the pieces we bring into a composition.
I could see a potential fit for release explainers and branded motion graphics. The practical question was whether we could use that canvas to produce something I would actually want to share. We needed a film to answer it.
The first demo answered the wrong question
We initially got a tiny, technically valid demo. It showed that a rendering path could produce output. It missed the creative outcome I had asked for.
That was a scope problem as much as a design problem. Qualification work had expanded ahead of the visible result. I had to bring the work back to the film itself: make the intended experience clear enough that I could judge it.
The eventual composition shows a rough brief becoming the fictional AFTER HOURS event-page concept. It's synthetic work, so the film can demonstrate the visual idea without borrowing the credibility of a customer deployment. The event and its signup concept belong to the story on screen.
We rendered a silent, 22-second film at 1280 by 720, running at 24 frames per second. The showcase includes a native accessible player and MP4 and WebM downloads. You can watch the actual result and decide whether the motion earns its screen time.
Creative acceptance needed its own place in the process. A renderer can deliver exactly what the composition describes while the composition still fails the brief. I should have made that distinction explicit earlier.
Review the build you intend to release
Once the film was worth showing, we still had to connect the accepted candidate to the deployed page.
Independent review checked the exact candidate. Type checking, focused lint and the full build passed, alongside desktop and mobile-viewport playback checks. We then carried that build through PR 62 and checked the deployed media against the accepted assets by hash.
Those hashes answered a specific question: were the production files the same files we had reviewed? They were.
Playback required a browser. Our first fresh production attempt stopped because the retained browser image was missing. The earlier candidate checks remained useful, but the production playback check was still unfinished. A release checklist gets considerably less reassuring when the tool needed to complete it has disappeared.
We returned with a usable browser fixture and ran the live checks. Chrome at a 1280-pixel desktop viewport and a 375-pixel mobile viewport with reduced motion each played the MP4 through all 22 seconds, decoding 528 frames. Native controls worked, the player started paused, and the checks found no page errors or horizontal overflow.
The desktop run dropped five frames; the mobile-viewport run dropped two. Both completed playback. That gives us a concrete production result for those Chrome conditions. Physical-device and Safari behaviour sit outside those runs.
The release record now holds both the accepted media identity and the fresh playback result. I want those proofs together because either one alone leaves an obvious question unanswered.
What I would change in the next brief
I'd put the first visible output and its creative acceptance criteria ahead of ancillary qualification work. We spent effort proving a path before we had a result that met the brief.
I'd also retain or preflight the browser fixture before deployment. Losing it didn't change the film, but it interrupted the final evidence needed to call delivery complete.
There is a broader operating consideration with a browser-based renderer: compositions execute code. Local rendering still needs deliberate choices about assets and runtime access. The short film gave us a bounded result to inspect while the wider renderer qualification remains separate work.
For now, the useful outcome is on the page: an editable composition became a reviewed film, and the accepted film played from production under the conditions we checked.
I'll use HyperFrames at the next suitable opportunity in our real work and gauge the experience there. A product change that needs explaining will give it a better test than another exercise invented to make the tool look good.