Adaptive Bitrate Streaming allows to deliver video for varying network bandwidths and broad range of devices - mobile, tablet or OTT, growth of mobile video consumption and popularity of SVOD services like Netflix or Hulu make ABR essential to your business. With Telesteram Cloud we're offering you a complete toolset to easily produce high quality HLS and MPEG DASH streams.
Adaptive Bitrate streaming - why should you care?
Let’s start with some numbers. In 2016 more than 54% of all video starts occurred on mobile devices. That’s up from 46% a 2015, 34% in 2014, and just 17% in 2013. This one metric has been a constant: the growth of mobile video consumption. And with more than 1.5 billion smartphones shipped in 2016, up 3% from 2015, this trend is unlikely to stop.
Be it mobile phone, tablet, set-top box - more video is now consumed this way than on PCs. OTT content delivered through services like Netflix or Amazon means users can and want to access it any time and anywhere. At home through quick Wi-Fi connection or on the move as more and more carriers offer unlimited data.
Not offering your content on mobile devices means missing out on opportunity to expand your business. Telestream Cloud provides you with a complete toolset to produce high quality HLS and MPEG-DASH adaptive streams with multi-language audio tracks and captions and protected by major DRM platforms (Widevine, Playready).
HLS, MPEG-DASH—what is ABR?
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.
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.
HLS & MPEG-DASH
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.
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.
Content preparation for adaptive-bit-rate video.
Preparing ABR content takes several steps. First, the desired packaging and layer structures need to be identified. Next, content must be encoded, checked for quality, packaged, encrypted and delivered.
Choosing packaging and profiles
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. The necessary packaging will naturally become apparent as a result.
The selection of optimal bit rates, frame sizes and frame resolutions will vary depending upon device types, connection types and encoding technology. Apple and Adobe provide 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, layer design 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. As a result, it is recommended that layers be designed while performing actual encoding tests with the final encoding technology.
Most packages, however, generally contain between 16 and 24 layers. Part of layer design will require a reduction in the number of layers. It is best to select a few common native display frame sizes (such as 1080p) and then encode multiple bit rates to those frame sizes. Doing so will avoid unnecessary performance degradation on players that use software scaling.
Encoding, packaging, delivery and DRM
Each layer will require that a complete H.264 stream be encoded. With 16 to 24 layers, encoding an ABR package can easily require 20 times the processing power needed for a single H.264 stream. Fortunately, highly parallelized multirate H.264 encoding technology exists that re-uses information across the different streams. When combined with GPU acceleration, today’s encoding systems can offer 10 or 20 times the speed of CPU-based systems.
When preparing for multiple devices, an important aspect of encoding is transmuxing, the ability to re-use encoded H.264 streams across multiple package types. This prevents having to re-encode the same bit rates simply to package the video differently.
With on-demand content, it is important to perform QC checks on the different video streams. QC may be performed visually or by using automated tools that measure quality across all of the streams.
On-demand content often requires user authentication and protection prior to playback, which requires digital rights management (DRM). When using DRM, the video must be encrypted during packaging, typically using AES 128-bit encryption. DRM systems typically have subtle requirements for how the encryption is performed by the encoder or packager, and it is important to validate that the two are compatible.
Finally, content delivery will be performed, either as a compressed TAR file or in the native package form. Where possible, it is recommended that the entire production process (ingest, encoding, transmuxing, packaging, quality control, encryption and delivery) be combined into a single automated workflow. Manual steps will significantly slow production time and may result in errors.