Adaptive bitrate streaming

While in the past most video or audio streaming technologies utilized packetized, stateful, single-bitrate streaming protocols such as RTP with RTSP, today's adaptive streaming technologies are based almost exclusively on HTTP, and are designed to work efficiently over large distributed HTTP networks.

Adaptive bitrate streaming works by detecting a user's bandwidth, CPU capability, as well as device type (such as smartphone, desktop computer, or smart TV) in real time, adjusting the quality of the media stream accordingly. It requires the use of an encoder which encodes a single source media (video or audio) at multiple bit rates. The player client switches between streaming the different encodings depending on available resources. This results in providing very little buffering, faster start times and a good experience for both high-end and low-end connections.

More specifically, adaptive bitrate streaming is a method of video streaming over HTTP where the source content is encoded at multiple bit rates. Each of the different bit rate streams are segmented into small multi-second parts. First, the client downloads a manifest file that describes the available stream segments and their respective bit rates. During stream start-up, the client usually requests the segments from the lowest bit rate stream. If the client finds that the network throughput is greater than the bit rate of the downloaded segment, then it will request a higher bit rate segment. Later, if the client finds that the network throughput has deteriorated, it will request a lower bit rate segment. An adaptive bitrate (ABR) algorithm in the client performs the key function of deciding which bit rate segments to download, based on the current state of the network. Several types of ABR algorithms are in commercial use: throughput-based algorithms use the throughput achieved in recent prior downloads for decision-making (e.g., throughput rule in dash.js), buffer-based algorithms use only the client's current buffer level (e.g., BOLA in dash.js), and hybrid algorithms combine both types of information (e.g., DYNAMIC in dash.js).

Current uses

Video streaming services that need to distribute content live or on-demand over the public Internet (also known as over-the-top media services) use adaptive bitrate technology in order to provide consumers with highest quality experience while minimizing buffering interruptions. When distributed over HTTP using content delivery networks adaptive bitrate streaming can easily be scaled to support streaming video content to millions of viewers concurrently. The world's largest streaming services, such as those operated by Netflix, Disney, NBC Universal, Warner Bros. Discovery, Apple, Google, Amazon and others, have all been actively using adaptive bit rate technology for many years now, making it standard practice for high-end streaming providers.

5 more chapters are free with a Lably account.

Benefits of adaptive bitrate streaming

Traditional server-driven adaptive bitrate streaming provides consumers of streaming media with the best-possible experience, since the media server automatically adapts to any changes in each user's network and playback conditions. The media and entertainment industry also benefit from adaptive bitrate streaming. As the video space grows, content delivery networks and video providers can provide customers with a superior viewing experience. Adaptive bitrate technology requires additional encoding, but simplifies the overall workflow and creates better results.

HTTP-based adaptive bitrate streaming technologies yield additional benefits over traditional server-driven adaptive bitrate streaming. First, since the streaming technology is built on top of HTTP, contrary to RTP-based adaptive streaming, the packets have no difficulties traversing firewalls and NAT devices. Second, since HTTP streaming is purely client-driven, all adaptation logic resides at the client. This reduces the requirement of persistent connections between server and client application. Furthermore, the server is not required to maintain session state information on each client, increasing scalability. Finally, existing HTTP delivery infrastructure, such as HTTP caches and servers, can be seamlessly adopted.

A scalable CDN is used to deliver media streaming to an Internet audience. The CDN receives the stream from the source at its Origin server, then replicates it to many or all of its Edge cache servers. The end-user requests the stream and is redirected to the "closest" Edge server. This can be tested using libdash and the Distributed DASH (D-DASH) dataset, which has several mirrors across Europe, Asia and the US. The use of HTTP-based adaptive streaming allows the Edge server to run a simple HTTP server software, whose license cost is cheap or free, reducing software licensing cost, compared to costly media server licences (e.g., Adobe Flash Media Streaming Server). The CDN cost for HTTP streaming media is then similar to HTTP web caching CDN cost.

