Benchmarks

Benchmarks

Status: methodology agreed, numbers not yet measured. This page exists so the measurements land somewhere with their conditions attached, rather than as a number somebody remembers hearing. Anything below without a date and a machine is a plan, not a result.

The question

Not "how fast is ffmpeg". It is: how long after an editor drops a morning's rushes into a project does the last one become reviewable, and how many machines does that take.

Why this got harder to answer, and more worth answering

Onelight now runs in two arrangements, and they do different amounts of work for the same job.

Shared volume. The server and the worker mount the same storage. A job opens the source in place and writes renditions in place. Zero copies.

Object storage. The worker has no volume. It downloads the whole source before it can decode -- ffmpeg wants a seekable file, and a proxy ladder reads the source many times -- and uploads each rendition when it is done.

The second arrangement adds a transfer term the first does not have, and for a large master that term can be larger than the encode. Nothing in CI shows it, because CI fixtures are a few hundred kilobytes. The first number worth having is the ratio of transfer to encode on a realistic source. Above about 1, the serverless story needs a different answer -- range reads instead of whole-file downloads, or workers colocated with the bucket -- and that is a design decision, not a tuning one.

What to measure

Report each of these separately. An aggregate hides which term is the problem, and they have completely different fixes.

1. Fetch, encode, upload as three numbers per job.
2. Realtime factor for the proxy ladder at 1080p and 4K: seconds of processing per second of footage. Hardware and software separately -- nyx does real VAAPI (vaapi:/dev/dri/renderD128:QVBR:low-power), a cloud worker may have nothing, and software 4K AV1 is a different universe.
3. Concurrency scaling. MEDIA_CONCURRENCY defaults to cpus - 2 per worker, and workers pull rather than being assigned, so the question is whether N workers give N times the throughput or whether they contend on disk or network.
4. The delivery case, which is the one that decides usability: not one file but a hundred camera masters arriving at once, measured end to end from upload to last-version-ready.
5. Requests and CPU-ms per review session, which is what Pricing is missing.

Conditions that have to be recorded with every number

A benchmark without these is an anecdote:

• machine, core count, and whether encoding was hardware or software
• source codec, resolution, bitrate, duration
• arrangement: shared volume or object storage
• worker count and MEDIA_CONCURRENCY
• where the bytes travelled: same host, same LAN, or the public internet

Where it will run

The test-bench project from the HDR work is the natural harness: it already synthesizes sources and drives the real pipeline. The integration exercise (scripts/integration-e2e.mjs) already measures a full upload-to-ready cycle and knows how to kill a worker mid-encode, so the timing hooks belong there rather than in a new script that would drift from it.

Results

None yet. Each entry will carry its date, its machine, and the conditions above.