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
TheDistributedRenderOptions 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.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 The plan contains:
RenderPlan:- Array of
RenderChunkobjects 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
TheRenderPlan interface defines the execution plan:
Render chunk
Each chunk is defined by:Local parallel rendering
By default, the orchestrator usesLocalExecutor to render chunks on the local machine:
Progress tracking
The orchestrator aggregates progress from all workers:Error handling
If any worker fails, all other workers are immediately aborted:Custom executors
Implement theRenderExecutor 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:- 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:Performance considerations
Optimal concurrency
For CPU-bound workloads (software encoding):Chunk size
Avoid chunks that are too small:- Browser startup time
- FFmpeg initialization
- File I/O operations
Memory usage
Each worker runs a full browser instance:Example: Full distributed workflow
Stateless rendering requirements
For cloud/distributed rendering, compositions must be stateless:Requirements
-
Deterministic time-based rendering
-
No reliance on playback history
-
Bind to document timeline