There are two ways in. Give Acme a URL it can reach and it pulls the file itself, retrying transient failures on its own. Or request a direct upload URL and send bytes to it, resumably, without the file passing through your servers.

Before anything is encoded, the source is inspected: container, video and audio streams, duration, frame rate, colour information. This is where most bad inputs are caught — a file with a video extension and no video stream, a truncated upload, a codec we can’t decode. Catching it here means the asset fails in seconds with a specific reason, instead of failing expensively in the middle of encoding or, worse, producing a technically valid asset that plays as a black screen.

A rendition ladder is the set of qualities a viewer can switch between. Most of the cost and most of the playback experience is decided here.

Acme reads the source and builds a ladder that fits it. A 240-minute lecture recorded at 720p and a two-minute highlight shot at 4K get different ladders, because they have different useful qualities and different viewers.

Two rules hold in every case. We don’t upscale: if the source is 720p, no 1080p rendition is produced, because it would cost you delivery bandwidth and give the viewer nothing that wasn’t already there. And screen recordings are treated differently from camera footage: a slide with 10pt text falls apart under settings that look perfectly fine on a face, so encoding decisions account for what the frame contains.

Audio is normalised and encoded once, separately from video, so switching quality mid-playback doesn’t interrupt sound. Thumbnails and a scrubbing preview strip are generated in the same pass — they’re needed by almost every interface, and asking you to make a second pipeline for them would be strange.

The master is the file as you gave it to us. The renditions are what viewers actually receive. They’re stored separately and priced separately, because they have different lifetimes.

Keep the master and you can re-encode later — a new rendition for a device that didn’t exist when the video was uploaded, a different ladder when your audience changes. Drop it and you keep playback while paying for less storage. Which of those is right depends on your catalogue, and it’s your decision to make per asset, not a platform default you have to live with.

HLS splits a rendition into short segments and describes them in a manifest. The player reads the manifest, requests segments one at a time, and can change its mind about quality between any two of them.

Segments are served from delivery nodes. A node that doesn’t have a requested segment fetches it once from a shielding layer in front of storage, then keeps it — so the first viewer of a video in a region pays a small latency cost and everyone after them doesn’t. Storage is never hit by viewer traffic directly.

Adaptive bitrate is a negotiation, and the player is the only participant with real information. It measures how fast segments are arriving and how full its buffer is, then picks the highest rendition it can sustain. When a train enters a tunnel, it steps down. When the connection recovers, it steps back up.

That means playback quality is decided by two things: the network the viewer has, and the ladder we built. We can’t affect the first one, which is exactly why the second one gets the attention it does.

Acme ships a player as a web component with the states you’d otherwise implement yourself — loading, buffering, recoverable error, unrecoverable error, expired link. You’re not required to use it. The manifest is standard, and any player that speaks HLS will work.

Events are signed with your endpoint secret; verify the signature before trusting the body. Delivery is retried with backoff if your endpoint doesn’t respond with success, so your handler needs to be idempotent — the same event can arrive twice, and events for the same asset can arrive out of order under retry. Every event carries the asset’s current state, so a handler that reads state from the payload rather than inferring it from event order will be correct in every case.

If your endpoint is unreachable for long enough, events stop being retried and are kept for you to fetch when you come back. Nothing is silently dropped.

If our API is degraded, you can’t create new assets and you won’t get webhooks. Playback of everything that already exists continues, because manifests and segments are served by the delivery layer and never require the control plane to answer a question.

A worker that dies mid-encode doesn’t take the job with it. The asset returns to the queue and is picked up elsewhere; retries are bounded, and when they’re exhausted the asset ends in a terminal state with a reason. What never happens is an asset sitting in encoding forever — every job has a deadline, and hitting it is itself a reportable outcome.

Retried work isn’t billed twice. You pay for the source you submitted, not for our attempts at it.

Delivery absorbs spikes without notice: that’s what the node layer is for, and a popular video is the easy case, since every viewer after the first is served from cache.

Encoding is the part with a real queue. A sudden bulk import competes with everyone else’s work, so during the beta capacity is allocated per team and large migrations are scheduled rather than discovered. If your product has a predictable weekly peak, tell us in the first conversation and it stops being a surprise for both sides.

An asset can be openly playable, or require a signed token. A token is produced by you, from a key only you hold, and carries an expiry — and optionally a restriction to a viewer, a session, or an origin. Acme validates it at the delivery layer, which means an expired or altered link fails at the node, before any bytes leave.

Short expiries are the ordinary case rather than the strict one. A link that lives for minutes and is issued per view is much less interesting to copy, and it turns “someone shared the URL” from a breach into a nuisance.

