Cloudinary Blog

HTTP Live Streaming (HLS): a Practical Guide

 HTTP Live Streaming (HLS): the Good, the Bad, and the Awesome

Originally developed for Apple, HTTP Live Streaming (HLS) is a video-streaming protocol, supported by Android and other mobile platforms. HLS uses adaptive bitrate to adjust video quality to each viewer’s internet speed and device capabilities. Presently, HLS is mandatory for live streaming on certain mobile devices and most HTML5 video players.

In this article you will learn about the following topics:

What Is HTTP Live Streaming?

Again, HLS is a protocol that streams videos by means of an adaptive bitrate. Initially designed for Apple devices, HLS now works on other devices, including Android phones, Smart TVs, game consoles, and more.

You can deliver HLS videos through standard web servers or content delivery networks (CDNs). During that process, HLS automatically adapts the video quality to match the viewer’s Internet speed, smoothly delivering videos of any quality, from 8K (UHD) to 144-pixel ones.

Sign up for Cloudinary free today!

How Does HLS Work?

HLS streams videos by leveraging three components: video data, distribution channels, and client devices.

Video Data

HLS can stream videos from two primary sources:

  • Content servers for on-demand streaming
  • Real time video sources for live streaming

Before streaming can proceed, two processes must first take place, typically on a server before data distribution starts:

  • Encoding, whereby video data is formatted according to either the H.264 or H.265 video-compression standard, which enables devices to recognize and decode data correctly. This process also creates video copies with different quality levels.
  • Segmentation, whereby video data is divided into short segments of a standard length of six seconds. Afterwards, index files are created to specify the order and timing in which to play the segments.

Distribution Channels

Once encoded and segmented, videos can be streamed to viewers in direct response to requests made to a content server. Alternatively, streaming can occur through a CDN, with which you can more easily distribute streams across a geographic area and cache data for faster delivery to client devices.

Client Devices

Client devices receive and display video data on smartphones, laptops, desktops, smart TVs, and other connected devices. On receiving a video file, a client device determines the order in which to play the segments according to the index file. Additionally, based on the connection speed, local system resources and screen dimensions, client devices figure out which stream quality to adopt.

For details on streaming, see this post: The Future of Audio and Video on the Web.

Client Support and Latency

HLS is universally supported and is a common way to stream video to mobile devices, tablets, or HTML5 video players.

Traditionally , HLS latency was higher than that of other streaming options with up to a 30-second delay. In late 2019, Apple introduced an HLS low latency mode that provides sub-two-second latency for live streaming. Originally, low latency HLS required changes in the way publishers authored and served video streams, and special support by clients and CDNs. However, as of May 2020, low latency is an integral part of the HLS protocol.

What Are the Pros and Cons of HLS?

HLS offers the following benefits:

  • HLS’s adaptive-bitrate capabilities ensure that broadcasters deliver the optimal user experience and minimize buffering events by adapting the video quality to the viewer's device and connection.
  • Players can automatically adapt and adjust for changes in network speed, preventing stalls when the local connection is unstable.
  • HLS is natively supported on Microsoft Edge 12-18, Safari 6+, iOS Safari 3.2+, Android Browser 3+, Opera Mobile 46+, and Chrome for Android 81+.
  • It can be deployed on almost all other client devices via an HLS-compatible video player

Note the flip side of HLS:

  • Live-streaming with HLS is typically delayed by 20 to 60 seconds.
  • HLS has less impact on short-form videos. If you're planning to deliver 10 seconds clips, better use progressive download—a technique that lets you deliver a small part of the video file, and download the rest while the video is playing.

For buffering tips, check out this post: How to Implement Smooth Video Buffering for a Better Viewing Experience.

How Do Other Live-Streaming Protocols Compare to HLS?

To better understand HLS, have a look at how it stacks against the other live-streaming protocols. Below is a brief comparison of HLS and three of them.


Real-Time Messaging Protocol (RTMP), also known as Flash, was developed in the mid-2000s by Macromedia for streaming audio and video. Currently, RTMP is under the auspice of Adobe as a semiopen standard.

Previously the default streaming protocol for all delivery networks, RTMP still remains the standard for many broadcasters, because it is the de-facto protocol for inputting video streams from a camera or encoder. However, because Adobe Flash was commonly used to play RTMP on browsers, and modern browsers retired support for Flash, RTMP is losing relevance.

Many broadcasters use online video platforms (OVPs) or hosting services, which transform video streams to HLS, causing many CDNs to retire support for RTMP.

