What is HLS Streaming? HTTP Live Streaming Explained

Over the past two decades, the media industry has undergone a significant transformation, introducing a wave of new concepts and technologies such as OTT, streaming, connected TV, DASH, and HLS. Even as a streaming media professional, I often find myself going back to the basics; searching for clear definitions and practical explanations of these evolving terms. This blog aims to provide a simple and practical introduction to one such concept: What is HLS?

What is HTTP live streaming (HLS)?

HLS is an adaptive bitrate streaming protocol developed by Apple back in 2009 originally for devices in the Apple ecosystem. This streaming protocol delivers audio-video segments over standard HTTP connections with latency from 10 to 30 seconds. Although it is called HTTP live streaming, it is used for both on-demand video streaming and live streaming.

A major advantage of HLS is its adaptive bitrate streaming. On the server side a stream can be encoded/transcoded in multiple renditions at various bitrates. When a client (HLS player on an end user device) requests content from the server, the player selects the most suitable video rendition in real time. The player also keeps a buffer of segments in case it loses network connection, minimizing disruptions for the end user. This adaptive bitrate streaming keeps playback stable, even when network conditions change.

How Does It Work?

Let’s take a deeper look at the end-to-end process a media asset goes through to be delivered as an HLS stream:

1. Ingest: Let’s say you have a camera setup (live streaming) or standalone media content file on a local device (VOD) which will be considered as original media content. This content can be in 1080p or 4K (aka 2160p) available to you at the highest bitrate.
2. Encoding/ Transcoding: A software or hardware encoder creates variants of the original media content as per the requirements. Usually this involves settings related to codecs (i.e AV1, H264, H265 for video, AAC or AC3 for audio), bitrates, frame rates, resolutions etc. Sometimes original media content needs to be transcoded i.e. converting one codec to another for compatibility reasons. For example, if the original media content is 4K with 5.1 AAC audio, then the encoder will create renditions of video at 480p@500kbps, 720p@1Mbps, 1080p@2Mbps, 2160p@8Mbps and audio at 2ch AAC@64kbps, 5.1ch AAC @256kbps and 2ch AC3@128kbps. The encoding process also involves other settings that need to be considered such as GOP, GOP size, frame rate, keyframe, sample rate for audio etc.
3. Packaging: An extension to encoder is called packager (also referred as segmenter). This packager considers media content’s frame rate and GOP size during segmentation into smaller segments (2 to 12 seconds long). These video segments files (.ts or .mp4) are indexed by a manifest file. The packager creates manifest files for every rendition/variant (i.e one each for 480p, 720p, 1080p & 2160p) and in the end it creates a master manifest file aka playlist file which refers to all the variant manifest files. For HLS, the manifest files are created with the .m3u8 extension.

Commonly, these packaged files (manifests and segments) are stored on the origin server and pushed out to the client over the internet (using HTTP protocol) when the player requests the content from the server. Typically, a content delivery network (CDN) will help distribute this packaged content.

The client requests the content master manifest URL (from a content delivery network) when an end user hits the play button on the HLS player. The client then selects a variant to play depending on the network bandwidth and fetches variant manifest (aka index) file as a reference for assembling the audio-video segments in order and it switches from higher quality to lower quality picture (and vice versa) as needed (depending on device display size, network bandwidth availability, etc).

In some use cases I have seen, HLS is combined with WebRTC to support both scalable playback or VOD delivery with real-time interaction. These workflows rely on switching between protocols depending on the viewing experience required. Emerging technologies like MOQ (Media over QUIC) are expected to provide these capabilities under one roof while simplifying the overall architecture.

When and Where Can You Use It?

HTTP live streaming is a widely compatible, scalable, secure and reliable egress streaming protocol, making it a strong fit for workflows where video and audio need to be delivered to massive global audiences and latency is not critical.

For example, HLS is commonly used in video-on-demand (VOD) workflows because of its broad compatibility across platforms, browsers, and devices. It is supported by major streaming platforms and ecosystems such as Netflix, Amazon Prime, Roku, Apple TV+, etc.

Benefits & Drawbacks

Benefits of HLS:

1. Compatibility: Can be used on all types of devices and platforms.
2. Adaptive bitrate streaming: Adapts to the varying network/bandwidth situations.
3. Scalability: With the help of CDN, events can be streamed worldwide.
4. Secure: Support encryption (AES-128, FairPlay) of the content and hence restricts unauthorized access.
5. Accessibility: Support closed captions, alternate audio tracks, audio description, etc.
6. Monetization: With support of advertising integration such as SCTE markers, Ad Interstitials, Discontinuity flags etc HLS can be used to monetize streaming.

