Skip to main content

How Remotion Lambda works

This document describes the procedure that gets executed when a Remotion Lambda video render is triggered.


This document explains the Lambda architecture from version 4.0.165 on.
Previously, Lambda functions did not use Response Streaming, and instead saved chunks to S3.

A single Lambda function is invoked using renderMediaOnLambda() - either directly or via the CLI which also calls this API. This invocation is called the main function.
The main function visits the Serve URL that it is being passed in a headless browser.
The main function finds the composition based on the composition ID that was passed and runs the props resolution algorithm to determine the props that should be passed to the video as well as the metadata (such as the duration in frames).
Based on the determined duration of the video and the concurrency, several renderer functions are spawned, which are tasked to render a portion of the video.
The renderer functions use AWS Lambda Response Streaming to report progress as well as the binary video chunks.
The main function concatenates the progress reports into a concise progress.json file and periodically uploads it to S3.
The getRenderProgress() API queries the S3 bucket for the progress.json file and returns the progress of the render.
As soon as all chunks have arrived in the main function, they get seamlessly concatenated. The concatenation algorithm is not a public API at the moment.
The main function uploads the final video to S3 and shuts down.


Can I roll my own distributed renderer?

The seamless concatenation of chunks is not a public API at the moment.
You may render chunks using frameRange and audioCodec: "pcm-16" which you can concatenate using FFmpeg.

Building a distributed renderer is hard, and not recommended for most.

Will each chunk download all assets?

Each chunk will download all assets that are referenced in this chunk.
This can lead to assets being downloaded many times at the same time, which may overwhelm a server or trigger rate limits.
In addition, you pay for the bandwidth, even if the assets are on S31).

Keep this in mind when designing your solution and consider using a CDN to serve assets.

1) An API for avoiding the S3 bandwidth charge is planned.