Five stages between upload and play
A file lands in a bucket and, some minutes later, a player somewhere starts it at a sensible bitrate. In between sit five stages, and most of the confusing behaviour in a managed video pipeline comes from treating them as one box. They have different bottlenecks and they bill on different meters.
Ingest and transcode
Ingest is getting the source in. For on-demand video that means a file in object storage, and a mezzanine is often tens of gigabytes, so uploads are chunked and resumable: the client sends numbered pieces, the server acknowledges each, and after a failure only the missing pieces go again. The usual shape is a signed URL, so the bytes travel from the client straight to the bucket instead of through your own server, and a storage event starts the next stage. Live ingest is a different animal: a contribution feed over RTMPS or SRT that a channel input has to accept in real time.
Transcode decodes the source once and encodes the ladder. This is where the money and the queue are. A managed transcoder bills per minute of output, not per minute of source, so one 10-minute video encoded into four rungs is 40 billable minutes. Underneath, transcoding is a farm of machines. A managed service hides the fleet, and its queueing shows up as concurrency limits and job queues. The lab models a farm you run yourself: it autoscales, and a new machine takes time to boot, so a burst of uploads waits behind a small fleet that is still growing. That wait is not a bug. It is what elastic capacity looks like from the outside.
A fixed ladder wastes bits on easy content, which is why per-title encoding exists: analyse the source, then pick rungs that fit it. A cartoon does not need the bitrate a grainy film does.
Package and store
Packaging is not transcoding. It takes the rungs that already exist and wraps them in what a player asks for: HLS playlists, a DASH manifest, or both over one set of CMAF segments. Two designs compete. Pre-packaged writes every format to the bucket up front, which makes the origin a plain bucket but multiplies storage by the number of formats and DRM variants. Just-in-time keeps one copy and builds the manifest, and applies encryption, when a request arrives. That trades storage for a packaging tier on the request path that has to scale with your audience.
Either way, a packager can only cut segments at keyframes that are already there. If the rungs were encoded with different GOP lengths, the segments won't line up across renditions and players glitch when they switch. The fix lives at encode time, which is a useful reminder that stages share constraints.
Storage looks cheap and compounds. You keep the mezzanine plus every rendition plus its segments, billed per GB per month, and the catalogue only grows. Storage classes and lifecycle rules decide what keeping it costs: colder classes charge less to hold and more to read back.
Deliver, and what the bill says
Delivery is a CDN copying segments to edges near viewers so the origin serves each segment roughly once per edge cache miss rather than once per viewer. Playlists carry short cache lifetimes, segments long ones. This is the stage that dominates the bill, and the lesson's worked example shows it. It takes 1,000 hours of new video a month, a four-rung ladder, 50 TB stored and 500 TB delivered. That is 240,000 output minutes. At the round example rates of the lesson's first example stack (labelled as examples, not list prices) transcode comes to $3,600, storage $1,000 and delivery $40,000, so delivery is about 90% of $44,600.
Three meters, then: output minutes, GB stored, GB delivered. Cutting a rung from the ladder cuts output minutes and storage, and delivered GB too if viewers were watching that rung, which is why ladder design is a cost decision and not only a quality one.
Watching it queue
The Cloud Video Lab runs a simulation of this flow with the stages as a strip: ingest, transcode, package, store, deliver, with play as a sixth card in the same strip. Each card prints the backlog, throughput, utilisation, wait and cost per hour that the simulation measured at that stage, and under the strip are the transcode farm, the job fanning out into the ladder, and a backlog chart with the capacity line and the boot gap marked. The upload burst defaults to 120 files, and you can turn autoscaling off to get a warm fleet.
The lab's boot-lag challenge sets exactly that scene. A big batch arrives, the autoscaler reacts to a queue it has already seen, and the goal is a worst ingest-to-ready under 25 s. Turning autoscaling off meets it, at the price of idle machines the rest of the time. Nothing in the lab touches a real file, so you can burst as hard as you like.