The video encoding API that learns from your viewers

Video encoding is compressing a source video with a codec so it can be streamed over the internet. The encoder decides how much picture detail to give up (the bitrate), which resolutions to produce, and which encoder feature set to use (the codec profile) so the file plays on the devices your viewers own. For streaming it does this several times at different quality levels, and that set of levels is the bitrate ladder.

On FastPix none of those choices are yours to make. You send a file, FastPix profiles it and builds a ladder for that one video, and you get back a playback URL that plays everywhere.

A video encoding API turns a source file or a live stream into adaptive-bitrate renditions ready for playback. You send one HTTP request containing a source URL. The service handles compression, builds the bitrate ladder, packages the segments and returns a playback URL you can drop into any player. Nothing runs on your infrastructure and there is no encoder to keep alive.

The FastPix API profiles each source, builds a ladder that fits it, and emits AV1, HEVC and H.264 packaged in CMAF. It is a server-side API — not the browser VideoEncoder in WebCodecs, which encodes frames inside a single user's tab. See the five-minute quick-start.

A cloud video encoding service takes your source files and returns streaming-ready renditions, without you running encoders. You send a file or a URL over an API. The service handles compression, the bitrate ladder, packaging and delivery, and hands back a playback URL. There is no encoder fleet to patch, scale or get paged about.

FastPix is a video encoding service built for developers rather than an application you log into. Encoding is free on Standard quality, and you are billed per source minute.

Encoding compresses raw video into a codec. Transcoding decodes video that is already compressed, then re-encodes it. A camera producing an H.264 file from its sensor is encoding. Taking that H.264 file and producing five smaller renditions from it is transcoding, because the source has to be decoded first.

Almost every file uploaded to a video platform is already compressed, so what actually runs is transcoding. Most vendors, FastPix included, say "encoding" because that is the word buyers search for. A third term, transmuxing, rewraps video into a different container without touching the picture at all. Encoding vs transcoding.

An encoder reads the source and throws away detail the eye is least likely to miss. It looks for redundancy in two directions. Within a frame, large areas of similar colour are described once rather than pixel by pixel. Across frames, only what changed between one picture and the next is stored. A codec such as H.264, HEVC or AV1 defines how that gets written down.

For streaming the encoder does this several times at different resolutions and bitrates, producing a ladder. The player requests short segments and moves up or down the rungs as the connection changes, which is what adaptive bitrate streaming means.

On FastPix a 10-minute 1080p source is ready to play in 35 to 90 seconds. Three things move that number: how long the source is, how complex the picture is, and how many rungs the ladder ends up with. Per-title encoding adds a profiling pass before it picks the ladder, which is more work than a fixed preset, and still finishes faster in practice.

Method and raw runs: the benchmark.

Just-in-time encoding returns a playback URL before every rendition has finished encoding. A traditional pipeline bakes the whole ladder first and only then hands you something playable, so your publish time is set by the slowest rung. Just-in-time flips that: the first rungs go live and the rest land underneath the viewer while they are already watching.

Just-in-time packaging is a related but different thing. It rewraps renditions that already exist into whatever container the requesting player wants, rather than producing new ones. FastPix packages CMAF on the way out.

Per-title encoding builds a bitrate ladder for each video instead of reusing one across the catalog. Netflix introduced the technique in 2015. The problem it solves is that a single ladder is wrong for almost every video it touches. A static interview and a fast-cut trailer need very different bitrates to look equally good, so one preset either wastes bits on the simple content or starves the complex content.

FastPix profiles each source, picks the rungs that fit it, and scores the result with VMAF rather than aiming at a fixed bitrate. Against open-source H.264, HEVC and AV1 baselines that produces the same picture in 35% fewer bytes. Glossary.

FastPix accepts H.264, HEVC, AV1 and VP9 as sources, and emits AV1, HEVC and H.264 in CMAF. Which codec a given viewer receives depends on what their player and device can decode. A recent Chrome build may get AV1 while an older smart TV falls back to H.264, from the same asset and the same API call. You do not configure that per device.

Your rate is identical either way. Codec does not appear anywhere in FastPix pricing, so moving traffic to a more efficient codec lowers your delivery bill rather than raising your encoding one.

AV1 generally delivers the same picture at a lower bitrate than HEVC. The trade is decode support and licensing. AV1 is royalty-free and well supported in modern browsers and newer mobile hardware. HEVC has wider hardware decode coverage across older devices and smart TVs, and carries patent licensing that AV1 does not.

Which is why FastPix emits both rather than making you choose. The ladder decides per surface, so a viewer with AV1 decode gets the smaller file and everyone else still gets a clean stream. AV1 vs H.264 vs H.265.

On FastPix you do not set one. Per-title encoding allocates bitrate per rung based on what the content needs. If you are sizing a pipeline yourself, the figures below are the range most 30fps content lands in. Complex content sits at the top of each range and simple content well below it.

HEVC and AV1 reach the same visual quality lower in each range. Ranges are indicative, not a spec: the only reliable answer is a quality score on your own content.

Every lossy encode discards information, so the real question is whether a viewer can see it. Bitrate alone answers that badly. Two files at the same bitrate can look completely different depending on the content, which is why FastPix targets a quality score rather than a number of bits. VMAF models what people actually perceive, scored against the original.

Re-encoding an already-compressed file always loses a little more, so quality never comes back by encoding again at a higher bitrate. Encode from the highest-quality master you have.

Resolution and quality tier affect the price. Codec, rung count and encoding passes do not. You are billed per source minute. A 40-minute episode is 40 minutes whether the ladder has four rungs or twelve, and whether it goes out as H.264 or AV1.

That is the structural difference with AWS. MediaConvert bills each rung separately, weighted by resolution, frame rate and pass count, so the same 40-minute episode arrives as 629 normalized minutes. Why AWS bills 629 minutes for 40.

Running FFmpeg yourself is workable, and for a small predictable catalog it can be the right call. It stops being cheap at the point where you need queueing, retries, GPU capacity planning, per-content ladder tuning, packaging, a CDN contract and someone on call. That is a standing engineering commitment, not a one-off build.

The part no single catalog can reproduce is a ladder-tuning feedback loop built on playback data from millions of streams a day. Your own telemetry only ever describes your own audience. FFmpeg alternatives.

Viewer Experience monitoring tracks errors, rebuffering, startup time and picture quality across production playback. Those are real sessions on real devices and real networks, not lab conditions. They show both ways a ladder fails: too fat and viewers on weak connections stall or burn through a data plan, too thin and the picture goes soft.

Machine learning feeds those signals back into how ladders get built, so the encoder that runs your next upload is not the one that ran your last. You do not opt in or configure anything. See FastPix Video Data.

Yes. Live ingest accepts RTMP, RTMPS and SRT, and outputs low-latency LL-HLS with adaptive bitrate. Point any standard encoder at a single ingest URL. FastPix transcodes, packages and delivers over a multi-CDN, and backup stream keys are included.

Live-to-VOD runs automatically, so the replay is archived and gets the same per-title treatment as a direct upload. Live encoding bills at one flat rate across 720p, 1080p, 2K and 4K. Live Streaming API.

Point your existing source URLs at one FastPix endpoint. The job definitions, output group config, packager settings and preset files all go away, because the ladder is decided per file rather than declared up front. Most teams run both pipelines side by side on a slice of the catalog first, compare quality scores and time-to-playable, then cut over.

Existing playback URLs keep working while you migrate, so there is no flag day and no re-encode of the back catalog before you can start. See FastPix vs AWS Elemental and the docs.