HTTP Video Streaming

HTTP video delivery ranges from one seekable file to an adaptive sequence of short media segments. HTTP moves representations and validators; a container organizes timed tracks, and codecs encode the audio and video samples. Keeping those layers separate makes range handling, caching, and playback failures easier to diagnose.

Progressive Download #

A browser can play a self-contained media file through a <video> element. It may begin with a normal GET or request only a byte range:

GET /media/talk.mp4 HTTP/1.1
Host: media.example
Range: bytes=0-

When the selected representation supports ranges, the server returns 206 Partial Content, the selected interval, and the full representation length:

HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Type: video/mp4
Content-Range: bytes 0-1048575/73400320
Content-Length: 1048576
ETag: "talk-v3"

A satisfiable single range must contain exactly the bytes described by Content-Range. An unsatisfiable range returns 416 Range Not Satisfiable with Content-Range: bytes */73400320. A server that ignores Range can return the complete representation with 200 OK; it must not label a complete body as a partial response.

Validators and Cache Revalidation #

Ranges apply to one representation version. Send a strong ETag or Last-Modified, and let a client use If-Range when resuming or seeking:

Range: bytes=32243712-32955076
If-Range: "talk-v3"

If the validator still matches, the server can return the requested range. Otherwise it returns the complete current representation, preventing bytes from two encodes from being combined. Ordinary conditional requests use If-None-Match or If-Modified-Since and can receive 304 Not Modified. Define Cache-Control according to mutability: content-addressed segments can be immutable, while manifests for live content require short freshness.

Codecs, Containers, Files, and Streams #

A codec such as H.264, AV1, AAC, or Opus transforms sample data. A container such as ISO Base Media File Format or WebM stores one or more encoded tracks, timestamps, indexes, and metadata. One file can contain multiple codecs, and the same codec can appear in several containers.

A finite MP4 file delivered by ranges is progressive download, even when playback begins before download finishes. A live source is continuous at capture time, but HTTP delivery still exposes finite resources such as a moving manifest and media segments. For progressive MP4, place initialization and index metadata where the client can obtain it before media bytes, commonly by fast-start processing that moves moov metadata near the beginning.

HLS and DASH #

HTTP Live Streaming (HLS) uses media playlists and a multivariant playlist. MPEG-DASH uses a Media Presentation Description. Both describe renditions and addressable media segments. A player estimates throughput and buffer health, then selects a rendition whose codec, dimensions, bitrate, and device capabilities fit current conditions.

Segment boundaries should align across renditions so a switch preserves the timeline. Small segments can reduce live latency but increase request, manifest, and CDN overhead. Low-latency modes add shorter partial segments and stricter origin-to-player timing; neither protocol removes encoder and player buffering.

CDNs cache manifests and segments as ordinary HTTP resources. Use versioned segment URLs, correct Content-Type, validators, and cache directives. Avoid cookies or query strings that unintentionally fragment cache keys. Live playlists must expire quickly enough to reveal new segments, while completed video-on-demand segments can use long immutable lifetimes.

Preload, Seekability, and Latency #

The HTML preload attribute is a hint: none, metadata, or auto. User settings, data-saving policies, autoplay rules, and implementation decisions can override it. An application must not assume preload="auto" downloads the entire file.

Seeking requires a mapping from playback time to accessible bytes or segments. A container index enables range-based file seeking; an HLS or DASH timeline identifies the corresponding segment. Live windows can discard old segments, so a seek outside the advertised window must fail or move to the earliest available point.

Startup latency includes manifest or metadata retrieval, connection setup, initial segment transfer, decoding, and the player’s safety buffer. End-to-end live latency also includes capture, encode, packaging, CDN propagation, and playout buffering. Measure each stage rather than attributing every delay to network bandwidth.

Server Checklist #

• Support HEAD, full GET, valid single or multipart byte ranges, and 416 responses consistently for progressive files.
• Preserve representation validators across nodes and return exact Content-Length, Content-Range, and media Content-Type values.
• Authorize every range and segment request; a cached partial response must not bypass the access policy for the full object.
• Test seeks near the beginning and end, concurrent ranges, stale If-Range, CDN cache hits, bandwidth changes, and manifest refresh during live playback.

Use a progressive file when one representation and ordinary seeking satisfy the product. Use HLS or DASH when clients need adaptive bitrate, live publication, multiple renditions, or a segment-oriented CDN workflow.

References #

• RFC 9110: HTTP Semantics, Range Requests
• WHATWG HTML: The Video Element
• Apple HTTP Live Streaming
• DASH Industry Forum Guidelines