Adaptive Bitrate Encoding

Adaptive Bitrate (ABR) streaming is a delivery technology designed to provide consistent, high-quality viewing in situations where bandwidth may fluctuate, and where viewers may be on a wide range of devices - mobile, tablet or OTT. Growth of mobile video consumption and popularity of VOD services (Netflix, Disney+ or Amazon) relies on ability to create both, HLS and MPEG-DASH video at a scale.

ABR streaming addresses these issues by encoding content into multiple variants, each potentially a different bit rate, frame size and/or frame rate. These variants are combined into a single package that represents the original content. ABR players switch between variants depending upon the device and available bandwidth, to ensure consistent high-quality playback.

For example, a single ABR package might include six variants, each encoded at progressively higher bit rates. The player will adaptively switch between low bit rates and high bit rates, depending upon the connectivity of the device.

How it works

During playback, video and audio are delivered via HTTP in small segments, typically between 3 and 10 seconds in length. Each content package includes multiple variants, and each variant may include many segments. The player is provided with a package manifest file outlining which variants are available and the location of the segments for each variant.

The video player requests and downloads a segment from a variant. While the segment is played, the connection speed is monitored, and the player may opt to switch variants, either increasing or decreasing the video bit rate based upon the connection speed. Players may also choose variants with different frame sizes or frame rates to optimize the visual experience for the device. This adaptive behavior is what ensures consistent playback regardless of connection speed or device.

Apple HLS (HTTP Live Streaming) and MPEG-DASH (Dynamic Adaptive Streaming over HTTP) are currently two most common ABR streaming technologies supported by vast majority of devices. And they are both supported in Telestream Cloud.

Apple HLS

HLS is media streaming protocol developed by Apple for iOS, Apple TV and OS X that over time has gained support on number of other platforms due to its popularity. It is natively supported on OSX, iOS, Android 4.1+ and Windows 10.

Originally HLS used H.264 as video codec encapsulated by MPEG-2 TS chunks. References to the segmented files are contained in .m3u8 manifest files.

In 2016 Apple added byte-range addressing for fragmented MP4 files. HTTP byte range requests allow to specify segments as byte range of a larger URL and consolidate segments into single large file. Primary benefits of this update:

• improved caching performance as the media player is walking through a larger file in a sequence rather than downloading each segment from different location
• there are fewer files to manage which can translate into savings on storage space
• ability to use both HLS and MPEG-DASH manifests for the same media files which allows for broader compatibility across different players

HLS content can be encrypted with AES-128 using an existing or randomly generated key. For an extra layer of encryption keys can be served over SSL.

MPEG-DASH

MPEG DASH works in principle just like HLS, but is codec agnostic so it’s not limited to H.264 only but can also use H.265 or VP9. It is also the first adaptive bit rate solution that has become an international standard. Stream metadata is described by MPD files (Media Presentation Description) that can be organized in different ways depending on the use case.

In various forms MPEG-DASH is supported by all major browsers and vast majority of Android devices (from smartphones to TVs).

MPEG DASH uses Common Encryption for content protection which is based on existing web standards and is DRM platform agnostic. It works with number of available DRM platforms (Microsoft PlayReady, Google Widevine) and allows to share keys, key identifiers, encryption algorithm, parameters, location to store proprietary data in a Protection System Specific Header (PSSH) while leaving details of DRM implementation to individual systems.

Considerations when preparing ABR content

Preparing ABR content involves several steps. First, the desired packaging and variants or layer structures need to be identified. Next, content must be encoded, checked for quality, packaged, encrypted and delivered.

Packaging choice is generally driven by what devices must be supported. Not every device supports players for every type of ABR streaming technology. As a result, one should catalogue both the devices and the players that will be supported. iOS and Android, which dominate the current devices landscape, use either HLS or MPEG-DASH respectively. The ability to re-use encoded H.264 streams across multiple package types is key to avoid having to re-encode the same bit rates simply to package the video differently.

The selection of optimal bit rates, frame sizes and frame resolutions will vary depending upon device types, connection types and encoding technology. Apple provides excellent starting points with suggested profiles suitable for their ecosystems. However, practically speaking, the entire catalogue of devices, expected network connections and network costs must be considered when designing layers.

With these considerations, variants choice is a balancing act between frame size, bit rate and quality. However, the actual encoding technology used may have the biggest effect upon quality. For example, one study performed by the MSU Graphics & Media Lab showed that the use of x264 encoding technology saved necessary bit rates by as much as 50 percent compared to other H.264 encoding technologies at the same quality level.