Video streaming, explained
Between the file you upload and the picture a viewer sees sits a chain of encoders, playlists, segments and caches. This hub explains each link and why it is there.
Video streaming cuts each version of a video into short pieces called segments. A playlist lists them, and the player fetches them over plain HTTP. The player can switch to a bigger or smaller version as the connection changes. HLS and DASH are the two main protocols. CDNs keep copies of the segments near viewers, and transcoding makes the versions in the first place.
Guides in this hub
- ExplainerWhat is HLS streaming?HTTP Live Streaming is a text playlist, a pile of short media files and a set of rules for a player. Here is how those pieces fit together and why it became the default way to deliver video.8 min readRead
- Deep diveAdaptive bitrate streaming, explainedA player that changes quality mid-stream is making a prediction every few seconds. How the rendition ladder is built, how the player chooses a rung, and what makes the choice hard.8 min readRead
- ComparisonHLS vs DASHTwo protocols that solve the same problem in almost the same way. Where they still diverge: device support, DRM, low latency, manifests and the CMAF packaging that lets one set of segments serve both.7 min readRead
- ExplainerCDN for video deliveryVideo is the most cache-friendly traffic on the internet and the most punishing when caching fails. How content delivery networks serve segments, what to cache for how long, and where the costs hide.8 min readRead
- Deep diveVideo transcoding, explainedTranscoding turns one source file into a set of aligned versions ready for adaptive streaming. Here is what happens at each stage, and which settings decide the result.9 min readRead
Streaming is one word for a lot of machinery. When someone presses play, no single file is sent to them. The player first downloads a small text playlist. It reads the list of short media segments and picks the version its connection can carry. Then it fetches the segments one by one, often from a cache in the same city. If the connection sags, it steps down to a smaller version at the next segment. When the connection recovers, it steps back up.
Each part of that story is a technology with its own rules and trade-offs. This hub takes them in the order the video meets them. First comes transcoding, then packaging into HLS or DASH, then adaptive switching, then delivery through a content delivery network. It is for people who upload and embed video and want to know what happens in between.
Why video is not simply downloaded
A single big file is a poor way to deliver video. It works for short clips on fast connections. It fails almost everywhere else, for the reasons below.
The limits of one big file
A plain MP4 on a web server can play progressively. The browser downloads from the start and plays what it has. But the file has one bitrate, chosen in advance. A viewer on a slow phone link buffers. A viewer on fibre gets no benefit from the spare speed.
Seeking past the downloaded part needs byte-range requests, and the server must support them. Live video is impossible, because a file that is still being written has no index.
How segments fix it
Segmented streaming treats video as a row of small files. Each file has its own address and travels over ordinary HTTP. Each version of the video is cut into segments a few seconds long. A playlist lists them, and the player fetches the ones it wants.
Apple designed HLS for this job in 2009. It later became RFC 8216, and it is what VideoBB uses to deliver every video. The HLS guide explains the playlists, the segments and the tags inside them.
Renditions and the ladder
A rendition is one version of the same video at a set size and bitrate. Segments only pay off if there are several renditions to choose from. The full set, from smallest to largest, is called a ladder.
What VideoBB builds from your upload
A transcoding pipeline takes the upload and makes the ladder. Every rendition is cut at the same moments in time. That lets the player switch between them mid-stream without a visible glitch.
On VideoBB the ladder runs 144p, 240p, 360p, 480p, 720p and 1080p for every upload. When the source is sharp enough, 1440p and 2160p are added, and Premium members can watch them. The transcoding guide shows how the ladder is made and why keyframes must line up across it.
How the player picks a rung
The player's automatic quality setting chooses a rung for each segment. It is harder than measuring the speed once, because the speed keeps changing. The adaptive bitrate guide explains how the player decides. The help page on quality levels and Auto shows the same menu from the viewer's side.
The streaming chain at a glance
Each stage answers a different question. A problem at one stage often shows up as a symptom at another. That is why the whole chain is worth knowing.
| Stage | What it does | Symptom when it goes wrong | Guide |
|---|---|---|---|
| Transcoding | Produces aligned renditions from the source | Blurry or blocky output, missing qualities | Video transcoding explained |
| Packaging | Cuts renditions into segments and writes playlists | Playback fails to start, wrong duration | What is HLS streaming |
| Adaptive selection | Player picks a rendition per segment | Constant quality switching, buffering | Adaptive bitrate streaming |
| Protocol choice | HLS or DASH, or both via CMAF | Works in one browser, not another | HLS vs DASH |
| Delivery | CDN caches segments near viewers | Slow start, stalls far from the origin | CDN for video delivery |
Two protocols, one idea
HLS is not the only segmented streaming protocol. MPEG-DASH does the same job in almost the same way. The HLS vs DASH comparison sets out where they still differ, including DRM, low-latency modes and advert insertion.
HLS and DASH side by side
ISO standardised MPEG-DASH in 2012. It uses an XML manifest instead of a text playlist. It was also built from the start to work with any codec.
For years the real difference was device support. Apple devices played HLS natively and nothing else. Other browsers needed JavaScript for either one.
CMAF: one set of segments for both
The Common Media Application Format changed the maths. It lets a single set of fragmented MP4 segments serve both protocols. So choosing both no longer means storing everything twice.
Delivery: why a CDN sits in front
A content delivery network, or CDN, keeps copies of the segments on servers close to viewers. Most requests then never reach the origin server. Segments are small files that never change, so they cache very well. The CDN guide explains cache lifetimes, origin shields and signed URLs. The video hosting hub covers what that delivery costs when you run it yourself.
Ideas that recur throughout this hub
- Segments are ordinary files with ordinary URLs. Caching, scale and reliability all follow from that.
- Switching renditions is only seamless if every rendition has a keyframe at the same timestamps.
- A playlist is cheap to refresh and a segment is costly to fetch. That shapes how live streaming and caching work.
- Bandwidth is measured, not known. Every adaptive player is guessing about the next few seconds.
- The protocol matters less than it used to. The encoding ladder and the delivery path matter more.
Frequently asked questions
Is streaming the same as downloading?
The bytes travel the same way, over HTTP. But streaming fetches short segments on demand and throws them away after playback. A download saves the whole file for later. In practice, a streaming player can switch quality mid-play, start fast from any point and follow a live stream. A single downloaded file can do none of those.
Why does my video start at low quality and then improve?
Adaptive players start carefully because they have not yet measured the connection. Many begin with the first rendition in the playlist, or a low one on purpose. That way playback starts within a second or two. Once the first segments reveal the real speed, the player steps up. This is by design: a player that guessed high and then buffered would feel worse.
Do I need to encode multiple versions before uploading?
No. Upload one high-quality source and the platform's transcoder builds the full ladder from it. On VideoBB that is 144p to 1080p for everyone, plus 1440p and 2160p when the source is large enough, which Premium members can watch. Encoding renditions yourself only makes sense when you run your own player and delivery. For upload, one source at a generous bitrate is best, since every rendition comes from it.
Sources
- RFC 8216: HTTP Live Streaming — The HLS specification
- Apple: HTTP Live Streaming — Apple's HLS documentation and authoring guidance
- DASH Industry Forum — MPEG-DASH interoperability guidelines
- MDN: Streaming media — Web media formats and streaming overview