Drawbacks of HLS:

1. Latency: Standard HLS has latency around 10 to 30 seconds which is not ideal during live streaming
2. Storage costs: Multiple renditions and segmentation increases costs.
3. Content creation complexity: Higher computational load due to encoding overheads.

HLS Video Streaming Compatibility

Over the past decade, I’ve worked extensively with HTTP live streaming as the de facto streaming protocol across a wide range of use cases, and it has consistently delivered reliable, high-quality performance. Based on this experience, it’s clear that HLS offers broad compatibility across:

• Platforms: Apple, Android, Roku, Amazon Fire, Sony PS, Microsoft Xbox, Comcast Xumo, LG WebOS, Samsung Tizen, etc.
• Video Codecs: H264, H265, AV1, MPEG 2, HDR, HDR10+, Dolby Vision etc.
• Audio Codecs: AAC, HE-AAC, Dolby AC3, Dolby EC3, Dolby Atmos, etc.
• Container Formats: MPEG-TS, fmp4 (CMAF/ .m4s/ .m4a) etc.

Does HLS Use TCP or UDP As Its Transport Protocol?

TCP and UDP are transport protocols responsible for delivering data over the internet. HLS operates over HTTP, which in turn relies on TCP, leveraging its reliable and ordered delivery mechanism to transport video segments. This ensures that all segments arrive intact and in sequence, minimizing packet loss and preventing video corruption; prioritizing playback stability and quality over raw speed. In contrast, UDP, which is used by protocols such as SRT and WebRTC, offers lower latency but does not guarantee delivery, making it more prone to packet loss.

Because HLS is delivered over HTTP, it behaves like regular web traffic, allowing it to seamlessly traverse firewalls and work across standard internet infrastructure. While UDP-based protocols are faster, TCP’s reliability makes it better suited for HLS’s segmented delivery model, where consistent and complete delivery of each segment is critical for smooth playback.

HLS vs. Alternative Streaming Protocols

If you’re choosing a live streaming protocol for your application and weighing different options, the best approach is to compare them side by side to see which one fits your use case best. Below, I’ve covered the protocol comparisons developers ask about most often.

HLS vs RTMP

HLS is primarily an egress/playback protocol, whereas RTMP is mainly used for ingest and contribution workflows. HLS is optimized for content delivery and is rarely used for ingestion. It relies on segments and manifest playlists, which introduce higher latency but enable massive scalability through CDN-based distribution.

RTMP, on the other hand, offers lower latency and was once widely used for both ingest and playback during the Adobe Flash era. However, as Flash declined, playback shifted toward HTTP based live streaming protocols such as HLS. Today, RTMP continues to be commonly used for contribution and encoder-to-platform ingest workflows, while HLS remains the dominant protocol for large-scale playback across modern streaming devices and platforms. Read a detailed HLS vs RTMP comparison in our previous blog.

HLS vs WebRTC

HLS is a streaming protocol designed for scalable streaming, whereas WebRTC is a broader real-time communication framework composed of multiple protocols, codecs, and JavaScript APIs that enable ultra-low-latency peer-to-peer communication. HLS follows a client-server delivery model over TCP/HTTP, which results in higher latency but provides reliable playback and seamless scalability through CDNs.

WebRTC, on the other hand, is primarily UDP-based and optimized for real-time interaction, enabling sub-second latency for applications such as video conferencing, live collaboration, and interactive streaming. While HLS scales efficiently to millions of viewers using CDN infrastructure, scaling WebRTC can be significantly more complex due to its peer-to-peer communication architecture and real-time processing requirements. See our previous blog for a detailed comparison of HLS vs WebRTC.

HLS vs DASH

HLS and MPEG-DASH (Dynamic Adaptive Streaming over HTTP) are both HTTP-based streaming protocols that deliver high-quality audio-video over the internet using CDN. HLS, developed by Apple, is essential for Apple ecosystem compatibility, while DASH is an open-standard, codec-agnostic alternative commonly used for Android and web browsers.

HLS vs LL-HLS

LL-HLS is an extension of standard HLS designed to significantly reduce streaming latency. Traditional HLS typically uses segment durations of 2 to 12 seconds, which contributes to higher end to end latency. LL-HLS improves this by introducing partial segments, often less than one second in duration, reducing latency to approximately 2-3 seconds. In addition to lower latency, LL-HLS optimizes data transfer by delivering incremental playlist updates and smaller media chunks, making it more efficient than traditional HLS, which relies on larger segments and full playlist refreshes.

