HLS: follow segments from input to playback

Latest client playlist snapshot

Follow five different stages

The encoder produces complete constant-duration segments from an input starting at media time zero. Publication happens after the configured delay. The server exposes a sliding list of published segment identifiers, while the client sees only its most recently polled snapshot. A listed segment must still finish downloading before its media enters the playable buffer. Playback then consumes media at one second per second. Five timeline rows show published, server-listed, client-listed, downloaded and fully played segments separately. Gray cells mean that stage has not selected or completed that segment; they do not mean the encoded file has been deleted.

Configure the source and the playlist

Segment duration sets media seconds per segment, from one through ten. Every synthetic segment has a fixed one-thousand-kilobit-per-second bitrate, so a four-second segment contains four thousand kilobits. Publication delay adds zero through five seconds after encoding completes. Playlist window keeps the latest three through ten published identifiers. The displayed playlist includes target duration, media sequence, durations and illustrative segment filenames. These filenames are shown as text, not links to real video files. This lab computes a delivery timeline; it does not encode or play an actual HLS stream.

Configure the client, not just the picture

Poll interval controls when the client learns a new playlist snapshot. Longer polling can miss identifiers that entered and left a small window between polls. Download capacity controls actual transferred kilobits each tenth of a second. Startup segments chooses one through three contiguous complete segments to download before playback starts. At initial attachment the client selects that many segments back from the current snapshot end. Choosing fewer than three deliberately explores an aggressive starting position; it is not recommended production HLS behavior. Scenario edits reset all state, preventing old buffer contents from surviving a new segment-duration setting.

Check the default fifteen-second startup

Restore defaults: four-second segments, a five-segment window, four-second polling, zero publication delay, four-thousand-kilobit-per-second capacity and three startup segments. At twelve seconds the client has a snapshot containing segments zero, one and two and starts the first download. Each download takes one second. Scrub to fifteen seconds: three segments are complete, twelve media seconds are buffered, and playback has just started at media time zero. Live input is therefore fifteen seconds ahead. Step forward to see playback consume buffer while production and later playlist snapshots progress independently. The exact state panel reports the quantities used to draw the timeline.

Distinguish a small playlist from short file retention

Set segment duration to one, poll interval to one, window to three and capacity to two hundred. Downloading one segment now takes five seconds, but the model retains every discovered descriptor and its underlying file for the session. Downloaded segments can therefore be older than the current playlist window. This is intentional: removing a URI from a playlist is not equivalent to immediately deleting its media. The specification separately describes availability after playlist removal. This teaching fixture assumes longer retention and does not implement an expiration policy or simulate HTTP errors.

Create a genuine discovery gap

Set segment duration to one, window to three, poll interval to twenty and startup segments to one. At the first useful poll the client attaches near the current edge. By the next poll, some subsequent identifiers were never observed. The status reports the missing segment and halts new requests rather than silently inventing its URL or skipping media. Already buffered media may continue playing and then stall. This demonstrates the cost of sparse discovery; it is not a claim that every HLS client uses this recovery policy. Restore defaults to compare the same sixty-second session without the missed identifiers.

Inspect the animation at your pace

Play advances sixty model seconds at normal speed. Pause freezes the inspection, Restart returns to zero with the current configuration, Step advances one second, and Finish displays the final state. The timeline slider selects any tenth of a second and pauses automatically. Inspection speed changes between half, normal, double and quadruple speed without altering the computed trace. Restore defaults restores the original scenario controls. Dark segment blocks indicate completion or membership in each labeled row; the orange transfer bar indicates partial download. The playlist and JSON state expose exact identifiers and counters without relying on color or the diagram.

Boundaries of this experiment

This is a complete-segment, single-rendition model, not low-latency HLS or a browser implementation. It excludes partial segments, blocking reloads, encryption, discontinuities, adaptive quality, audio synchronization, request latency, decoder queues and real network calls. Fixed polling is an experimental control, not the specification’s changed-versus-unchanged reload procedure. Transfer accounting uses one-hundred-millisecond ticks, unused capacity in a completion tick is discarded, and complete media becomes usable in the following tick. Requests wait when the playable buffer cannot fit another whole segment under its thirty-second cap. After startup, stalls resume with newly completed media rather than repeating the initial threshold. Live-input latency is unknown until playback starts and increases when playback stalls; it is not forced to a universal multiple of segment duration.

Protocol reference: RFC 8216, HTTP Live Streaming.