History

Non-adaptive segmented media delivery over HTTP

DVD Forum created a WG1 Special Streaming group in October 2002 that was co-chaired by Toshiba and Phoenix Technologies, with participation from Microsoft, Apple Computer, DTS Inc., Warner Brothers, 20th Century Fox, Digital Deluxe, Disney, Macromedia and Akamai. The group was responsible for developing and standardizing methods of DVD content online delivery, known as DVDoverIP, that would form an integral part of the Enhanced DVD Format specification (DVD-ENAV). One of the specified DVD-ENAV streaming methods described packing MPEG-1 and MPEG-2 DVD TS Sectors into small 2 KB files which could be served to the player using an HTTP server. The MPEG-1 segments represented a lower bandwidth stream, while the MPEG-2 segments represented a higher bit rate stream. An accompanying XML schema provided a simple playlist of bit rates, languages and URL servers. However, the specification did not suggest or define dynamic bitrate switching.

An early HTTP web server based streaming system called SProxy was developed and deployed in the Hewlett-Packard Laboratories in 2006. It showed how to use HTTP range requests to break the content into small segments. SProxy demonstrated the effectiveness of segment-based streaming, gaining the best Internet penetration due to the wide deployment of firewalls, and reducing the unnecessary traffic transmission if a user chooses to terminate the streaming session earlier before reaching the end.

Move Networks

Modern adaptive bitrate streaming over HTTP was developed by Move Networks between 2004 and 2006, and started gaining worldwide attention in 2007 when it was chosen by ABC Networks as the streaming solution for their new HD video streaming website. Originally named Quantum Streaming, the ABR technology was incorporated into a suite of products named Move Media Services which included Move Simulcode (video encoding), Move Publish (content publishing, storage and digital rights management), Move Play (player) and Move Monetize (viewing data analytics). Move Networks ABR technology was described in a NAB weekly technology newsletter as follows:

Their system streams video from standard Web servers rather than specialized media servers, and uses the same HTTP protocol employed for standard Web pages. The video stream is broken up into short fragments cached in small pieces using a system that Move Networks calls Quantum Streaming, which aims to avoid the negative effects of Internet congestion and packet loss. The player automatically adjusts stream quality based on network conditions and the local environment of each media consumer.

— "High Definition Internet Streaming Video", NAB TV TechCheck (July 2007)

In October 2010, Move Networks was awarded a patent for its adaptive bitrate streaming invention (US patent no. 7818444), based on a provisional patent application filed in April 2004.

Implementations

After Move Networks' successfully demonstrated that HTTP-based ABR streaming was a viable commercial alternative to traditional packetized streaming protocols, other implementations of HTTP-based ABR followed shortly:

Microsoft demonstrated a prototype of ABR streaming on NBC's Olympics website in August 2008 during the 2008 Summer Olympics. After officially announcing an ABR streaming product in October 2008 at the Digital Hollywood conference it released Smooth Streaming (MSS) as an extension for IIS7 web servers in February (beta) and April (GA) 2009.
Apple Inc. first released HTTP Live Streaming (HLS) in June 2009 with the rollout of iOS 3.0 and iPhone 3GS.
Adobe Systems released HTTP Dynamic Streaming (HDS) in June 2010.
MPEG published the first version of the Dynamic Adaptive Streaming over HTTP (DASH) standard in April 2012, though the work on the standard had begun several years earlier with participation from Microsoft, Apple, Adobe, Netflix and other companies.

Of the ABR streaming implementations described here the only ones still actively developed and used in 2026 are Apple HLS and MPEG DASH.

Microsoft Smooth Streaming (MSS)

