Streaming Protocols Explained: HLS, DASH, MPEG-TS, RTMP and More

Between the camera and your screen, video passes through several technologies. Streaming protocols decide how it’s packaged and delivered: in small segments over ordinary web servers, as a continuous stream, or broadcast once across a managed network. You don’t need to understand them to watch TV, but they explain a lot about delay, buffering and reliability.

For the overall journey from server to screen, start with how video streaming works.

Protocol, codec and container: three different things

• A codec compresses the video (for example H.264 or HEVC). See video codecs explained.
• A container wraps compressed video and audio together (for example MP4 or MPEG-TS).
• A protocol decides how that content travels across the network.

When people say “HLS stream”, they usually mean all three together: H.264 or HEVC video, in TS or MP4 segments, delivered with HLS.

Delivery to viewers

HLS (HTTP Live Streaming)

Developed by Apple and now the most widely supported streaming protocol.

• Video is cut into short segments, listed in an .m3u8 playlist.
• Delivered over ordinary web servers and CDNs.
• Supports adaptive bitrate: several quality versions, and the player switches between them.
• Used by most streaming services and many IPTV channels.

Our guide to adaptive bitrate streaming explains how players choose a quality level.

MPEG-DASH

An international standard that works much like HLS: segments, a manifest (called an MPD), web delivery and adaptive bitrate. Many large streaming services use DASH on some devices and HLS on others.

CMAF and low-latency variants

CMAF is a common segment format that lets the same files serve both HLS and DASH. Low-latency versions of HLS and DASH use shorter segments and partial delivery to bring live streams closer to real time — see why live streams lag behind TV.

MPEG-TS over HTTP

Many IPTV channels are delivered as a continuous MPEG-TS stream over HTTP rather than as segments. It’s simple and widely supported by IPTV players, but usually offers a single quality level, so connection dips cause buffering rather than a quality drop.

Multicast (managed networks)

Broadband providers’ own TV services often send each live channel once across their network using multicast, copying it only where viewers need it. It’s extremely efficient but works only inside managed networks. See multicast IPTV explained.

Contribution: getting video to the platform

These protocols mostly carry video from a broadcaster or creator to a streaming platform:

• RTMP — once the protocol of Flash video players; today mainly used to send live streams to platforms.
• SRT (Secure Reliable Transport) — an open-source protocol for sending high-quality live video reliably over the public internet.
• RTP / RTSP — common in IP cameras and some broadcast and operator systems.

Real-time and interactive

WebRTC delivers sub-second latency for video calls and interactive streams, such as live auctions or betting. It’s harder to scale to huge audiences than segment-based protocols.

Comparison at a glance

Protocol	Typical role	Latency	Adaptive quality
HLS	Delivery to viewers	Medium (lower with LL-HLS)	Yes
MPEG-DASH	Delivery to viewers	Medium (lower with LL-DASH)	Yes
MPEG-TS over HTTP	IPTV channel delivery	Low–medium	Usually no
Multicast	Operator IPTV	Low	No
RTMP	Ingest to platforms	Low	No
SRT	Contribution over internet	Low	No
WebRTC	Interactive, real-time	Very low	Limited

Where content delivery networks fit

Segment-based protocols work so well at scale because they use normal web technology, which content delivery networks cache close to viewers. Our guide to CDNs in streaming explains how that works.

What it means for viewers

• Adaptive protocols (HLS, DASH) usually drop quality before they buffer.
• Single-quality streams (often MPEG-TS IPTV channels) buffer when your connection dips — so network quality matters more.
• Live delay depends heavily on segment length and player buffer.
• Managed multicast TV is very consistent but tied to your broadband provider.

How adaptive segment streaming works, step by step

Because HLS and DASH power most of what you watch, it’s worth seeing what happens when you press play:

1. The player downloads the manifest — a small text file listing the available quality levels and segment addresses.
2. It picks a starting quality, often a cautious one, so playback begins quickly.
3. It downloads the first few segments, each a few seconds long, and starts playing once it has enough in its buffer.
4. While you watch, it measures how fast segments arrive. If they arrive quickly, it steps up in quality; if they slow down, it steps down before the buffer runs out.
5. For live streams, the player keeps refreshing the manifest to find new segments as they’re created.

This is why a stream may look soft for the first few seconds and then sharpen — the player is testing your connection before committing to a higher quality.

How to tell which protocol a stream uses

You rarely need to know, but clues are easy to spot:

• A stream address ending in .m3u8 is usually HLS.
• An address ending in .mpd is usually DASH.
• An address ending in .ts, or a plain channel number in an IPTV playlist, is often a continuous MPEG-TS stream.
• Some IPTV players let you choose the output format — for example HLS or MPEG-TS — in their connection or playlist settings; if one format buffers, trying the other is a reasonable test.

IPTV playlist files simply list these addresses, one per channel, so the player knows where to fetch each stream.

A worked example

A viewer notices that one IPTV channel buffers on Wi-Fi while a big streaming app on the same TV just drops to a softer picture. The difference is the protocol: the app uses adaptive HLS and steps down a quality level, while the IPTV channel is a single-quality MPEG-TS stream that can only pause and wait. Moving the TV to Ethernet fixes the IPTV buffering.

The bottom line

Streaming protocols decide how video travels: HLS and DASH deliver adaptive segments over web servers; MPEG-TS streams are common in IPTV; multicast powers broadband TV; and RTMP, SRT and WebRTC handle contribution and real-time uses. Knowing which you’re using explains why some streams adapt smoothly while others buffer.