A two-hour film must start playing within two seconds on a phone on 4G. What has to exist before the play button works?

Short answer

Precompute the renditions and segments, cache the manifest and first low-rung segment close to users, then keep startup to a licence check, one segment download and decoder start.

The answer is that almost nothing happens at play time

Two seconds does not buy you any real work. It buys a few network round trips and a decoder start. So the honest response is a list of things finished long before the viewer opened the app, and the interviewer is checking whether you know that streaming is a preparation problem wearing a latency costume.

Before the play button can work, the film must already exist as alternative encodings at several bitrates and resolutions. Each must already be cut into short segments. Every segment must begin at a point a decoder can start from. The segments must be described by a manifest. That manifest and the opening segments must already sit in a cache close to the viewer. And if the title is protected, a licence must be obtainable in one round trip that overlaps the rest.

Anything on that list which is not done in advance cannot be done inside two seconds. Transcoding a two-hour film is minutes to hours of compute. There is no version of this design where it happens on demand.

The object count, derived from the segment length

Do the arithmetic, because it explains why this is an asset-management problem as much as a delivery one. Two hours is 7,200 seconds. At four-second segments that is 1,800 segments for one rendition. A ladder of six video renditions is 6 × 1,800, so 10,800 objects, before audio tracks in several languages, subtitle files, thumbnails and the manifests themselves.

That number is why encoding is a batch pipeline with a job queue, why the segments live in object storage, and why adding a rung across a large catalogue is a capital decision rather than a configuration change. It is also why segment length is a genuine trade-off rather than a default to accept.

Shorter segments start faster, because the first segment you must fetch before showing a frame is smaller, and they let the player react to a change in throughput sooner. They cost more requests and more per-segment overhead. Longer segments compress a little better and are cheaper to serve, and they make both startup and adaptation sluggish. Some designs use shorter segments at the start of a title and longer ones after, which is a neat compromise to have heard of.

Why every segment starts at a point a decoder can enter

A decoder cannot begin part-way through a group of pictures, because most frames are stored as differences from other frames. It can only start at a frame that stands alone. Those frames are the entry points. So the encoder places those independent frames at fixed intervals and the segment boundaries are put on them.

Then comes the constraint that makes adaptive switching possible. Those boundaries must fall at the same positions in every rendition. If one rung's segments start at 0, 4 and 8 seconds while another's start at 0, 5 and 10, a player switching between them either overlaps content or leaves a gap, and the visible result is a stutter at the exact moment the network improved. Aligning the ladder is imposed on encoding, before anything is delivered, and it cannot be repaired at the edge.

flowchart LR
  A[Mezzanine master] --> B[Transcode ladder<br/>aligned boundaries]
  B --> C[Segment and package<br/>plus manifest]
  C --> D[Object storage]
  D --> E[CDN edge<br/>prewarmed for hits]
  E --> F[Play tap<br/>manifest then segment]
  F --> G[Low rung plays<br/>then steps up]

Everything left of the play tap happens on a schedule measured in hours. Only the last two boxes happen inside the viewer's two seconds, which is the whole shape of the answer.

Spending the two seconds

Itemise it rather than asserting it. Connection setup to the edge, including DNS and a TLS handshake, is one or two round trips and on a mobile network a round trip is tens of milliseconds at best. The manifest is a small fetch, though a top-level manifest pointing at a per-rendition manifest is a second round trip you should notice. The initialisation segment carrying the codec configuration is another. Then one media segment, which at a low rung and four seconds of content is a few hundred kilobytes. Then the decoder starts and the player has to buffer enough to be confident it will not stall immediately.

Add those up. There is no slack. So the levers are: start on a low rung, keep the first segment small, collapse round trips by keeping manifests shallow and reusing the connection, and fetch the licence in parallel rather than in sequence.

Starting low is the important one and it has a cost worth stating. The first few seconds look worse than the connection could support, and the player steps up as it measures actual throughput and watches its buffer grow. Start on a high rung to look good and you gamble the startup budget on a network you have not measured yet. Most players resolve it by starting conservatively and switching up within the first few seconds, so the viewer sees a picture immediately and a better picture shortly after.

Adaptation itself runs on two signals: measured throughput and buffer occupancy. Throughput alone is jumpy on a mobile network. Buffer alone reacts too late. Using both is what stops the ladder oscillating between rungs, which is visible to viewers as the picture quality breathing.

What a cold cache does to the promise

Here is where an answer stops being a diagram. The two seconds depends on the segments being at an edge near the viewer. For a popular title on launch night, they are, because you pushed them there deliberately before anyone asked.

For a film nobody has watched in a year, the edge has nothing. The cache is empty and the promise is not. The first request becomes an origin fetch across a continent, and the budget is gone. Nothing in the design prevents that, and pretending otherwise is worse than admitting it. What you can do is bound it: prewarm the manifest and the first few segments of every title in the catalogue, since that is a small fraction of the total bytes, and let the rest fill on demand as the viewer watches. Startup is then fast even for the long tail, and only a viewer who skips ahead in an unpopular film pays the origin latency.

Tiered caching helps for the same reason. A regional cache between the edge and the origin turns most misses into a short hop rather than a long one, and it also protects the origin when a new release causes thousands of edges to miss at once.

The two mistakes an interviewer is listening for

The first is putting encoding anywhere in the request path, usually phrased as transcoding on the fly for the device that asked. It is the single answer that cannot be rescued by any amount of caching, because the work exceeds the budget by orders of magnitude.

The second is measuring startup from the wrong moment. Teams instrument from "player initialised" or from "first segment requested", both of which exclude the app launch, the DNS lookup and the licence call. The viewer's two seconds begins when their thumb lifts off the play button. Measure from there, at the percentiles that matter, on real mobile networks, or the number on your dashboard will be healthy while the product feels slow.

Startup latency is not something you optimise at play time; it is a property of decisions already taken about ladder alignment, segment length and what you chose to place at the edge before anybody asked for it.

© 2026 Preptima. Originally published at preptima.com.