There was an error while loading. Please reload this page.
Measure bytes moved when streaming, instead of counting reads Counting invocations overstated it. The poster input-seeks with -ss before -i, so it decodes a short window rather than the file, and other passes do the same. Measured against a counting HTTP server: 5.67x the source, not 8x. A 40 GB master streams in about 227 GB rather than 320. The better result is that a full transcode ran against an HTTP URL and produced every rendition. ffmpeg seeks by Range and does not need the file, so the adaptive-source design works before any of it is written.
Correct the framing on eight source reads Called it a prerequisite for streaming. It is not: R2 egress is free and eight sequential reads cost cents in Class B operations, so the bill is effectively unchanged. What eight reads spend is wall-clock and bandwidth. The measurement still matters, for a different reason: it says a worker with disk should download once and read locally, and only a worker that cannot hold the source should stream. Folding the passes makes the streaming case reasonable and shortens every job either way.
Measure source reads per transcode: eight, not one Counted with a logging wrapper around ffmpeg on a real transcode. Every one of the eight invocations reads the source. Free on a shared volume, where the file is in page cache after the first pass. Not free streamed: a 40 GB master read eight times is 320 GB per job. Folding the passes is therefore a prerequisite for streaming rather than a follow-up, which is the opposite of how it looks.
Preset against quality: the timing holds, the quality numbers do not veryfast is 2.1x faster than medium on a grainy source and 2.3x on a clean one, so the speed ratio is real. SSIM says quality is equal, and that is not usable evidence: medium spent 20% more bits and scored lower, which is what psy-rd, AQ and trellis look like to SSIM. The metric measures the wrong thing across presets. The source is also far grainier than any camera master. So the default stays where it is until this is settled on real footage with VMAF. The lever should ship as a configurable profile instead.
First measurement: x264 preset for software proxies veryfast is 2.3x faster than the medium currently used, at our real proxy settings. superfast gains 9% more for double the size, so veryfast is the knee. Sizes are from synthetic content and will not generalise; the timing ratio will.
Rewrite pricing and benchmarks, add encoding Both pages were overwritten prose. Rewritten as tables and short statements. Adds the Workers free tier, which the rates table had left out, and an Encoding page: Cloudflare Containers can run ffmpeg, cap at 4 vCPU and 20 GB disk with no GPU, and the disk cap blocks the current design because the worker downloads whole sources.
Add pricing and benchmark pages Pricing is derived from Cloudflare's published rates, read 2026-08-03 and linked, with the arithmetic kept simple enough to redo. Everything that is an assumption says so, and the four numbers that need measuring before the request and CPU terms mean anything are listed rather than guessed at. Benchmarks is a methodology with no results yet, on purpose: it says what to measure and which conditions have to be recorded with each number, so the first real run lands somewhere with its context attached.