How YouTube streams.
Videos arrive as a sequence of small (~4 sec) chunks, each encoded at multiple quality levels. A manifest file describes what\'s available. Your player measures your bandwidth and picks a quality level per chunk. Move the bandwidth slider and watch the resolution flip mid-stream.
Why chunks, not a single stream
Old streaming (RTMP, original RTSP) sent a single continuous stream. The server picked the quality; clients couldn\'t adapt; one packet loss could derail the playback. DASH and HLS broke video into independent 2-10 second segments, each encoded at multiple bitrates. The client picks per segment. Switching quality is a clean cut at the next segment boundary. Network blips affect at most one segment, not the whole stream. CDNs can cache segments like any other static file.
The ABR algorithm
Adaptive Bitrate algorithms pick the next segment\'s quality. Three families: throughput-based (measure recent download speed, pick the highest rung that fits with safety margin), buffer-based (if buffer is full, try higher quality; if low, drop), hybrid like Pensieve (uses RL on both signals). Most production ABRs are hybrid because pure throughput is jittery and pure buffer doesn\'t respond fast enough to slow connections.
Why videos sometimes start at 144p and creep up
Conservative startup. The player has no bandwidth measurement yet on segment 1, so it picks the lowest rung that fits a guess (often default 144p or 360p). After fetching a few segments, it has real numbers and walks up the ladder. Modern players try to start higher with HTTP/2 connection-reuse signals and last-session bandwidth estimates stored in localStorage, but the "ugly first second" is hard to fully eliminate.
Video delivery internals →
DASH vs HLS, low-latency LL-HLS, CMAF, CDN tier selection, ABR algorithms, why YouTube also uses pre-fetching + ML-based quality prediction.
Open the Codex →