SuperpoweredHome Get Superpowered Android's 10 Millisecond Problem Mobile Audio Latency Test App Android Audio Player USB Audio and MIDI for Android

HLS Android (HTTP Live Streaming) Audio with HLS Android Example

Android HTTP Live StreamingAndroid HTTP Live Streaming?

Though Android is the most widely distributed mobile OS, Android HTTP Live Streaming ("HLS") is not of the same quality as HLS on iOS.

Though newer versions of the Android OS tend to perform somewhat better, according to JWPlayer, Android fragmentation is still a problem and depending on the Android version, HLS may:

  • not be supported at all (Android 2.3, Gingerbread)
  • cause devices to crash (Android 3.0, Honeycomb)
  • lack seeking ability, feature distorted images, and restart videos completely when in fullscreen (Android 4.0, Ice Cream Sandwich)
  • lack seeking ability, and throw an error and crash when in fullscreen (Android 4.1, Jelly Bean)

Though excessive buffering resulted in the crashing noted above, the tablet-only OS Honeycomb 3.0 was an attempt at HLS-capability.

The introduction of Android 4.4 KitKat included an update to the platform's HLS support to a superset of HLS specification version 7 (version 4 of the protocol), yet as the Android Open Source Issue Tracker makes clear, the Android-HLS issue is still far from solved despite the improvements made to KitKat.

Knowing this doesn't make it any easier on developers looking to utilize HLS streaming in their mobile apps and proves frustrating, considering the wide array of device/Android version combinations in the Android ecosystem.

Developers, then, are left with two alternatives: attempt to build an implementation for your app from scratch, or utilize a third-party SDK that solves the Android HLS problem for you. In many ways, the struggle for seamless HLS streaming on Android is similar to the struggle for low latency Android audio—but that's not the only thing the two problems have in common.

They share a common solution as well: Superpowered Audio technology.

But before we detail Superpowered HLS Streaming for Android and iOS, we will describe a typical HLS streaming implementation for Android. Generally, implementations are made up by using multiple, different external libraries for each layer:

  • Network Communication: HTTP download, Transport Layer Security for HTTPS.
  • MPEG Transport: parsing and demuxing.
  • Audio Decoding: MP3 and AAC.
  • Media Segment Files: M3U8 parsing.
  • Audio Processing: resampling.

Inevitably, this makes for severe interoperability and efficiency problems as each library is optimized locally, and kludged together, hence, the streaming performance cannot be optimized holistically.

In other words, you cannot take a Ford engine, put it on a Tesla chassis with a Porsche suspension and steering mechanism from a Trabant and expect any sort of reliable performance. You need to integrate and unify the entire stack.

Introducing Superpowered HTTP Live Streaming HLS for Android and iOS

The Superpowered HLS Streaming Audio for Android and iOS unites the entire stack of:

  • Network Communication: BSD Network Socket communication, HTTP Client and Parser, TLS implementation for HTTPS (TLS parser, AES encryption [ECB, CBC, CFB128, CFB8, CTR], X509 parsing [and ASN1], RSA cryptography (PKCS1v1.5), arbitrary-precision arithmetic, CTR DRBG, MD5, SHA1, SHA224, SHA256, SHA384, SHA512 [and HMACs])
  • AES-128 decryption
  • MPEG Transport Stream Parser
  • MP3 and AAC-LC decoding
  • Caching, efficient memory handling and adjustable download management
  • HLS decoder to manage all playback integration into the Superpowered Advanced Audio Player with time stretching, pitch shifting, seeking.

This way, with a Superpowered binary, the entire HLS stack runs inside the mobile app – with zero 3rd party dependency libraries, completely independent of Android or iOS versions and fragmentation – is how one achieves stable and reliable HLS Audio Streaming on Android.

The Superpowered HLS player supports:

  • VOD, live or event streams
  • AAC-LC or MP3, in audio files or MPEG-TS files
  • byte ranges
  • AES-128 encryption
  • bandwidth measurement, automatic stream switching (can be turned off)

The Superpowered HLS player can be set to three unique download strategies:

  • Download all remaining content after the playhead.
  • Download everything: if all download finished after the playhead, will download everything in front as well.
  • Seconds ahead of playhead strategy: set it to 20 for example, and it will not download more than 20 seconds ahead of the playhead to save bandwidth for the mobile user.

The Superpowered SDK contains a HTTP Live Streaming example project for iOS and Android that shows you how to create a simple HLS audio player with seeking, buffering indicator and time display. Also, choose from multiple live and vod streams, multiple download strategies and enable time stretching.

Please note: Per the license governing Superpowered technology; Superpowered HLS technology must be licensed and is not available for free, unlike the Superpowered SDK.

HLS Streaming Android Background

Implemented in 2009 by Apple as part of their Quicktime, Safari, OS X, and iOS software, HTTP Live Streaming (HLS) has become the standard media streaming communications protocol for adaptive bitrate (ABR) video on mobile, tablets, and desktop.

HLS supports both live broadcasts and video on demand (“VOD”). Because HLS detects bandwidth capacity, adjusting video quality based on bandwidth available at the time, HLS quality tends to higher—i.e., less buffering and interrupted playback—than streaming a static file at a single bitrate.

Why choose HLS over other streaming technologies?

Because unlike other streaming technologies (eg. Adobe Media Server), it makes use of well-known Hyper Text Transport Protocol (“HTTP”). HLS works by breaking a stream into several small HTTP downloads. Rather than loading the entire file at once, each download loads a short chunk of a potentially unbounded transport stream. As the stream is played, the client is able to dynamically switch between several alternate streams—each containing the same data, but encoded at different bitrates—so that the streaming session adapts to the available bandwidth.