Distributing Adaptive to Android: Problems and Solutions

android sick.pngMost streaming producers are aware that distributing adaptive streams to Android is kind of mess; in this short article I wanted to summarize the problem and introduce some solutions. I’m an encoder, not a coder, so most of this is borrowed from other, more technical sources, but it’s important enough that I wanted to get it on my own blog.

By way of background, Android’s initial streaming strategy centered around the Flash player, which worked acceptably well until Adobe pulled the plug on updating the Flash player for Android and other platforms. This left Google in the lurch, which it tried to fill by adding support for HTTP Live Streaming (HLS), starting officially with Android 3.0+. This approach, implemented well, would be very attractive to producers who are already serving HLS streams to iOS devices, which support HLS natively.

However, as has been widely supported, Android’s HLS support has serious flaws, as neatly summarized by Jeroen Wijering in this Streaming Media article (I’ve added version numbers and updated his market share numbers to current figures):

 Officially, Android supports HLS as of Honeycomb (version 3.2). In practice, we see a number of critical bugs in the current iterations of Android that break in-browser HLS playback:

--  On Honeycomb (version 3.2), HLS playback crashes a tablet quite consistently. The version is of little concern though, since it has 2 (now under .01%) percent market share and is shrinking.

--  On Ice Cream Sandwich (version 4.0.3-4.0.4) 26 percent share (now 16.9%), HLS plays, but VOD streams cannot be seeked. The aspect ratio is also not detected, leading to deformed images. When going full-screen, a video is re-started from the beginning (again with no support for seeking).

-- On Jelly Bean (version 4.1-4.3) 3 percent share, but growing (now ~ 60%), the aspect ratio issue is fixed but the no-seek issue remains. Additionally, the new default browser (Chrome) does not understand HLS, leading to broken mimetype detection and an error message plus crash of the stream when taking it full-screen.

Wijering also noted that Android versions prior to Honeycomb, most notably Gingerbread (now at 21.2%), had no HLS support at all, so even if HLS worked well, it would still exclude those running Gingerbread and earlier platforms.

You can read more about this with similar conclusions in Jens Leoffler’s blog post, “The Bitter Reality of HTML5 Video on Android.” You can more easily reconcile Jens’ title with Jeroen’s comments by understanding that Apple supports HLS on iOS devices via HTML5. Here’s Jens’ final lament, “Although supported in earlier OS versions, Android 4.3 Chrome does not support HLS anymore in the HTML5 video tag.”

Potential Solutions

So, without Flash or adequate HLS support, what are streaming producers doing? There are a number of solutions available.

Create a native Android App - Here’s Leoffler’s comment - “A realistic workaround is to use a native application and open it from the web browser by using the Android intent filter. It has not much to do with actual HTML5 video, but it allows the use of a custom and improved HLS video stack professional Android video applications rely on.”

Jen’s second link takes you to an article on Adobe PrimeTime, which is a platform offered by Adobe that, among other capabilities, can extend HLS playback to desktop, iOS and Android devices with an improved HLS stack that avoids the problems Jeroen and Jens described. If you use PrimeTime, you get the benefit of Adobe’s development efforts in the new Android stack, though there is obviously a fee attached. Presumably, if you don’t use PrimeTime, you have to create your own stack to play the HLS streams.

HLS with MP4 Fallback - This is a schema used by JW Player that you can read about here. In essence, your embed code specifies a primary (HLS) and secondary URL (MP4 file delivered via progressive download). If the player can’t play the HLS stream, it falls back to progressive download. Not an optimal solution, but it beats a blank screen. Note that this solution works only for VOD streams; for live, you can supply an alternative RTSP stream, but you’d need a Wowza Media server to work with the JW Player (see here).

Ask your online video platform (OVP) - At the very least, most larger OVPs offer a software development kit (SDK) to port their player functionality into an Android App, though in most instances, you have to build the app yourself. In addition, Ooyala offers an app called Hook that content publishers can use instead of creating their own. Frost & Sullivan analyst and Streaming Media VP Dan Rayburn just wrote a white paper on Hook, which you can download (after registration) here.

[Updated]From some Twitter buddies - I learned that there are some DRM providers (especially from PlayReady ecosystem) which provide HLS SDKs for Android (thanks @jensloeffler), and also that NDS, which has been acquired by Cisco, does also (thanks to (Fabio Sonnati, @sonnati).

When considering a solution, keep these considerations in mind:

-- Cost, with developing your own app being much more expensive, but also more functional, than the fallback approach.

-- The percentage of potential viewers who will download an app, and the marketing effort associated with making that happen. Dan’s white paper quotes the French Open as a user, which is a great testimonial, but unless your content is equally alluring, you may have trouble getting your viewers to download the app.

-- What happens to older Android devices still running Gingerbread. Presumably, any application that relies on native HLS support at all, won’t work for these users.

I'm stepping a bit out of my expertise here, but it's information that I wanted to share. If there are any obvious errors or omissions, please feel free to let me know, either via email at jozer@mindspring.com or via a comment to this article. Thanks. 


(Android image from http://www.belford.com.br/tag/celular/)

Comments (0)

Post a Comment
* Your Name:
* Your Email:
(not publicly displayed)
Reply Notification:
Approval Notification:
* Security Image:
Security Image Generate new
Copy the numbers and letters from the security image:
* Message: