Google Lacks A Strategy To Support Live Video On Android Devices

For content owners that want to get their live event-based streaming content on mobile phones and tablets, many are quickly finding out that getting it to Android devices is extremely challenging. Unlike Apple’s iOS platform, Google has yet to provide an easy way to get live video to Android devices and to date, hasn’t detailed any kind of strategy of how they plan to fix it. Many content owners I have spoken with, as well as those who help these content owners encode and distribute their video are now questioning why they should even continue to go through all the trouble of trying to support Android based devices at all.

While media companies can always build an app for their event series, most do one-off events and are faced with streaming to the mobile web and reaching their audience using browsers on Android and iOS devices. When Android phones became popular, live video was supported in the mobile browser thanks to Flash. Digital video professionals with live content to distribute were able to keep doing what they were doing on the desktop and Flash made it easier than it is now. That’s not to say that Flash was perfect as in many cases their desktop players were heavy, containing ad overlays and metadata interaction that had a major impact on the playback quality. To get better quality video playback, some people turned to RTSP delivery, which Android touted as its native live video format until Android 2.3.4 came out, when that feature no longer worked.

The most effective way to get live video to Android browsers was to make a stripped-down Flash player that didn’t demand much from the phones. Video was decoded in the software but it would drain batteries quickly. It was imperfect but it functioned well enough to play video. With the introduction of Android 3.0 it looked like HLS support was going to be built-in for all future devices, and that has held true, sort of. HLS support doesn’t match the specification, and buffering is common. Industry-leading HLS implementations like those from Cisco and Akamai will not load on Android devices, so for the most part, content owners went back to Flash. But now Flash isn’t available to new Android phones.

Right now, content owners are left in an awkward state if they want to deliver live video to Android browsers. If Flash is present, you can deliver a basic Flash video player. If it is not, you can try to deliver HLS but the HLS manifests must either be hand-coded or created using Android-specific tools. If the HLS video can play without buffering you’ll find that there is no way to specify the aspect ratio, so in portrait mode it looks broken. The aspect ratio problem seems to have been fixed in Android 4.1 but often, if you enter video playback in landscape mode and leave in portrait it will crash. You can allow the HLS video to open and play in a separate application, but you lose the ability to communicate with the page, and exiting the video dumps the user back on their home screen.

In comparison to iOS devices, content owners can still send the same live video to iOS devices that they could in 2009, and it will play smoothly with little buffering. Live video support for browser-based streaming within Android tablets and phones is a significant challenge with little help available from Google, and with Android still talking about removing H.264 video support, many content owners are wondering why they should even try to support Android any longer? What’s clear is that Google doesn’t have a strategy to fix the problem and many content owners and video ecosystem vendors are frustrated. Content owners want to get their live video on as many devices and platforms as possible and right now, getting it to Android devices is very difficult and costly. Unless Google steps in to solve the problem, don’t expect content owners to continue to try to support Android devices for live video streaming.

Content owners that want to give their feedback to Google about this, feel free to do so in the comments section below.