HLS Versus MSS

Introduced by Microsoft in 2008, Microsoft Smooth Streaming (MSS) also leverages adaptive bitrates for live streaming. Since it is proprietary to Microsoft devices, adoption of MSS is limited. The platform on which it is most widely used is the Xbox One game console.


Also bitrate adaptive, Moving Picture Experts Group-Dynamic Adaptive Streaming Over HTTP (MPEG-DASH) is the newest of the alternative protocols and the first HTTP-based international-streaming protocol. Thanks to this protocol’s codec-agnostic approach, you can play video with it almost universally, hence its standard acceptance. MPEG-DASH supports a range of formats, including H.264, H.265, VP8/9 and AV1.

For a tutorial on optimizing MPEG-DASH, see this post: Video Optimization, Part II: Multi-Codec Adaptive Bitrate Streaming.

How Do You Deploy Basic HLS?

This section describes how to deploy HLS. Before you start, ensure that the following requirements are in place:

  • A receiver in the form of an HTML page for streaming to a browser, or a client app for streaming to a mobile device or tablet.
  • A host in the form of a web server or CDN.
  • A utility for encoding your video source. That utility must be able to encode video in fragmented MPEG-4 or MPEG-2 TS files with H.264 or H.265 data, and audio files as augmentative and alternative communication (AAC) or Dolby AC-3.

For more information, check out Doug Sillars article on "How HLS Adaptive Bitrate Works"

Step 1: Create an HTML Page and embed video.js.

An easy way to get started with HLS is to embed a video player like video.js. Video.js is a lightweight player that is responsive and integrates with platforms like YouTube and Vimeo.

Add the code below to embed video.js on your page.

Copy to clipboard
  <link href="" rel="stylesheet" />

  <script src=""></script>

    <source src="MY_VIDEO.mp4" type="video/mp4" />
    <source src="MY_VIDEO.webm" type="video/webm" />
    <p class="vjs-no-js">
      To view this video please enable JavaScript, and consider upgrading to a
      web browser that
      <a href="" target="_blank"
        >supports HTML5 video</a

  <script src=""></script>

Step 2: Configure a Web Server.

Configure a web server from which to serve the video stream. As mentioned previously, any normal web server can serve this purpose. During configuration, associate your file extensions with the correct MIME type to identify data.

The following table shows which file extension is associated with which MIME type.

File Extension MIME Type
.ts video/MP2T
.mp4/.m4s video/mp4

A few tips:

  • To ensure compatibility, if your web server has MIME-type constraints, associate .m3u files with audio/mpegURL.
  • Be sure to optimize your files by compressing them. Since index files are often large in size and frequently redownloaded, compression makes a big difference. A good practice is to compress them before upload. Alternatively, set up real-time gzip compression on your server.

    Another issue with index files is caching. When streaming live broadcasts, index files are often overwritten. To ensure that you deliver the latest version, re-serve the index file with each request by shortening the time to live (TTL) of your files to properly cache the recent files. For video on demand, the index file stays the same so you can skip this step.

To learn about the progressive web, see this post: Media-Heavy Apps? Progressive Web to the Rescue.

Step 3: Validate Your Streams.

Before streaming media to viewers, validate your streams to ensure that the files play correctly and smoothly. One way of doing that is with the Media Stream Validator, which is part of Apple's HTTP Live Streaming Toolkit.

Media Stream Validator is a CLI utility for verifying local and HTTP URL files. It produces a diagnostic report on any errors or issues found. After adding files to your stream, always run this utility or a similar one as a safeguard.

Step 4: Serve Key Files Securely Over HTTPS.

Depending on your content, you might wish to set up streaming over secure protocols. You can do that with the Apple FairPlay Streaming software development kit (SDK) by directly serving files over HTTPS. Alternatively, serve media files over HTTPS, in which case you must encrypt them. You can do that with Apple’s file and stream segmenter tools by setting encryption options, including periodic encryption-key changes to put a lifecycle on your media, limiting access to a certain period of time.

Afterwards, decrypt your media files with an initialization vector. As with the keys, you can change initialization vectors periodically. For optimal protection, we recommend that you change your keys every three to four hours, and initialization vectors every 50 MB of the data that is streamed.

To protect your keys from being stolen and avoid your encryption efforts going to waste, transfer the keys over HTTPS or another secure method. This can be a tricky task, however, so test the keys internally over HTTP first. That way, if issues surface, you can resolve them before adding HTTPS.

