RTMP vs HLS: Which Protocol Fits Your Live Stream?

RTMP vs HLS is less a contest than a hand-off. RTMP carries a live stream from your encoder to a server, and HLS carries it from the server to viewers. Most live platforms use both, in that order. This guide compares them on delay, browser support, scale and codecs, then shows which one your stream needs.

The RTMP vs HLS choice is easier with numbers, so this guide uses figures from YouTube’s help pages, the HLS specification and our own bandwidth maths. If you want the basics first, start with the beginner’s guide below.

RTMP vs HLS: What Is the Difference?

RTMP keeps one live connection open to push video to a server, while HLS cuts video into short files that players fetch over ordinary HTTP. As a result, that single design choice explains almost every other difference. The first is mainly an ingest protocol, and the second is mainly a delivery protocol.

Table comparing RTMP and HLS across nine points: main job, how video moves, port, browser playback, codecs, quality choices, encryption, delay and scaling. RTMP sends video from encoder to server over one TCP connection, while HLS delivers short files over HTTP that browsers can play and caches can serve.

How Does Each Protocol Move Your Video?

RTMP pushes a continuous stream over TCP, and HLS publishes a playlist of short segments that each player pulls. Wikipedia’s account of the format says Apple released it in 2009. A player reads an .m3u8 playlist, then downloads the segments one by one.

Also, the same playlist can list the stream at several bitrates. That is how adaptive bitrate works: the player switches rungs as the connection changes. The older protocol has no such list, because each connection carries one stream.

Segments also set a rule for your encoder. The HLS specification expects each H.264 segment to contain a keyframe. Match your encoder to the segment length. YouTube recommends a 2-second keyframe interval, which suits segments of 2 seconds or any multiple of it. By default, the Nginx module cuts a new segment every 5 seconds and keeps a 30-second playlist, according to its wiki.

RTMP vs HLS Latency: How Much Delay Does Each Add?

RTMP adds little delay on its own, while HLS keeps viewers at least three segments behind live by default. In the RTMP vs HLS latency debate, the gap comes from the segments, not from slow servers. The specification sets the default hold-back at three times the target duration, so 5-second segments mean about 15 seconds.

YouTube says HLS has higher latency than RTMP, because it sends segments instead of a continuous stream. YouTube’s latency options give a useful yardstick: most viewers see under 10 seconds on low latency, and under 5 seconds on ultra-low.

Horizontal bar chart of the minimum distance behind live for classic HLS at the specification’s default of three segments: 6 seconds for 2-second segments, 9 for 3-second, 15 for 5-second, 18 for 6-second and 30 for 10-second segments, with dashed lines at 5 and 10 seconds marking YouTube’s ultra-low and low latency tiers.

RTMP vs HLS: Can Low-Latency HLS Close the Gap?

Partly: Low-Latency HLS cuts the delay with parts shorter than a second, while classic segments hit a hard limit. The maths shows it. Segments of 3 seconds or less keep the classic format under 10 seconds, and getting under 5 seconds needs segments of about 1.6 seconds. Shorter segments also shrink the buffer, and the specification warns that this raises the risk of stalls.

Low-Latency HLS attacks the problem differently. Apple announced it in 2019, and it splits each segment into parts shorter than a second. It needs HTTP/2. Also, Wikipedia notes it entered the specification in April 2020.

RTMP’s advantage has a limit too. It applies only to the first leg. The platform still transcodes the stream and repackages it before viewers see anything.

RTMP vs HLS in the Browser: What Can Play?

HLS plays in browsers and on phones, and RTMP does not. According to Wikipedia, Safari, iOS and Chrome on Android play it natively. However, other browsers use a JavaScript player built on the same segments.

RTMP lost browser playback when Flash ended. It survives as the way in, so a typical site converts the stream to HLS before showing it. The beginner’s guide covers why the protocol outlived Flash.

RTMP vs HLS at Scale: Who Carries the Load?

HLS scales because its segments are plain files that caches and CDNs can serve, while an RTMP server holds a live connection open for every viewer. Wikipedia notes that this content can come from conventional HTTP servers and travel over CDN networks, and that Twitch uses HLS to reach many concurrent viewers.

