The Three-Renderer Rule: Unified Video Pipelines from Preview to Export

If you have ever built a programmatic video pipeline, you know the "Preview Paradox." You spend hours perfecting a motion sequence in a web preview, only to find that the final MP4 export rendered on a server looks... different. Maybe a font didn't load, a GLSL effect glitched, or a blend mode calculated alpha incorrectly.

Inconsistent video rendering architecture is the silent killer of video automation. When your preview engine and your export engine are two different codebases, you aren't building a product; you're building a translation layer that will inevitably fail.

At VideoFlow, we solved this by enforcing the Three-Renderer Rule: one source of truth (VideoJSON) rendered by three specialized but pixel-identical engines. Whether you are scrubbing a timeline at 60 FPS or batch-rendering 10,000 personalized videos in a headless cloud worker, the pixels do not lie.

The Source of Truth: VideoJSON

Before we look at the renderers, we have to talk about the data. Most video-as-code tools couple the description of the video to the logic of the renderer. Remotion, for example, uses React component trees. This is powerful but tethers your video to a React runtime.

VideoFlow treats VideoJSON as the universal exchange format. It is a portable, resolution-agnostic schema that describes every layer, transition, and keyframe. Because it is pure data, it can be stored in a database, diffed in Git, or emitted by an LLM agent.

Renderer 1: The DOM (Live Preview)

Development starts with @videoflow/renderer-dom. This engine is designed for the Playground and in-app editors. It renders layers as native DOM elements—text as HTML, media as <video> or <canvas>, and shapes as SVG—all encapsulated within a Shadow DOM for style isolation.

It achieves frame-accurate seeking and 60 FPS playback by syncing a high-performance requestAnimationFrame loop with an OfflineAudioContext. When you change a property in your code, the DOM renderer performs an incremental update, re-rendering only the affected frame without a full reload.

Renderer 2: The Browser (Zero-Cost Export)

When a user hits "Export" in your web app, you shouldn't have to spin up a $50/month server to render an MP4. @videoflow/renderer-browser handles the heavy lifting entirely on the client side.

Using the modern WebCodecs API, this renderer rasterizes frames and encodes them into a H.264 bitstream directly in the browser tab. To keep the UI responsive, we offload the encoding and muxing to a Web Worker. This allows for high-quality MP4 exports with zero server overhead and total data privacy.

Renderer 3: The Server (Headless Automation)

For batch jobs and background processing, @videoflow/renderer-server takes the stage. It runs in Node.js and drives a headless Chromium instance via Playwright.

This is the secret sauce of the Three-Renderer Rule. Because the server renderer uses a real browser engine, it reuses the exact same rasterization logic as the browser and DOM renderers. It doesn't try to "simulate" a browser; it is a browser.

By default, it uses the same WebCodecs-based pipeline as the browser renderer, meaning you don't even need to install FFmpeg on your server to generate MP4s. However, if you need custom x264 flags or specialized containers, you can opt into a per-frame FFmpeg pipeline:

import VideoFlow from '@videoflow/core';
import '@videoflow/renderer-server'; 

const $ = new VideoFlow({ width: 1920, height: 1080 });
$.addText({ text: 'Automated Render', fontSize: 8 });
$.wait('5s');

await $.renderVideo({
  outputType: 'file',
  output: './render.mp4',
  ffmpeg: true, // Optional: use FFmpeg for advanced encoding flags
});

Why This Matters for Developers

By unifying the video rendering architecture, VideoFlow eliminates the most frustrating part of programmatic video: debugging environment-specific glitches.

1. Pixel-for-Pixel Consistency: A blurResolve transition or a bloom GLSL effect will look identical in your local preview and your production export.
2. Flexible Deployment: Start with browser-only exports to save on costs, then move to server-side rendering as your scale grows, without changing a single line of your video logic.
3. Built-in Cinematic Primitives: Because the renderers share a registry of transitions and effects, you get access to 27+ transitions and 42+ GLSL effects out of the box that are guaranteed to work everywhere.

Get Started with VideoFlow

Ready to build a reliable video pipeline? The entire core and all three renderers are open-source under the Apache-2.0 license.

• Explore the Docs to learn about the builder API.
• Try the Playground to see the DOM renderer in action.
• Star the project on GitHub to follow our roadmap.

Stop fighting your renderers and start building with a unified architecture.