HESP vs HLS vs MPEG DASH: Which One is Best For Your Live Streaming Business

If you are a regular live streamer, you are well aware of the menace of streaming protocol fragmentation. HLS and MPEG DASH (also known as MPD or simply DASH) are popular streaming protocols that are frequently used for on-demand and live video streaming. But with the entry of the new HESP streaming protocol, the contest has intensified. So, it is natural to get confused while picking one out of the three. 

While all of them have their own strengths and weaknesses, choosing one should always depend on your specific business needs. We are here to help you out in this process! 

In this blog, we will tell you everything about the new HESP protocol, compare and contrast it with HLS and DASH protocols, and help you decide which one would suit your business. So, let’s get started! 

What is HESP? – High-Efficiency Streaming Protocol

HESP stands for High-Efficiency Streaming Protocol. This streaming protocol is specially designed for HEVC video and uses a number of features to improve the performance of the HEVC Streaming Progressive, like adaptive bitrate streaming, error resilience, and ultra-low latency live streaming. 

So, before understanding HESP, we will have to know about HEVC and HEVC Streaming Progressive. HEVC is an advanced standard for encoding video files. It is more efficient than the previous standard, AVC (Advanced Video Coding). 

HEVC Streaming Progressive is a form of video streaming that uses the HEVC standard of video encoding. It can deliver high-quality video at lower bitrates. This makes it ideal for streaming video over slow or unstable networks.

And since HESP is made for HEVC codec, it clearly shows similar characteristics. If we have to define it technically, the HESP streaming protocol is an HTTP-based adaptive bitrate streaming protocol. It can stream videos at ultra-low latency with a maximum latency of 2 seconds and minimum latency of 0.4 seconds while showing good bitrate flexibility. Let’s understand it’s working in detail. 

How HESP Handles The Video Stream?

HESP is quite unique because it uses two video streams, instead of a single stream like the other two protocols. The first one is called the “Initialization Stream”, while the second is called the “Continuation Stream”. The Initialization stream is a collection of Key Frames, while the Continuation stream is like a normal encoded stream that all the other protocols use. 

Now you must be thinking what is a Key Frame? Different forms of video frames are used during the video compression process of encoding, but there are four major types of video frames:

• I-Frame: The I-Frame contains your whole image without reference to any other frame. 

• Key Frame: Key Frame is a sub-type of I-Frame, where it itself is the last reference frame. This means that no frame after this frame can reference any frame before the Key Frame.  

• P-Frame: P-Frame contains only the changes with respect to the previous frame. 
• B-Frame: It contains the changes in the current frame with respect to the previous and the upcoming frame. 

Now coming back to the HESP streams. Since the Initialization Stream contains only the Key Frames, it is used to start the stream. Also, when the viewer changes the position of the video playback, this stream is used, as it can instantly decode the frame and restart the playback. 

When the video playback starts, the first frame is pulled from the Initialization Stream. But once it has been successfully decoded and played, the player automatically starts pulling the frames from the second stream, which is the continuation stream. Due to this process, the player takes very little time to start or restart any stream in HESP. 

How It Works

HESP can easily scale over any standard CDN. So, the raw audio/video input received from the source is transported to the cloud, where an SRT receiver receives it. The received raw video file is passed through an ABR transcoder, that breaks the video into smaller chunks and converts them into multiple bitrates. These smaller chunks then enter the HESP package. 

You can even link it to any standard DRM. In doing so, the video will get encrypted and hence can be decrypted using the DRM decryption key only. So, unauthorized users will not be able to access it. 

Finally, the processed video file gets delivered to an HESP-supported player over a HESP-supported device and browser, from which the end-users can access the video. 

Pros

• Can stream videos in ultra-low latency. 
• Supports adaptive bitrate streaming. 
• Supports DRM and works well with CDN.

Cons

• Not supported by many devices.
• It is technically a bit more complicated than HLS. 

What is HLS and LL-HLS?

HLS stands for HTTP Live Streaming. It is currently the most popular and most widely used live-streaming protocol across the globe. A major reason for its popularity is its immense device and browser support. It can literally function in almost any browser and any device. 

If we go back to history, HLS was actually developed by Apple in 2009 to solve one major problem. The previous protocol WebRTC was a peer-to-peer streaming protocol, which means one device could directly connect to the other device without going through the internet. But that made it unscalable. So, Apple wanted to create an HTTP-based streaming protocol that would be immensely scalable. 

Thus, HLS came into existence. While creating it, Apple was only thinking about scalability, and in this pursuit, latency got ignored to the extent that when the protocol was finally operational, a minimum average latency of 15 seconds, which could even go up to 1 minute in worst cases, was observed. 

To solve this latency problem, Apple finally came up with an extended version of HLS, called the Low-Latency HTTP Live Streaming Protocol, or LL-HLS in 2020. This LL-HLS protocol functions almost similarly to the HLS protocol, with some small modifications. Let’s study the working of HLS and LL-HLS in our next section. 

How Do HLS and LL-HLS Work?

