Comparing the two most known and used adaptive HTTP Streaming Technologies: Apple’s HLS and MPEG-DASH.
May 15 2018
Published by Lorcan Možiš
Adaptive HTTP Streaming Technologies: HLS vs. DASH
You’re into Live Streaming and don’t know weather to use HLS or DASH? You’re new to the Live Streaming and want to get to know about the technical side behind it?
Maybe this article will help you with your decision or giving you an insight to the technical side.
The industry of adaptive HTTP streaming technologies is currently led by Apple with HTTP Live Streaming (HLS) and the internationally standardized Dynamic Adaptive Streaming over HTTP from MPEG, MPEG-DASH. There is also Microsoft Smooth Streaming (MSS) and HDS, HTTP Dynamic Streaming, from Adobe. As already mentioned, HLS and DASH are currently market leaders, which is the reason why this article deals only with these two adaptive HTTP streaming technologies.
Instead of using a single video file, HLS separates a video into many small parts. As video codec you have to use H264 to encode the normally 10 seconds long .ts files. A separate .m3u8 file then links to these chunks. This text file, specially formatted for HLS, also contains metadata about the stream. It is extremely important that a .m3u8 file can link to other .m3u8 files. Thus, only the current .ts chunks will be loaded into the video player (link to HTML5 Video Player Comparison Blog?) and can be displayed.
The video quality can be automatically adjusted if the available bandwidth is too low. For example, if a user watches a stream in the highest video quality and the system notices that the download of a .ts chunk takes longer than its playback length, the video is automatically resumed in the next lower quality. This prevents the video from constantly having to buffer.
Because HLS was developed by Apple, it is currently the only method that supports video streaming on iOS devices (iPads and iPhones).
Similar to HLS, DASH splits a large video file into many small sections. These are normally slightly shorter than the HLS standard of 10 seconds, namely only 2-4 seconds. Unlike HLS, DASH does not require a specific video codec, so the successor version H265 can be used instead of H264. Instead of a .m3u8 file, DASH uses a so-called media presentation description file (.mpd) as a manifest. Its functionality is the same as that of a .m3u8 file.
Unlike HLS, there is no universal DRM solution for DASH. DASH requires Widefine from Google and PlayReady from Microsoft to deliver video content.
Feature Comparison HLS vs. DASH
Now let’s compare some features of HLS and DASH. These, of course, do not give a hundred percent statement about the usability of the corresponding software, but are intended to provide a brief overview.
Both HLS and DASH can be used on regular HTTP servers such as Nginx, Apache and similar.
Especially with multilingual content, it is important to be able to switch between different audio channels of the individual languages. This is possible with both DASH and HLS.
To add subtitles to a video, a separate file is usually created, which can have the WebVTT format, for example. This is then referenced from the manifest (i.e. the .m3u8 or .mpd file).
In general, it is possible to insert advertising into a live stream at both HLS and DASH. To do so, individual video chunks are simply exchanged. DASH provides an effective method for this: A standardized interface allows advertising to be inserted effectively.
How quickly you can switch between individual channels depends on the largest of the sub-segments (chunks). The smaller the chunks, the faster a channel can be changed. As already mentioned in the introduction, chunks are usually about 10 seconds long with HLS, whereas they are usually 2 to 4 seconds long with DASH. So DASH is one step ahead in this respect.
Small chunks also have the disadvantage that they reduce the efficiency of the code. Playlists with small chunks have to be updated more often than playlists with larger chunks. This means that playlists containing shorter video segments must be updated more often by an HTTP request.
HLS and DASH have their advantages and disadvantages. HLS is the older product and has slightly fewer features than DASH. But DASH doesn’t offer iOS support and so it depends on what kind of live stream you want to offer yourself. Before you decide on one of the two adaptive live stream technologies, you should first consider which features you need and which audience you want to reach.
Of course, you can also use both services, but you need twice as much storage space as the content has to be encoded twice. It also states that DASH may soon be subject to a charge. This would speak against the use of DASH and for the use of HLS.
At Strive, we use HLS by default because a unified DRM solution can be used and the full range of viewers including iOS users is covered. On request we are also able to realize your live stream with the help of DASH.
Subscribe to our awesome newsletter to be always up to date about our latest news.