Revoking a playback ID stops future manifest requests immediately. Segments already cached by a viewer’s own player remain in that player until they’re evicted — no delivery system can reach into a browser’s cache, and any vendor telling you otherwise is describing something they can’t do.

Traffic is encrypted in transit and stored objects are encrypted at rest, with keys we manage and rotate. The mechanics are described to your reviewer in full rather than summarised into a sentence here, because a sentence about key management is worth very little to the person whose job is to check it.

Accounts are isolated from each other, and a sandbox account is a different account rather than a flag on yours. Playback IDs are long random identifiers rather than sequential ones, so there is no neighbouring asset to arrive at by adding one — and enumeration attempts are rate-limited at the delivery layer regardless.

Deleting an asset removes the master and the renditions, invalidates its playback IDs, and purges the segments from delivery nodes. Backups age out on a stated schedule, and we tell you what that schedule is rather than describing it as “a reasonable period”.

You can set a retention rule per account so that assets are removed on their own after a period you choose — which is usually what teams with regulatory obligations actually need, instead of remembering to call delete.

Nobody, in the ordinary case. Support can see an asset’s technical record — its state, its ladder, its error — without being able to play it, because those are different permissions and reading the record is what answers almost every question.

Investigating a specific failure sometimes requires more. When it does, the access is requested against a named asset, granted for a limited period, and written to a log you can ask to see. We would rather tell you that this path exists than describe an access model that nobody could operate.

A data processing agreement, answers to your questionnaire in your own format, the categories of subprocessor we rely on and the current list, the retention and deletion policy, and the incident notification procedure with the timelines written into it.

What you won’t find here is a row of certification badges. During a closed beta, claiming an audit we haven’t completed would be the one thing on this page you couldn’t verify — so the honest version is this: ask what you need, and you’ll get either the document or a straight answer about when it exists.

Write to us and a person answers — not a form, and not a legal notice. Good-faith research is welcome and we won’t pursue anyone for it.

One request: don’t test against another team’s assets. The sandbox exists for exactly this, and if you don’t have one, ask and we’ll open one for the purpose.

This is the case the per-asset master decision exists for. Keeping every original for a catalogue where half the material is never opened again is the most common way a learning platform’s bill stops matching its usage. Dropping the master keeps playback and stops paying for the part nobody re-encodes.

It also drives how the ladder is built: a recorded lecture is a screen capture with 10pt text in it, and encoding decisions that look fine on a face fall apart on a slide.

Everything on the data and security page exists because of this shape of customer: the region chosen per account, tokens that expire in minutes rather than days, retention rules that remove assets without anyone remembering to call delete, and an honest sentence about what a delivery network can and cannot purge from a viewer’s own browser.

The part that isn’t technical matters as much. A reviewer’s questionnaire arriving before the first call is a good sign, not an obstacle.

Encoding is the stage with a real queue, and this is the product shape that finds its edge. A load that arrives as a comb rather than a curve is a scheduling problem before it is a capacity one, which is why beta capacity is allocated per team and a predictable weekly peak is something to say out loud in the first conversation.

Sources here are almost always screen capture, so the encode-side rule about screen recordings is doing most of the work you’d notice.

A popular clip is the easy case for delivery: the first viewer in a region pays a small latency cost and every viewer after them is served from the node. The hard case is the first few seconds — a ladder whose bottom rung is genuinely usable matters more here than a wide top, because the player’s first choice is made with almost no information.

Every few years a capability stops being a project and becomes a line item. Payments did it. Search did it. Video is doing it now: a support tool records sessions, a training product ships a course, a clinical system keeps a consultation — and not one of those teams set out to operate an encoder.

What’s available to them is usually one of two things. A set of primitives — object storage, a transcoding service, a delivery network — that someone has to wire together and then own for as long as the product lives. Or a platform designed for media companies, priced and shaped around a business whose product is the video itself.

Most products sit between those two, and that gap is where we work. It’s not a glamorous position. Infrastructure is noticed on its worst day and invisible on every other one, and we’d like to keep the ratio that way round.

More control over the ladder for teams whose sources are unusual — long-form screen capture and high-motion footage pull in opposite directions, and today we choose for you more often than we’d like.

Finer placement of storage and processing, because “which region” turns out to be a per-asset question in more products than we expected.

Playback analytics that answer product questions rather than infrastructure ones: not only how playback performed, but whether people watched.

And live, eventually, as its own system rather than a checkbox on this one — not before the file pipeline is something we’d stake the company on.

Beta teams get direct access to the people building this, and a real say in what gets built next. In exchange we ask for two things: tell us when something is worse than what you had before, and let us look at real failures in your account when they happen.

That’s the whole exchange, and it’s the reason the beta is small. It doesn’t scale, and at this stage it isn’t supposed to.