Skip to content

Benchmarks

Jump to bottom
David Torcivia edited this page Aug 3, 2026 · 7 revisions

Benchmarks

No measurements yet. This page records what to measure and what conditions to record with each result.

Two arrangements do different work

Shared volume. Server and worker mount the same storage. A job opens the source in place and writes renditions in place. No copies.

Object storage. The worker has no volume. It downloads the whole source before decoding, because ffmpeg wants a seekable file and a proxy ladder reads the source repeatedly, then uploads each rendition.

The second adds a transfer term the first does not have. On a large master that term may exceed the encode. CI cannot show this because fixtures are a few hundred KB.

First measurement: the ratio of transfer to encode on a realistic source. Above about 1, the fix is a design change rather than tuning, and it is the same change Cloudflare Containers require (Encoding).

What to measure

Report separately. Aggregates hide which term is the problem, and the terms have different fixes.

  1. Fetch, encode and upload as three numbers per job.
  2. Realtime factor for the proxy ladder at 1080p and 4K: processing seconds per second of footage. Hardware and software separately.
  3. Concurrency scaling. MEDIA_CONCURRENCY defaults to cpus - 2 per worker, and workers pull rather than being assigned, so measure whether N workers give N times throughput or contend on disk or network.
  4. A delivery: a hundred masters arriving at once, measured from upload to last version ready. This is the number that decides usability.
  5. Requests and CPU-ms per review session, which Pricing needs.

Conditions to record with every result

  • machine, core count, hardware or software encoding
  • source codec, resolution, bitrate, duration
  • arrangement: shared volume or object storage
  • worker count and MEDIA_CONCURRENCY
  • network path: same host, LAN, or public internet

Harness

scripts/integration-e2e.mjs already drives a full upload-to-ready cycle and can kill a worker mid-encode. Timing hooks belong there rather than in a new script that would drift from it.

Results

x264 preset for software proxies, 2026-08-03

30 s of 1920x1080 at 25 fps, synthetic (testsrc2), 3 vCPU in the worker image, encoded with the settings proxies actually use: CRF 23, -g 24, -keyint_min 24, -sc_threshold 0, audio stream-copied.

preset time realtime factor output
medium (current default) 23.7 s 1.3x 19.5 MB
fast 22.9 s 1.3x 19.6 MB
faster 18.0 s 1.7x 19.1 MB
veryfast 10.4 s 2.9x 17.3 MB
superfast 9.5 s 3.1x 33.7 MB

veryfast is 2.3x faster than medium on the same hardware. superfast buys another 9% for double the bytes, so veryfast is the knee.

Caveat on the sizes: synthetic content compresses unlike real footage, and here veryfast came out smaller than medium, which will not generalise. On real material expect veryfast to be somewhat larger at the same CRF. The timing ratio is the durable result; the size column needs redoing on a real master.

What this implies for long sources: at medium a one-hour 1080p master is roughly 46 minutes of encoding on 3 cores, and about 20 at veryfast. 4K is several times worse again. Software-only encoding of long masters is slow enough that parallelism across workers matters more than any preset choice.

Clone this wiki locally