An HLS stream originates from the source where the live content is being created. This source video stream (primary playlist) is then converted into multiple encoded video files with different bitrates. These encoded files (media playlists) are finally segmented into smaller chunks, for adaptive bitrate streaming. The process has been explained in the diagram given below.  

In the case of LL-HLS, the base process remains the same, with some minor modifications like

• A segment is further divided into partial segments. These partial segments are only a few milliseconds long and are referenced in the media playlist. 
• A “preload hint” tag is added to the media playlist. These tags act as a “hint” for the player and let them know that the partial segments are coming so that the player starts requesting them instantly without waiting. 
• The block playlist reloads feature ensures that the player receives a response from the server only when a new segment or partial segment is available. 

HESP vs HLS 

HLS, one of the oldest live-streaming protocols, is widely supported by all types of devices. It is easiest to set up and use. It supports live streaming at lower internet bandwidths. Hence, viewers sitting in remote areas with poor internet connectivity can still stream the HLS videos without any buffering, as the video bitrates get auto-adjusted to suit the available bandwidth. It also lets the user choose the suitable video quality as per their needs. 

Hence, when compared to HESP, HLS is more suitable for users who want wide device support. As HESP is a new protocol, many devices do not yet support it. Also, HLS is a bit simpler to set up and use, when compared to HESP. 

HESP vs MPEG DASH

MPEG DASH is referred to as Dynamic Adaptive Streaming over HTTP because it is by far the most flexible HTTP-based adaptive streaming protocol. Hence, it can easily beat both HLS and HESP in this parameter, as it offers immense control and flexibility over the video quality and bitrate.

However, it is also the most complicated protocol to implement and offers lesser device support when compared to HLS, though still higher support than HESP. 

Comparing HESP vs HLS vs DASH

Let’s compare HESP vs HLS vs MPEG DASH based on different live streaming parameters, to understand which one performs better for which use case. 

Considerations for Live Streaming Businesses

Before choosing the live streaming protocol, you must understand your business needs. Usually, every live streamer has to think of the following considerations:

• The type of video content you are going to stream, like whether you are streaming live news or sports broadcast, live music concerts, or normal live videos. 
• The target audience for your videos, their geographical location, and availability of internet bandwidth in their locality. 
• The devices that your viewers are expected to use to stream these videos. 
• The bandwidth of your streaming server. 

Based on the answers to these considerations, you will be able to decide the best streaming protocol for your live streaming business, as explained in the next section. 

Which Protocol is Best For Your Live Streaming Business?

If you are looking for a protocol that can stream your live videos in real-time, and offers ultra-low latency (as in the case of news or sports broadcast), then you might be tempted to incline towards HESP. However, you will still have to remember that HESP will be supported on a very small number of devices. 

But if you use MPEG DASH, which also offers all the good properties of HESP like excellent adaptive bitrate flexibility and ultra-low latency streaming, you will also get the benefit of wider device support! Hence, your news and sports broadcasts will now reach a larger audience in real time. Also, MPEG DASH offers more control over video quality, and hence, the audience sitting in remote areas can decide to stream the videos at a lower bitrate. 

Finally, if you are looking for a protocol that is easy to implement, but can still offer adaptive bitrate streaming and is supported by almost any device, then you must use HLS. HLS ticks almost all the boxes perfectly, with only one drawback – latency. But, if you are streaming music videos or random videos where latency does not really matter, you should go with HLS without any second thought. 

To Sum Up

In this blog, we compared HESP vs HLS vs MPEG DASH to see how they perform under different parameters. In the end, the best streaming protocol will depend on your specific streaming needs. 

If you need a protocol that is easy to implement and widely supported, then go for HLS. If you need a streaming protocol that can deliver high-quality video at low bitrates with ultra-low latency, then HESP is ideal for you. But if you need a protocol that offers ultra-low latency, and adaptive bitrate along with more control over the video quality and bitrate, you can try MPEG-DASH. 

And if you are looking for a perfect live streaming platform that supports both HLS and MPEG DASH, offers built-in support for Adaptive Bitrate Streaming and DVR-Enabled Live Play, with multi-DRM security and built-in CDN network, Muvi Live is the one for you! At Muvi Live, you get 100+ industry-leading features out-of-the-box, and can live stream from your mobile device too! So, why wait? Start FREE by signing up today! 

FAQs

What is HESP, and how does it differ from HLS?

HESP, or High-Efficiency Streaming Protocol, is specially designed for HEVC video and uses a number of features to improve the performance of the HEVC Streaming Progressive, like adaptive bitrate streaming, error resilience, and ultra-low latency live streaming.

It is a bit more complex than the HLS streaming protocol.  

Which streaming protocol is best for live streaming with real-time ultra-low latency?

Both HESP and MPEG-DASH are good, but MPEG-DASH supports a greater number of devices. 

What is HEVC, and how does it relate to HESP?

HEVC is an advanced standard for encoding video files. HEVC Streaming Progressive is a form of video streaming that uses this standard of encoding. HESP is a streaming protocol designed to enhance the quality of HEVC Streaming Progressive.