HLS vs MOQ

MOQ is an emerging open standard being developed by the IETF to unify real-time, sub-second, and on-demand video within a modern next-generation live streaming protocol. Because it relies on UDP, MOQ can achieve sub-second latency, though it is also more susceptible to packet loss. In contrast, HLS uses reliable TCP-based delivery, which comes with higher latency trade-offs. HLS distributes content through a client-server model over CDNs, while MOQ uses a publish-subscribe approach over QUIC relays. Although MOQ is still in its early stages, the media industry is actively exploring it as a potential next-generation solution for real-time content delivery.

Does Red5 Support HLS?

Depending on your level of control and customization needs, you can live stream video and audio with HLS streaming protocol with wide device support, adaptive bitrate, and massive scalability through CDNs, with latency from 20 to 60 seconds to millions of viewers, we have got you covered. Visit our demo page, connect your camera and microphone, and experience HLS playback for yourself. Then read “How to Use HLS Streaming with Red5 Pro and Red5 Cloud” blog.

1. Red5 Cloud

If you want a fully managed, globally distributed streaming solution with an intuitive dashboard, Red5 Cloud is the easiest place to start. Sign up with no credit card required and get the free tier every month:

• 50 GB of streaming.
• 6,000 instance hours.
• Hosting in US Central.
• Access to documentation and email support.

Once you reach the 50 GB monthly limit, you can:

• Continue streaming immediately with our usage-based pricing model, Pay-As-You-Grow, at $0.08 per GB and $0.69 per instance hour. No monthly minimums and no fixed commitments.
• Or wait until the next monthly cycle for your free 50 GB to reset.

Check out this Youtube playlist to get started with Red5 Cloud.

2. Red5 Pro

If you need full customization, maximum flexibility, and complete control over your infrastructure, choose Red5 Pro, our server software built for ultra-low latency streaming at scale. Start with a 30-day trial and get access to all capabilities without limitations.

Learn more about HLS egress support in Red5 Pro and HLS plugin in our documentation.

Choosing the Right Setup

Not sure which solution is the best fit for your streaming challenges? Visit our product comparison page or contact us to discuss your project.

Conclusion

So if you ask me “what is HLS”, I would say a widely adopted HTTP-based adaptive streaming protocol used to deliver audio-video reliably across devices by breaking content into small segments and dynamically adjusting quality based on network conditions. Its scalability via CDNs and broad compatibility make it the backbone of modern streaming workflows.

FAQs

What does HLS stand for?

HLS stands for HTTP Based Live Streaming. It is a streaming protocol developed by Apple in 2009 and primarily used for content delivery. It distributes segmented video to viewers across browsers, mobile devices, and smart TVs with broad compatibility. Because it is optimized for playback rather than contribution, it is rarely used for ingest workflows. Its reliability and scalability make it well suited for reaching large audiences.

Which browser supports HLS?

HLS is natively supported across the Apple ecosystem through the built-in AVPlayer framework, including playback in Safari browsers. On other modern browsers such as Microsoft Edge, Google Chrome, Firefox, and Brave, HLS is not natively supported but can be played using HTML5-based players (e.g., via JavaScript libraries like hls.js) that enable compatibility.

Is Netflix HLS?

Yes, Netflix uses HLS for delivery specifically on Apple devices because of native playback support. While HLS is used for compatibility across many devices, Netflix also heavily uses MPEG-DASH as a primary, standardized protocol. For live content, Netflix uses HLS with CMAF to ensure reliability across devices.

What is an HLS Stream?

HLS Stream is a package created after encoding-transcoding-packaging. Many software/hardware tools create this package which usually consists of a master manifest file (aka playlist file), variant manifest files, audio-video chunks etc.

What is an HLS Playlist Link?

For delivery, HLS typically relies on CDNs to scale efficiently. To make content available, the HLS stream (packaged assets) is hosted on a CDN. Once published, the CDN URL pointing to the master manifest file (also known as the playlist) serves as the HLS playback URL, which client players use to request segments and start streaming the content.

How to stream with HLS for free?

You can start streaming with HLS right away using our fully managed, globally distributed streaming PaaS solution, Red5 Cloud. No credit card is required to sign up, and you’ll get 50 GB of streaming free each month. If you need more flexibility in deployment, you can also begin a 30-day free trial with Red5 Pro to explore custom setups.