Skip to main content
The RenderOrchestrator class enables distributed rendering by splitting a composition into chunks that can be rendered in parallel across multiple workers.

Overview

Distributed rendering is ideal for:
  • Long compositions that would take too long to render sequentially
  • Cloud rendering on serverless platforms (AWS Lambda, Google Cloud Run)
  • Multi-core local rendering to maximize CPU/GPU utilization
  • CI/CD pipelines that need fast video generation

Basic usage

Configuration

The DistributedRenderOptions interface extends RendererOptions with distributed rendering options:
number
Number of chunks to split the job into. Defaults to Math.max(1, os.cpus().length - 1).
RenderExecutor
Custom executor for rendering chunks. Defaults to LocalExecutor which runs chunks as local processes.
All options from RendererOptions are also supported. See local rendering for the full list.

Distributed rendering workflow

1

Create render plan

The orchestrator analyzes the composition and creates a RenderPlan:
The plan contains:
  • Array of RenderChunk objects defining each chunk’s frame range
  • Temporary file paths for chunk outputs
  • Configuration for concatenation and final mixing
2

Render chunks in parallel

Each chunk is rendered independently with its own frame range:
Workers report individual progress which is aggregated into global progress.
3

Concatenate chunks

After all chunks complete, they are concatenated using FFmpeg’s concat demuxer:
This performs stream copy (no re-encoding) for maximum speed.
4

Mix final audio

The concatenated video is mixed with explicit audio tracks:
FFmpeg processes the audio tracks with filters for volume, fades, delays, etc.
5

Clean up temporary files

All chunk files and intermediate outputs are deleted:

Render plan structure

The RenderPlan interface defines the execution plan:

Render chunk

Each chunk is defined by:

Local parallel rendering

By default, the orchestrator uses LocalExecutor to render chunks on the local machine:

Progress tracking

The orchestrator aggregates progress from all workers:
Progress calculation:

Error handling

If any worker fails, all other workers are immediately aborted:

Custom executors

Implement the RenderExecutor interface to create custom execution strategies:

Example: Cloud executor

Audio handling in distributed mode

Distributed rendering uses a two-phase audio approach:

Phase 1: Chunk rendering

Chunks capture implicit audio (from DOM audio elements) using PCM:
This ensures:
  • No audio re-encoding during chunk rendering
  • Implicit audio is preserved for concatenation
  • Deterministic audio synchronization

Phase 2: Final mixing

After concatenation, explicit audio tracks are mixed:
The orchestrator detects implicit audio:

Performance considerations

Optimal concurrency

For CPU-bound workloads (software encoding):
For GPU-bound workloads (hardware encoding):
For cloud rendering:

Chunk size

Avoid chunks that are too small:
Small chunks have overhead:
  • Browser startup time
  • FFmpeg initialization
  • File I/O operations

Memory usage

Each worker runs a full browser instance:
Limit concurrency on memory-constrained systems:

Example: Full distributed workflow

Stateless rendering requirements

For cloud/distributed rendering, compositions must be stateless:
Each chunk renders independently without access to previous frames. Your composition must support deterministic frame seeking.

Requirements

  1. Deterministic time-based rendering
  2. No reliance on playback history
  3. Bind to document timeline
See the distributed rendering example for a complete stateless composition.