Video Streaming: Transcoding, HLS, DASH and Adaptive Bitrate
How video streaming works: upload, transcoding ladders, HLS and DASH segments, adaptive bitrate players and CDN delivery behind YouTube and Netflix.
Video streaming platforms such as YouTube and Netflix don't send one video file. They transcode each upload into many versions at different resolutions and bitrates, split each into short segments, and describe them in a manifest using HLS or DASH. The player downloads segments over plain HTTP from a CDN and uses adaptive bitrate (ABR) logic to switch quality segment by segment as network conditions change, so playback starts fast and rarely stalls.
From upload to playback
Upload and transcoding
- Uploads of large files use chunked, resumable uploads straight to object storage. See resumable uploads.
- A bitrate ladder defines the renditions, for example 240p at 300 kbps up to 1080p at 5 Mbps and 4K at 15+ Mbps. Smarter platforms tune the ladder per title, since a cartoon needs fewer bits than a sports match.
- Codecs: H.264 for compatibility, with newer codecs (HEVC, VP9, AV1) for better compression on devices that support them. More codecs mean more storage and compute.
- Parallelism: split the source into chunks and transcode them on many workers at once, then stitch the results. A queue distributes the work; failed chunks are retried. See message queues.
- Extras: thumbnails, captions, audio tracks in several languages, and content checks run as part of the same pipeline.
HLS and DASH
Both formats split each rendition into segments of a few seconds and publish a manifest. HLS (HTTP Live Streaming) uses .m3u8 playlists and is required on Apple platforms; DASH uses an XML media presentation description. With the CMAF container, one set of segments can serve both, halving storage.
#EXTM3U # master playlist (HLS)
#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360
360p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2500000,RESOLUTION=1280x720
720p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
1080p/index.m3u8Because segments are ordinary HTTP files, they're cached by CDNs like any static asset, which is what makes streaming to millions of viewers affordable.
Adaptive bitrate
- The player measures download throughput and watches its buffer (seconds of video downloaded ahead).
- It picks the rendition for each next segment: higher quality when throughput is high and the buffer is healthy, lower when the buffer drains.
- Start-up: begin with a low or medium rendition to start quickly, then step up.
- Goals in tension: start fast, avoid rebuffering (the worst experience), maximise quality, and avoid switching quality too often.
Delivery at scale
- CDNs serve almost all traffic: popular titles are cached at the edge; large platforms also place caches inside internet service providers' networks.
- The long tail of rarely watched videos is served from regional caches or origin, so origin capacity and cost per GB still matter.
- Cache keys per segment and rendition; segments are immutable, so they can be cached for a long time.
- Live streaming adds tight latency: shorter segments or low-latency HLS/DASH modes, and transcoding in real time.
- Protection: signed URLs and DRM for paid content.
- Quality metrics: start-up time, rebuffering ratio, average bitrate and playback failures, measured from players.
Where it’s used
Per-title bitrate ladders and CDN-cached segments serve films and series worldwide.
Massive parallel transcoding of uploads, with fast low-resolution versions published first.
Low-latency HLS or DASH with real-time transcoding and huge synchronised audiences.
In an interview
- Walk through upload, transcoding into a bitrate ladder, segmenting and manifests.
- Explain how ABR picks segments from throughput and buffer level.
- Put a CDN in front and treat segments as immutable cached files.
- Size storage and transcoding compute, and mention live streaming differences.
Further reading
- HTTP Live StreamingApple Developer
- Per-Title Encode OptimizationNetflix Technology Blog