Video delivery only works well when the format matches the job. A training library, a live sports feed, and a product launch all need different trade-offs in latency, resilience, and device support. In this article I break down the main streaming types, explain the protocols behind them, and show how to choose a setup that behaves well on real networks.
The practical choice comes down to timing, resilience, and the devices you need to support
- Live streaming is about immediacy; on-demand is about convenience and scale.
- Adaptive bitrate streaming is the default because it helps playback survive changing network conditions.
- HLS and DASH are the main delivery formats; RTMP still appears mostly at ingest.
- Low-latency live makes sense when interaction matters, but it adds operational complexity.
- For UK audiences, mixed network quality makes fallback ladders and CDN delivery essential.
The categories that matter most in real video workflows
When I map a project, I start with the viewer's relationship to time. Live streaming is about simultaneity, on-demand is about convenience, linear streaming is about scheduled programming, and catch-up sits in the gap with a replay window around a live event. Those labels sound simple, but they lead to very different technical choices.| Category | What it is | Best fit | Main trade-off |
|---|---|---|---|
| Live streaming | Content is captured and delivered as it happens. | Sports, webinars, launches, breaking news, corporate events | Delay and network stability matter more than in any other format. |
| On-demand | The viewer starts playback whenever they want. | Training, archives, tutorials, highlights | No shared live moment, but excellent control and scalability. |
| Linear streaming | A scheduled feed runs like a TV channel. | FAST channels, brand channels, digital signage | Less viewer control, but strong if you want programmed viewing. |
| Catch-up live | A live feed includes a rewind or replay window. | News, sports, conference coverage | More storage, more packaging, and more logic to manage. |
The important point is that these are not competing ideas so much as different audience promises. Once that promise is clear, the technical stack becomes much easier to choose, which is where adaptive delivery enters the picture.
Why adaptive bitrate is the backbone of modern delivery
Adaptive bitrate streaming, usually shortened to ABR, is what keeps playback from falling apart when the network changes mid-session. The same video is encoded into multiple renditions, often at different bitrates and resolutions, and the player switches between them based on current bandwidth and buffer health. In practice, that is the difference between a stream that keeps going and one that pauses every few seconds.
- It reduces buffering by letting the player move down to a lighter rendition when the connection weakens.
- It improves start time because the player can begin with a conservative bitrate and ramp up.
- It makes mobile viewing realistic on trains, in cafés, or anywhere the signal is uneven.
- It scales better through CDNs because HTTP-based delivery and segmented media are easier to cache and distribute.
A sensible ladder usually includes more than one safety net. I like to see at least one low-bitrate option, a mid-tier option that looks acceptable on average networks, and one or two higher rungs for viewers with stronger connections. Without that ladder, you force every user into the same compromise, which is rarely a good one.
Once ABR is in place, the next question is not just how good the picture looks, but how the pieces of the pipeline are actually delivered.
HLS, DASH, CMAF, and RTMP play different roles
At the technical layer, I separate transport, packaging, and playback. HLS and DASH are delivery formats for viewers, CMAF is a packaging approach that can support both, and RTMP is usually a contribution protocol for getting a source feed into the platform. Mixing those layers up is one of the fastest ways to design a workflow that looks fine on paper and becomes awkward in production.
| Protocol or format | Primary role | Where it fits best | What to remember |
|---|---|---|---|
| HLS | Viewer delivery | Live and on-demand playback across Apple devices, browsers, and CDN-backed workflows | Runs over ordinary web delivery and is built for reliability and broad compatibility. |
| DASH | Viewer delivery | Standards-based adaptive streaming in multi-device environments | Works well when you want a flexible, modern delivery stack outside the Apple ecosystem too. |
| CMAF | Packaging format | Workflows that want to share media segments across HLS and DASH | Useful when you want less duplication and cleaner packaging logic. |
| RTMP | Contribution ingest | Encoder to platform or encoder to cloud ingest | Still practical for bringing a live source into the system, but not my choice for final viewer playback. |
If I am building a public-facing stream, I generally want the delivery side to be HLS or DASH, with RTMP used only where it makes sense upstream. That separation keeps the architecture cleaner and makes it easier to optimize for the audience instead of the encoder.
Low latency is useful, but only when the use case justifies it
Low-latency live streaming is tempting because everyone wants video to feel instant. I do not reach for it by default. I use it when the delay changes the product, such as auctions, live chat interactions, betting, remote moderation, or sports commentary where being a few seconds behind breaks the experience.
Apple's low-latency HLS mode is designed to bring delay down to around two seconds or less when the workflow is set up correctly. That is a real gain, but it comes with trade-offs: shorter segments, smaller player buffers, tighter encoder settings, and less forgiveness when the network gets messy. In other words, the closer you get to real time, the less room you have for sloppiness.
- Use standard live delivery when stability matters more than instant interaction.
- Use low-latency live when audience feedback must stay tightly synced to the stream.
- Avoid over-optimising latency if the content is a webinar, training session, or branded broadcast with no live response loop.
- Expect more tuning because the pipeline becomes more sensitive to encoder behaviour and network jitter.
My rule is simple: if a viewer being ten seconds behind is fine, do not pay the complexity cost of chasing sub-two-second delivery. That decision becomes clearer once you match the workflow to the audience, which is where context matters most.
Choose the stack around your audience, not the protocol
For a UK audience, I assume a mixed reality by default: home fibre, office Wi-Fi, mobile on the move, and evenings where networks are busier than they look in a lab. That pushes me toward CDN-backed adaptive delivery almost every time, because a stream that only works under ideal conditions is not a production-ready stream.
| Use case | Practical choice | Why it works |
|---|---|---|
| Public webinar or product launch | HLS or DASH with ABR through a CDN | Broad compatibility and strong resilience without unnecessary latency pressure. |
| Sports watch-along or auction | Low-latency live pipeline | The audience reaction loop stays close to the action, which matters for the experience. |
| Training library or content archive | On-demand delivery with ABR | Simple to scale, easy to revisit, and forgiving of varied viewer connections. |
| Venue contribution to cloud | RTMP push into the encoder or platform | A practical way to get a source feed into the production chain before repackaging for viewers. |
| Multi-device app | Package for HLS and DASH, ideally with shared CMAF segments | Gives you broader device coverage without duplicating more work than necessary. |
If the device mix is narrow, one delivery path may be enough. If it is broad, packaging for both HLS and DASH often saves time later, especially when players, browsers, and connected TV environments do not all behave the same way.
The checks that prevent most streaming problems
The failures I see most often are not dramatic. They are small decisions that compound: no bitrate ladder, the wrong latency target, the wrong protocol used for the wrong layer, and no proper test on weaker networks. For a stream that has to work in the real world, those details matter more than most teams expect.
- Keep at least one conservative low-bitrate rendition in the ladder.
- Test on weak Wi-Fi and mobile data, not just office broadband.
- Separate ingest from viewer delivery so the architecture stays clean.
- Check that captions, alternate audio, and metadata survive packaging.
- Build a fallback path for encoder issues, upstream failures, or CDN problems.
- Only chase ultra-low latency when the content truly benefits from it.
If I had to reduce the whole topic to one rule, it would be this: use ABR-based HLS or DASH for most public delivery, keep RTMP at the contribution stage, and move to low-latency live only when the content genuinely needs it. That combination usually gives the best balance of reach, reliability, and operational sanity.