Note: I emailed a representative of the Android team asking if they were willing to talk about this subject but didn’t hear back. If Google would like to respond to this issue, I’ll be happy to post their response or hear any plans they may have to address the problem.

  • As noted on twitter, you missed it on this one:

    The same HTTP Live Streaming from iOS is supported on Android.

    That’s not to say they can’t do better but gloom and doom as your post makes it seem.

    • Hi John, that’s not exactly true.

      4.1 supports HLS in a browser pretty well, but Google keeps talking about removing H.264 support. What is jellybean at now in terms of the install base? 2%? 5%? So a company is going to base a strategy around a technology that reaches 5% of android phones and Google is talking about not supporting?
      HLS is supported natively using an html5 tag in chrome on jellybean. Technically. But the level of support for the protocol still falls far behind iOS, requiring a lot of (undocumented) adjustments to a standard HLS stream before it will work.

      • No doubt it is behind iOS in terms of numbers of you can reach w/ HLS but to say they don’t have a strategy is far from correct.

        What should they do? Provide an update to everything less than 3.0?

        • According to the spec, lots of things work. In reality from talking to content owners and developers, following the spec provided to Android developers still leaves you with a lot of questions. 3.x and 4.0.x crash while delivering Live HLS, period. 3.x and 4.0.x don’t honor aspect ratio. 4.1 supports an undocumented subset of the HLS protocol. When Google has a strategy, you see coherent results. Support for Live on Android is not the result of a strategy.

          • I’m a dev and my tests of HLS have all been positive. Granted, my stream may be different than others.

            I’m all for Google improving their strategy and increasing support. Time will tell.

          • Ian Ni-Lewis

            4.1 supports a documented version of HLS: version 3. What it doesn’t support is the newer features that were added in versions 5+. The most painful omission is EXT-X-PLAYLIST-TYPE, which allows sources to differentiate between ephemeral streams, events that are recorded live, and VOD. But this didn’t exist in the version of the spec that Android targets.

            As long as HLS is an Apple standard I don’t see a way that Google could possibly implement all of it–it’s a moving target.

  • Dan, we have been providing technology to deliver live video to Android devices for years but not in the browser. The Browser is a dead-end. No major content owners are relying on the browser. they are all building dedicated apps for Google Play and we we provide the technology to enable the live/vod encrypted content playback experience via those apps. this is the model for NetFlix, HBO Go, BBC Mobile etc.
    Live streaming is supported on Android via dedicated apps.

    • Cal Shanley

      This is not a feasible model for smaller organizations or one-off events. Investing in building an Android app is a hard sell for a 2-hour or 2-day event, and the high cost puts live streaming to Android out of the reach of many. Why should we have to spend thousands of dollars to do what the tag was designed to do?

      • RIght but by the same token why would Google spend a penny on making changes to their browser or OS for these kinds of events?

        • Cal Shanley

          They shouldn’t do it for these events. They should do it to be compliant with W3C standards and specs, and to be a good member of the community. Web standards are developed for everyone’s benefit, so anyone can create content without having to worry about a multitude of browser implementations – it’s on the device and browser developers to match the standards and make the web work. If you choose to ignore or break the standards, you get Microsoft, which I hope Google does not aspire to be.

          • Cal: Google doesn’t do anything to “be compliant with W3C standards and specs, and to be a good member of the community.” They do things to make money and they make it pretty clear in all their actions and marketing. To that note, all of these standards are supported in “in-app” playback by the player OEMs. For example our technology supports Live and VOD playback of HLS, SS and DASH content with PlayReady on Android. The key here is if you go the app route, you aren’t dependent on all the potholes in the browser support.

          • Cal Shanley

            All companies do things to make money. It’s our responsibility to ensure that they’re also acting to keep the internet open and accessible – tenets under which it was created.

            Google is a member of the W3C standards body. They need to adhere to the standards they helped to create.

          • Ian Ni-Lewis

            Cal, you lost me there. How is incomplete HLS support a violation of the W3C standards? HLS is an IETF draft standard that is wholly controlled by Apple, not a “W3C” standard that Google “helped to create.”

            Substitute “MPEG-DASH” for “HLS” and your argument starts to make sense.

  • Dan 100% agree with your post. “HTML5” video on Android is buggy at best. AllDigital has built from the ground up an Android video framework that supports live and ondemand video back to Android 2.1 and forward to the latest versions of Android and GoogleTV. It includes full hardware acceleration and content security. This allows the content owner to stream one ABR HLS source feed across iOS and Android. On lower powered devices our technology does the bandwidth detection server side to avoid excessive stream switching. For live events we can compile apps and place them in the Play Store. These apps can link directly from the browser page making it user friendly.

  • We do 1,000’s of live broadcasts that target mobile viewers and you are exactly right, Dan. Native support for “something” would be a strategy, and suggesting H264 is not in Android’s future just adds to the confusion. You get the feeling that Google has students in charge of live video for Android, and when the next class comes in it’s a random do-over.

  • Here is a comment I just was sent in an email on the topic:

    “Dan, right now I have never had a YouTube Live event work on mobile. I was told you have to make your live stream the featured stream on your channel and then have to go in and click off enable for mobile and you have to encode to a specific codec set. All of Which I have done. Never worked.”

    It’s as if each handset was running something different. One set of handsets disabled live streams at the OS level to save battery life. This year there is already one handset on Verizon that ONLY supports WebM no HLS. No flash. Right now what can install flash and what can’t. What plays HLS correctly and what version of Android. It’s almost like there are 50 different handsets and operating systems. Something that works on FroYo on Samsung might not work on FroYo on HTC or Motorola. It’s crazy. Then there is ICS and JellyBean.”

    • “This year there is already one handset on Verizon that ONLY supports WebM no HLS. No flash.”

      Which handset is that?

  • Jay Charles

    Even RTSP is suffering since 4.0 . In 2.3 and 3.x, at least the RSTP implementation in the native player was working as expected. As of 4.0, RTSP redirect is broken (StageFright just keeps trying to connect to the original URL after the 302), which forced me into some ugly hacks to handle redirect based load balancing.

    That said, once you get connected up to the stream RTSP works as expected, so at least there’s that.

  • We should make a demarc here in that there are really two types of streaming being delivered to Android devices. 1. In the browser HLS for non-premium content like CEOTV etc and 2. In-App streaming for premium content ala HBO Go, NetFlix etc. The underlying factors driving more and more companies in the direction of #2 are outlined here. Google doesn’t make money on streaming in the browser. As a result, they aren’t financially motivated to improve upon the existing HLS with HTML5 experience. In fact they make money when you deliver streaming via Google Play apps. So they are focused on that experience and over time will drive more and more of the market in that direction because it benefits them. It’s the same scenario with Apple and iOS devices. Nevermind on Android you have so many different OEM media players being included on the devices and the features of these players and economics behind their presence on the devices varies from OEM to OEM. Going the app approach insulates the content owner from all the pitfalls Dan describes below. For example, the technology we sell at BuyDRM supports Android 2.2+, Live and On-Demand, HLS, Smooth Streaming and MPEG-DASH with PlayReady. Relying on an In-App experience provides a much smoother experience for the end-user clearly.

    • Google doesn’t make money when streaming through apps so why would apps vs browser differ? The apps you stream from are free w/ a subscription (from the company, not Google), usually.

      • yes and no. Google makes money from Apps. The more you download apps the better the chance they are making money. Some apps are free. Some are not. Google sells more Android devices when there is content available for the devices as well. Yes they give the OS away but more devices means more ad revenue.

        • Umm no. A free app is a free app. They have made $0 on that app. You can’t cash a “chance” at any bank.

          • John: Google’s strategy involves having free apps and paid apps. Some free apps convert into paid apps. When users see Paid apps while browsing free apps or updating them, they have an opportunity to purchase them and they do en masse. Google’s strategy doesn’t involve spending money to support free streaming in the browser as it’s not aligned with their business goals.

          • I hear you but no. Free apps stay free. Rarely will a free app start charging. Google isn’t attempting to force people, as you initially suggested, to building apps vs streaming in the browser (which is my point).

            You know what browsers do? Show sites. You know what sites have? Ads. You know where Google lives? Yep…Ad-land.

            Their ad revenue is up 220% (see quarterly #’s just released) from last year. Ads is their business and those are in browsers as well as free apps. To them it matters not where users stream, IMHO.

          • John: It seems we are living in parallel universes πŸ™‚ When users are streaming videos they aren’t looking at or loading ads on web pages hence the reason Google doesn’t care about streaming in the browser. Yes they care about people loading web pages. Not every web page has video. in fact, most don’t. The overall point here being Google doesn’t lack a strategy for live video. They have one and it centers around the App store. They are dedicated to improving Stage Fright so more and more app vendors can tap into the multimedia experience on Android just not necessarily in the browser. Nevermind everything they do will only be done at the pace of the WC3.

          • The basics of a page loading means every element has to be loaded then once the video (or swf, in the case of Flash) is ready you can click play (unless autoplay hits). During this time, ads are loaded. It doesn’t matter if you look or not. An impression is registered whether your eyeballs hit the ad or not.

            If you truly believe the WC3 holds them back, you’re not a dev and don’t use Chrome. πŸ˜‰

            We clearly disagree, and that’s fine. I was merely trying to help you understand how it really works to not live on an assumption of Google’s practices.

          • John: Again, most web pages don’t have video so Google isn’t expecting the browser to be a point of downstream revenue from free 3rd party video. They mostly get their ads during search and during pages that are in fact sans video. They don’t make money on video ads through third parties either. The WC3 does hold everyone back because regardless of what business models are successful and regardless of what users like, the WC3 is going to take its sweet time coming up with a standard that may be 10 years behind ala HTML5.

          • G_A

            I like how Christopher Levy just makes up another argument or his false conclusion, when Cal Shanley explained to him why he was wrong the first go-around.

            The apps from streaming services in the PlayStore does not generate income for Google. They are free. The users pays through a monthly subscription to these services, an Google doesn’t get a cent out of it. Now, if you have sources that verify that Google extort money from these streaming providers to let them have their apps in the PlayStore, pleae share them. Or admit you were wrong.

            As for your second failed attempt, you are arguing that a user using the web browser to reach videos doesn’t see ads, and therefore it is better to force the content providers to provide the content to users in apps. Now, we have already comte to he conclusion that in the overwhelming amount of cases, Google doesn’t make a cent out of these apps, because the content isn’t bought in the app, and the app isn’t bought at all – it is free.

            So you are arguing no money is better than no money. But then, users ARE seeing ads in the browser BEFORE they full screen the video. And believe me, most free video sites do have adds. So unless you have a magic hat with a rabbit with a point that makes sense up your sleeve, you haven’t said anything so far to disprove the obvious (for us not “into the biz”): Google makes money IF you watch video in the browser. And NOT when you do it in free apps.

          • How that link refutes my point is beyond me. A game (mind you, we’re talking streaming apps here) did well and that refutes the point that Google is attempting to force devs to the app store vs the browser? Really?

            Google clearly wants to make money on paid apps but it, by no means, should lead you to the conclusion that Google is attempting to push devs to building apps, which are 9.9 times out of 10 free with paid content (either a cable provider, subscription, or otherwise that Google gets $0 from).

            I’m bowing out of this convo as you clearly don’t get it (nothing personal). We’ll just go round and round and I prefer not to. πŸ˜€ Have a great day sir.

          • John: We were speaking about apps in General. But on that note since you are so strong in your convictions how about the HULU App on Android? How about Spotify? There’s two apps right there from very well known brands that are streaming and offer an upsell which Google makes money on just like Apple. As a company working with brands like HBO and others to deploy streaming apps in the Google Play store, I definitely get it. We have differing experiences in the market clearly.

          • Ok. Have a great weekend.

            Thx for the discussion.

          • Cal Shanley

            I’m still not clear on how Google makes money off of free video streaming applications. Hulu, Spotify, Netflix, HBO Go – all free apps. There’s no upsell; you pay the content provider directly for a subscription. Unless they’re using Google for in-app billing, Google isn’t making any money off these apps.

            However – the existence of these banner apps on their platform ensures the success of the platform, which means more device sales and adoption, which means money. And if we’re talking about the platform, Android needs to match or surpass the stability and feature set of iOS to win market share, and bad UX with web video is holding them back.

          • Agreed.

          • Cal: Simple. When you upgrade from the Free Hulu or Free Spotify you do it in the app and Google gets a cut of the fees. From the article above: “Google Play apps are earning much more now than they did just six months ago. According to app store analytics provider App Annie, Google Play revenues increased by 137 percent during the first seven months of the year β€” a trend several developers with apps on Google Play are seeing in both the domestic and international markets.” “β€œPayer conversion, which we believe to be the final frontier on Android, is getting progressively better and is almost in kissing proximity to that of iOS platform,” he says. β€œThe shift has been very exciting and encouraging for us.” So Google is going to push this business model and push it hard and it won’t be in the browser πŸ™‚

          • Cal Shanley

            Please check your facts. Hulu doesn’t have an in-app upgrade process – they tie to their own web sign-up process. This is common – why would Hulu give Google a cut of the subscription fee when they already have their own subscription system? Apple actually tried to mandate against external subscription systems in iOS, but content providers refused to comply and Apple had to cave.

            Google can push whatever business model they want. Their app strategy isn’t really relevant to the fact that they’ve shipped a broken web browser on tens of millions of devices, and most content providers and developers will refuse to pony up app-development money to work around Google’s mistake, especially when the majority of their customers are iOS users.

  • Rtsp still works on the newer android sdk’s, its pretty bad and slow, so most of us who work with live feeds use ffmpeg, We have developed an ffmpeg sdk for iOS and we have built android rtsp for corporate clients, So I don’t really see the issue.
    Apple’s live streaming justs adds another standard that leaves some of us wondering did we really need. is http streaming any better than rtsp and other more proven methods is an open question because Apple requires use of HLS for extended streaming over cellular networks. Would HLS even of been adopted so quickly without the Apple enforcement.

  • Posted this to you on Twitter but here is the Apple live event being streamed on my Samsung Galaxy Tab 10.1 on 4.0.4.

    Again, Android supports HLS.

  • There are commercial options to solve this issue – The good news is that Android provides the proper APIs to solve this problem with an abstraction layer (iOS doesn’t).