Smooth Streaming was developed as an IIS Media Services extension that enabled adaptive streaming of media to clients over HTTP. The media storage format was based on the ISO base media file format and published by Microsoft as the Protected Interoperable File Format specification. Microsoft was actively involved with 3GPP, MPEG and DECE organizations' efforts to standardize adaptive bit-rate HTTP streaming, which ultimately resulted in the publication of the DASH standard. Microsoft provided Smooth Streaming Client software development kits for Silverlight and Windows Phone 7, as well as a Smooth Streaming Porting Kit that could be used for other client operating systems, such as Apple iOS, Android, and Linux. IIS Media Services 4.0, released in November 2010, introduced a feature which enabled Live Smooth Streaming H.264/AAC videos to be dynamically repackaged into the Apple HTTP Adaptive Streaming format and delivered to iOS devices without the need for re-encoding. Between 2009 and 2013, Microsoft successfully demonstrated delivery of both live and on-demand 1080p HD video with Smooth Streaming to Silverlight clients. In 2010, Microsoft also partnered with NVIDIA to demonstrate live streaming of 1080p stereoscopic 3D video to PCs equipped with NVIDIA 3D Vision technology.

In 2013 Microsoft shifted its media services product offering to the cloud where it continued to support Smooth Streaming as a core component of Azure Media Services. However, development and adoption of MPEG DASH and HLS as industry standards gradually displaced Smooth Streaming as Microsoft's preferred adaptive streaming technology by the end of that decade. In June 2023 Microsoft announced the retirement of Azure Media Services, effective June 2024, and while the announcement didn't explicitly mention Smooth Streaming by name it effectively meant the end of support for Smooth Streaming in any active Microsoft products.

Apple HTTP Live Streaming (HLS)

HTTP Live Streaming (HLS) is an HTTP-based media streaming communications protocol implemented by Apple Inc. as part of QuickTime X and iOS. HLS supports both live and video on demand content. It works by breaking down media streams or files into short pieces (media segments), which are stored as MPEG-TS or fragmented MP4 files. This is typically done at multiple bitrates using a stream or file segmenter application, also known as a packager. One such segmenter implementation is provided by Apple. Additional packagers are available, including free and open source offerings like Google's Shaka Packager and various commercial tools as well - such as Unified Streaming. The segmenter is also responsible for producing a set of playlist files in the M3U8 format which describe the media chunks. Each playlist is specific to a given bitrate and contains the relative or absolute URLs to the chunks for that bitrate. The client is then responsible for requesting the appropriate playlist depending on available bandwidth.

HTTP Live Streaming is a standard feature in the iPhone 3.0 and newer versions.

Apple has submitted its solution to the IETF for consideration as an Informational Request for Comments. This was officially accepted as RFC 8216. A number of proprietary and open source solutions exist for both the server implementation (segmenter) and the client player.

HLS streams can be identified by the playlist URL format extension of m3u8 or MIME type of application/vnd.apple.mpegurl. These adaptive streams can be made available in many different bitrates and the client device interacts with the server to obtain the best available bitrate which can reliably be delivered.

Playback support

Playback of HLS is supported on many platforms, including Safari and native apps on macOS and iOS, Chromium-based browsers, ExoPlayer on Android, and the Roku platform. Many Smart TVs also have native support for HLS. Playing HLS on other platforms like Firefox is typically achieved via a browser / JavaScript player implementation. Many open source and commercial players are available, including hls.js, video.js http-streaming, BitMovin, JWPlayer, THEOplayer, etc.

Adobe HTTP Dynamic Streaming (HDS)

"HTTP Dynamic streaming is the process of efficiently delivering streaming video to users by dynamically switching among different streams of varying quality and size during playback. This provides users with the best possible viewing experience their bandwidth and local computer hardware (CPU) can support. Another major goal of dynamic streaming is to make this process smooth and seamless to users, so that if up-scaling or down-scaling the quality of the stream is necessary, it is a smooth and nearly unnoticeable switch without disrupting the continuous playback."