Following are the preliminary requirements for setting up HTTPS key serving:

SSL Certificate

Verify that a signed SSL certificate is on your HTTPS server. If not, obtain and install a valid certificate from a paid or free provider.

Depending on the certificate service you use, either run a certificate client, such as Certbot, or install the certificate directly. For the latter option, be sure to also install your intermediate or leaf certificate so that users can verify the root certificate.

Authentication Domain

Verify that the authentication domain for your key files matches the domain for your first playlist file. Such a setup enables you to serve your playlist file from your HTTPS server and your other files from HTTP. Since the files cannot be played correctly without the playlist, your videos are secure to an extent.

Next, set up a way for viewers to authenticate themselves. You can do that by building a dialog or a system for storing credentials on the client device. HLS does not offer dialogs so if you pick that option, build a dialog yourself.

For details on HTTP security, see this post: Why Isn't Everyone Using HTTPS and How to Do It With Cloudinary.

How Does Cloudinary Help You Set Up HLS?

With HLS, you create many video copies or video representations, each of which must meet the requirements of various device resolutions, data rates, and video quality. Additionally, you must do the following:

  1. Add index and streaming files for the representations.
  2. Create a master file that references the representations and that provides information on and metadata for the various video versions.

That’s a load of grunt work for even one video. Turn to Cloudinary, which automatically generates and delivers all those files from the original video, transcoded to either HLS or MPEG-DASH, or both of those protocols. Called “streaming profiles,” that feature enables you to configure adaptive streaming processes. You can customize the default profile settings to satisfy your requirements. Once those settings are in place, Cloudinary automatically handles all the drudgery for you.

For details on streaming profiles, see the following:

Other resources are our interactive demos, our FAQ page, and the Cloudinary community forum.

Above all, try out this superb feature yourself. Start with creating a free Cloudinary account.

Want to learn more about HTML5 Video Players?

Recent Blog Posts

The Pros and Cons of AVIF for Websites

AVIF is a 2019 spinoff from the AV1 video format developed by the Alliance for Open Media (AOM), whose members include Amazon, Apple, ARM, Facebook, Google, Huawei, Mozilla, Microsoft, Netflix, and Intel. As an open-source and royalty-free video codec, AVIF delivers much higher compression rates than the older image codecs like JPEG and WebP, and is on par with the brand-new JPEG-XL format, which does not work on any browser yet.

Read more
Get Your Media Moving Faster with Cloudinary’s Media Optimizer

So, your boss comes to you in a panic: he's just heard about Google's Core Web Vitals initiative and needs you to optimize the company website right now! "No problem," you say, hiding your fear that it's not something that can be done overnight. Just taking the first metric, Largest Contentful Paint (LCP), how can you possibly identify all the large elements - most likely images or video posters - of the many hundreds of pages that make up your site? There are already thousands of high-resolution (read massive) media files stored away, which marketing could use any time. How are you going to make sure they're all compressed to a size small enough to be delivered within the threshold? Not to mention all the new images and videos that will be created over time...

Read more
How to Tap Into the Value of User-Generated Content (UGC)

User-generated content (UGC) took off with, first of all, the advent of the internet and, subsequently, social networks. Everyday consumers were given keys to the kingdom, so to speak, so that they, too, could compose and post content, simultaneously engaging with others online. Twitter, Facebook, Instagram, Snapchat, TikTok—the networks through which we can create and publish content have grown exponentially, and brands are becoming aware of the benefits of tapping into the gold mines offered by those networks.

Read more
Identifying Countries by IP Address in Columnar Databases Through SQL

Cloudinary reaps a myriad of open web traffic, from ad networks to e-commerce sites. Our Data Science team is dedicated to analyzing the data for use internally and externally.

A glance at any General Data Protection Regulation (GDPR) article would reveal that—unlike Android device IDs (AID), through which users can reset their web address—keeping user identifiers, such as Internal Protocol (IP) and Media Access Control (MAC) addresses, as well as International Mobile Equipment Identity (IMEI), violates privacy. As a solution, you can discard all privacy identifications or make them visible to users for reset.

Read more
Digital-First Asset Management Explained

As the world changes, so does technology. I don’t need to name more than a handful of antiquated technologies before you nod in agreement: floppy disks, Walkmans, phone booths, VHS tapes, each of which have been phased out or rendered useless by new solutions that meet the same need but much more effectively.

Read more