In short, our own maths shows where the limit sits. A 1 Gbps port serves about 166 viewers of a 6 Mbps stream, because each viewer pulls their own copy.

Table of where the bandwidth goes for one 6 megabit per second stream: 6 megabits in for ingest, 18 megabits out when restreaming to three platforms, about 166 viewers when delivering from one 1 gigabit origin, and a cache or CDN serving the segments so the origin does not serve every viewer.

Which Codecs Do RTMP and HLS Carry?

Both carry H.264 and AAC everywhere, but only Enhanced RTMP lets the older protocol carry HEVC and AV1. So RTMP vs HLS is no longer a codec contest. Classic codecs were limited by the Flash-era format. Enhanced RTMP removes that limit, and the specification adds HEVC, AV1, VP9 and Opus.

In addition, the gain is measurable. YouTube’s encoder settings accept H.264, H.265 and AV1, and they recommend about 29% less bitrate for AV1 and H.265 at 1080p30: 10 Mbps instead of 14. HLS also works as an input for encoders that cannot send HDR or newer codecs over RTMP.

RTMP vs HLS: Which Fits Your Live Stream?

RTMP sends a stream into a platform or server. HLS shows it to an audience. Running your own origin means using both, because the right choice depends on where the stream is going.

Decision table with six live streaming situations and the protocol for each: RTMP or RTMPS for sending from OBS to a platform, HLS for showing a stream on your own site, HLS with a cache or CDN for a large audience, HLS ingest for older encoders with HDR, RTMP in and out for relaying to several platforms, and Low-Latency HLS or a real-time protocol for delay under 5 seconds.

Can You Use RTMP and HLS Together?

Yes, and most live setups do: RTMP carries the stream in, the server packages it, and HLS carries it out. A single origin can do all three jobs, and it can transcode a quality ladder in between.

Flow diagram of the usual live pipeline: an encoder such as OBS or FFmpeg sends the stream over RTMP to an origin server that packages the segments, which delivers HLS over HTTP through an optional cache or CDN to viewers on any device.

However, the ladder is where the work lands. Each rung is a separate transcode, so CPU grows with the number of rungs. Our Nginx guide gives a working two-rung configuration. Meanwhile, the hardware transcoder comparison shows when a GPU or ASIC pays off.

What About SRT and WebRTC?

They are real alternatives for ingest and for low delay, but this comparison stays with the two protocols above because those are what most encoders and platforms speak. Newer open-source servers such as MediaMTX handle RTMP, HLS, SRT, WebRTC and RTSP in one place.

If you need interaction in under a second, start with real-time tools, not segment-based ones. For everything else, RTMP in and HLS out remains the safest default.

What Does the Choice Mean for Your Server?

RTMP ingest is a bandwidth job, HLS packaging adds disk and a little CPU, and a quality ladder adds cores. The RTMP vs HLS split also shapes the bill, so plan the port first, then the drives, then the processor.

• Ingest: the upload equals the bitrate, and every restream destination repeats it.
• Origin: segments live on disk or in memory, and a cache keeps viewers off the origin.
• Ladder: each rung is an encode, so measure the speed before you promise a channel count.

RTMP vs HLS: The Short Version

RTMP vs HLS is a hand-off, not a choice: RTMP gets your stream in, and HLS gets it to viewers. Pick RTMP or RTMPS for the first leg, standard segments for the second, and Low-Latency HLS when the second leg needs to be quick.

• Expect delivery to sit at least three segments behind live.
• Use shorter segments, or Low-Latency HLS, to cut the delay.
• Put a cache or CDN in front of HLS when the audience grows past one port.

Frequently Asked Questions

What is the difference between RTMP and HLS?

Is RTMP or HLS better for live streaming?

Is HLS slower than RTMP?

Can I use RTMP and HLS together?

Does YouTube use RTMP or HLS?

What is low-latency HLS?

Do I need a CDN for HLS?

What is the best protocol for low-latency live streaming?