Flash Player and Flash Media Server supported adaptive bit-rate streaming over the traditional RTMP protocol, as well as HTTP, similar to the HTTP-based solutions from Apple and Microsoft, HTTP dynamic streaming being supported in Flash Player 10.1 and later. HTTP-based streaming has the advantage of not requiring any firewall ports to be opened outside of the normal ports used by web browsers. HTTP-based streaming also allows video fragments to be cached by browsers, proxies, and CDNs, drastically reducing the load on the source server.

As of 2026, Adobe HDS is considered deprecated and no longer used in any large scale deployments.

Dynamic Adaptive Streaming over HTTP (DASH)

Dynamic Adaptive Streaming over HTTP (DASH), also known as MPEG-DASH, is the only adaptive bit-rate HTTP-based streaming solution that is an international standard MPEG-DASH technology was developed under MPEG. Work on DASH started in 2010 and became a Draft International Standard in January 2011 and an International Standard in November 2011. The MPEG-DASH standard was published as ISO/IEC 23009-1:2012 in April 2012.

MPEG-DASH is a technology related to Adobe Systems HTTP Dynamic Streaming, Apple Inc. HTTP Live Streaming (HLS) and Microsoft Smooth Streaming. DASH is based on Adaptive HTTP streaming (AHS) in 3GPP Release 9 and on HTTP Adaptive Streaming (HAS) in Open IPTV Forum Release 2. As part of their collaboration with MPEG, 3GPP Release 10 has adopted DASH (with specific codecs and operating modes) for use over wireless networks.

The goal of standardizing an adaptive streaming solution is to assure the market that the solution can work universally, unlike other solutions that are more specific to certain vendors, such as Apple's HLS, Microsoft's Smooth Streaming, or Adobe's HDS.

Available implementations are the HTML5-based bitdash MPEG-DASH player as well as the open source C++-based DASH client access library libdash of bitmovin GmbH, the DASH tools of the Institute of Information Technology (ITEC) at Alpen-Adria University Klagenfurt, the multimedia framework of the GPAC group at Telecom ParisTech, and the dash.js player of the DASH-IF.

Common Media Application Format (CMAF)

CMAF is a presentation container format used for the delivery of both HLS and MPEG-DASH. Hence, it is intended to simplify delivery of HTTP-based streaming media. It was proposed in 2016 by Apple and Microsoft and officially published in 2018.

Self-learning clients

In recent years, the benefits of self-learning algorithms in adaptive bitrate streaming have been investigated in academia. While most of the initial self-learning approaches are implemented at the server-side (e.g., performing admission control using reinforcement learning or artificial neural networks), more recent research is focusing on the development of self-learning HTTP Adaptive Streaming clients. Multiple approaches have been presented in literature using the SARSA or Q-learning algorithm. In all of these approaches, the client state is modeled using, among others, information about the current perceived network throughput and buffer filling level. Based on this information, the self-learning client autonomously decides which quality level to select for the next video segment. The learning process is steered using feedback information, representing the Quality of Experience (QoE) (e.g., based on the quality level, the number of switches and the number of video freezes). Furthermore, it was shown that multi-agent Q-learning can be applied to improve QoE fairness among multiple adaptive streaming clients.

Criticisms

HTTP-based adaptive bit rate technologies are significantly more operationally complex than traditional streaming technologies. Some of the documented considerations are things such as additional storage and encoding costs, and challenges with maintaining quality globally. There have also been some interesting dynamics found around the interactions between complex adaptive bit rate logic competing with complex TCP flow control logic.

However, these criticisms have been outweighed in practice by the economics and scalability of HTTP delivery: whereas non-HTTP streaming solutions require massive deployment of specialized streaming server infrastructure, HTTP-based adaptive bit-rate streaming can leverage the same HTTP web servers used to deliver all other content over the Internet.

With no single clearly defined or open standard for the digital rights management used in the above methods, there is no 100% compatible way of delivering restricted or time-sensitive content to any device or player. This also proves to be a problem with digital rights management being employed by any streaming protocol.