Dash Hls Comparison Essay
Through applications such as Google’s Shaka Player or the DASH-IF JS player, MPEG-DASH allows a single video format to be displayed on any device. It provides support for devices from mobile phones to hybrid broadcast/broadband television (HbbTV). It is a native ABR scheme, ensuring that the best quality is always achieved for a given bandwidth. This article is a section of a detailed white paper on server-side ad insertion recently released by Elemental Technologies.
MPEG-DASH is codec-agnostic. Because HEVC is fully compatible with MPEG-DASH, high performance compression can be used to maximize quality, or can be used as a common platform to deliver 4K Ultra HD. In 2014, IBC honored the Vienna State Opera with a special award for its 4K UHD streaming using HEVC encoding and MPEG-DASH delivery.
MPEG-DASH also hosts common encryption (CENC), an emerging standard that uses the encrypted media extensions (EME) defined in HTML5 to provide the digital rights management (DRM) decryption in the player. This in turn allows a common encrypted file to be delivered by MPEG-DASH, whatever the DRM system used in the player.
However, MPEG-DASH is not the only solution currently available. For Apple hardware and a number of other very popular devices, the rule is to use Apple HLS protocol for ABR streaming.
HLS is a very mature technology and is implemented in a wide range of manufacturers’ devices beyond Apple, even though that in and of itself is a major market. There are third-party players available, such as THEOplayer from OpenTelly or Flowplayer, which do not require any plug-in for HLS playback, making them widely applicable.
On the other hand, HLS is a proprietary technology, developed by Apple and other private companies. It has not changed much since its launch ten years ago and is very stable – or getting outdated, depending on your point of view. As a proprietary standard, it carries some risk of obsolescence.
Contrast that with MPEG-DASH, which is developed by the very long-standing and independent MPEG forum. The MPEG forum continues to develop the standard and will undoubtedly develop new MPEG formats in future. The ubiquity of MPEG formats will almost certainly see DASH support in all browsers, most mobile devices, set-top boxes and smart TVs.
MPEG-DASH can deliver substantially lower end-to-end latency compared to HLS. It also uses a templated manifest that can be cached at the edge, while an HLS manifest is updated routinely and needs to be propagated several times a minute.
The one significant philosophical difference between the two is that MPEG-DASH is open to a range of encryption solutions, whereas HLS only supports its own DRM. To provide heavy duty content protection in HLS means wrapping the streams in another technology that can be interpreted by the receiving device. CENC common encryption technology is the usual solution to this issue.
HLS and MPEG-DASH share much in common, though, in the philosophy of how content is presented through manifests or playlists, and how video content is sliced into small chunks. The architecture and the underlying protocols are what allow server-side ad insertion without recourse to complex proprietary extensions. This therefore allow users to build open infrastructures while retaining the benefits of advanced capabilities.
Finally, to be fully exhaustive, there are other ABR protocols in the field, like Smooth Streaming from Microsoft and HTTP Dynamic Streaming (HDS) from Adobe. These two streaming formats have less flexibility in the way manifests are generated, and while they can also be used for server-side ad insertion with static ad replacement, it is much more complex to deal with personalized server-side ad insertion.
Client-side ad insertion
High-value streaming video content can attract large volumes of viewers, and responding effectively to peaks in demand is essential. It requires the ability to scale video delivery seamlessly while maintaining performance and the best quality of service.
Sporting events, for example, can create enormous demand. During the 2014 FIFA World Cup in Brazil, as many as three million consumers a day worldwide used online video services provided by the host broadcaster. Twenty-four million unique users watched tens of millions of hours of content online during the tournament. The peak streaming rate – during the Argentina v. Netherlands game – was 6.9 terabytes per second.
The advantage of client-side advertising is that program content can be encoded and packaged in all the different formats, in advance. When a request comes from a consumer, all that happens is that the appropriate file is played out from a server.
Server-side ad insertion
Server-side advertising depends fundamentally upon just-in-time packaging; the content is stored in some suitable high-quality delivery format and packaged for delivery at the time it is requested. This has other benefits for the operator, including reduction of storage and bandwidth costs by delivering content best suited to network conditions, and the target device, at the moment of delivery.
To cope with fluctuations in demand for just-in-time server-side ad insertion, a highly scalable architecture is required. Demand will inherently vary over time, but for broadcasters, there will inevitably be sharp peaks: a breaking news story, or the return of a highly popular television series.
The solution lies in encoding and packaging that can be virtualized for rapid deployment and hosted in a cloud infrastructure for immediate auto-scaling. Dedicated single path hardware encoders and packagers lack flexibility. The only practical solution is to spin up instances of software-based video processing as they are needed.
Further, for dynamic server-side advertising insertion, the best place to prepare the content stream is at the edge, as close as possible to the consumer. This implies a cloud service. In the 2014 World Cup example quoted above, the encoding and packaging used Elemental software hosted on Amazon Web Services. The cloud is required to create millions of individually tailored manifests of content and advertising, even for live streamed events.
That, in turn, demands a flexible architecture to manage requests and determine where best to create output streams. A manifest must be created and manipulated according to the rules and demands of the advertising management provider. Instructions must be delivered to just-in-time encoding and packaging software, wherever it is. Finally, a single contiguous stream is sent to the client.
Lionel Bringuier is Director, Product Management, Video Delivery Solutions for Elemental Technologies, an Amazon Web Services Company.
The benefits of DASH
There exist multiple standards for adaptive streaming over HTTP, the most popular of which are HTTP Live Streaming (HLS), SmoothStreaming and Dynamic Adaptive Streaming over HTTP (DASH). Whilst HLS is the most widely used of these three standards today, it’s important to note that it has major disadvantages compared to both DASH and SmoothStreaming. Here we touch on just two of them.
- HLS requires that video is packaged in the M2TS transport stream; a format that was designed for broadcast TV rather than for streaming content over the internet. Conversely, both DASH and SmoothStreaming use the fragmented MP4 (fMP4) container format, which was designed specifically with streaming content over the internet in mind. M2TS has many inherent disadvantages compared to fMP4, both for servers and clients, some of which are summarized by Timothy Siglin’s excellent white paper.
- All three standards divide media into small chunks, and allow clients to switch between different qualities (typically based on the available bandwidth) by having them stop downloading chunks of one quality and start downloading chunks of another. DASH and SmoothStreaming with fMP4 both require that chunk boundaries are aligned across the different qualities, and that each chunk starts with a keyframe. This allows seamless switching from one quality to another without ever having to download overlapping chunks in multiple qualities. Unfortunately, the same cannot be said for HLS. HLS does not require that chunks start with keyframes, and so to seamlessly switch from one quality to another requires (in the worst case) that the client download overlapping chunks in both the old and new quality, and then splice them together when a keyframe is found. This is inefficient and significantly increases the probability of re-buffers, particularly when the client is attempting to switch to a lower quality due to a decrease in the available bandwidth.
DASH is the only internationally standardized solution, and an increasing number of major streaming services have either adopted it or are in the process of doing so. With this and the advantages outlined above in mind, we’ve decided to prioritize DASH support in ExoPlayer. This means that whilst we’ll continue to support both SmoothStreaming and HLS, new features that cannot be easily implemented across all three standards will be implemented first for DASH, and later (if at all) for SmoothStreaming and HLS. Which is yet another reason to choose DASH!