The bit people ask about most: what the player fetches, and in what order.
Every packaged asset publishes to a stable tree. Manifests sit at the top, media playlists per rung below, segments under those.
# multivariant manifest — what the player loads first /media/hls/master.m3u8 # one media playlist per rung /media/hls/1080/index.m3u8 /media/hls/720/index.m3u8 /media/hls/480/index.m3u8 # segments, fetched continuously during playback /media/hls/1080/seg.ts
Paths are stable for the life of an asset, so segments cache freely. Manifests carry a short lifetime instead, which is what lets a ladder change take effect without purging anything.
| Segments | Cached at the edge and in the browser. Immutable once published. |
| Manifests | Short lifetime, revalidated. Never served stale after a repackage. |
| Range requests | Supported on segments; used by players that seek aggressively. |
A region that fails health checks stops receiving requests within seconds rather than serving errors. Players see a brief rendition switch, not a stall. If the origin itself is unreachable, already-cached segments keep serving — a full outage degrades to "no new assets" rather than "nothing plays".
<video controls playsinline
src="https://cdn.beamquay.org/<asset>/media/hls/master.m3u8">
</video>
Safari and iOS play this natively. Everywhere else, attach hls.js to the same URL — there is nothing custom to handle.