Video Transcoding & Streaming (HLS/DASH)
StorageConverts uploaded video into multiple resolutions/bitrates and serves it in small chunks so playback can adapt in real time to the viewer's bandwidth.
Streaming video isn't 'serve one big file' — it's built around adaptive bitrate streaming: the source video is transcoded into multiple renditions (e.g. 240p/480p/720p/1080p, each at several bitrates), split into short chunks (typically 2–10 seconds each), and described by a manifest file (HLS's `.m3u8` or DASH's `.mpd`) listing all available renditions and chunk URLs. The client's player continuously monitors its own network conditions and requests the next chunk from whichever rendition currently fits its available bandwidth — switching resolution seamlessly, chunk by chunk, without ever stopping playback to rebuffer, which is the entire point of the design.
How it connects
Video Transcoding & Streaming (HLS/DASH) as the source, with the components it typically interacts with.
- → Object / Blob Storage: Raw and transcoded video renditions are stored durably in object storage, which the streaming service reads from to serve playback requests.
- → CDN (Content Delivery Network): Video segments are served through a CDN so playback bandwidth is handled at the edge, close to viewers, instead of from origin servers.
- → Message Queues & Event Streaming: Uploaded videos trigger an async transcoding pipeline via queued jobs, since encoding into multiple renditions is too slow to do inline on upload.