Date: February 27, 2013 Author: Ed Wolf

The Pain of Live Streaming on Android

Streaming video on mobile devices remains one of the most challenging and frustrating experiences for viewers and broadcasters alike. When HTTP Live Streaming (HLS) was introduced, the goal was simple: easily stream live and on-demand video content to devices with a variety of bandwidth connections. Adaptive streaming is the marquee feature of HLS, and while Adobe’s RTMP can offer similar capabilities in Flash, desktop browsers like Chrome and Firefox can play HLS streams using a player like the JW Player. HLS is enhanced further by native implementations found within Safari and iOS, which makes streaming to mobile devices even easier.

So, what’s the problem?

Android and the lack of native HLS support.

All Hail Apple?

To be fair, it’s not all Android’s fault for lacking support for HLS in version 4.2 and beyond. Even the major desktop browsers have not yet implemented native HLS playback, and the only way to do so is through a Flash plugin. This doesn’t bode well for those of us who like to design sites for both the desktop and mobile devices, since the later generally can’t use Flash.

Android’s HLS implementation has a storied and turbulent past. Basic support was introduced in 3.0 (Honeycomb), but has never worked well enough for practical use. Below is an overview of the issues that have been found in each major Android version. We’ve also included a chart showing how widespread each version of Android is in the market:

Android distribution by version as of February 4, 2013

Android 2.3 (Gingerbread)

  • No Support, despite being the most popular version of Android

Android 3.0 (Honeycomb)

  • Streams cause tablet devices to crash

Android 4.0 (Ice Cream Sandwich)

  • VOD streams do not seek
  • Aspect ratios are not detected and cause image deformation
  • Fullscreen causes videos to restart from the beginning

Android 4.1+ (Jelly Bean)

  • Aspect ratio issue is fixed, but seek is still unavailable
  • Chrome does not understand HLS leading to broken mimetype detection
  • Taking video fullscreen causes devices to throw an error and stop.

You can see these HLS issues for yourself by viewing the sample stream we provide on our HTML5 report.

Android’s lack of native HLS support is one of the factors for why streaming to mobile devices remains a challenge. Since HLS is a proposed draft from Apple, and not yet an accepted standard by the IETF, companies like Google and Microsoft are both wary about ceding any control of their platform to Apple. With everyone gunning for a piece of the mobile market, it makes sense that a non-proprietary standard, like MPEG DASH, would help make adaptive streaming more prolific.

The Workarounds

With Android shipments and activations now outpacing iOS devices, broadcasters need to find a way to deliver HLS video to non-Apple devices. Since HLS streaming is supported on Android version 2.3-4.0 via Flash, you have to assume the user experience will be sub-par (see the aforementioned issues). Additionally, Flash support was discontinued in Android 4.1, meaning future versions of the OS cannot play back HLS streams natively.

A way around this limitation is to either build your own app’s implementation, or utilize an SDK from a third party vendor. However, this approach can be time consuming or impractical for some broadcasters. Additionally, it requires you to maintain and distribute an application to your users.

The easiest way to support HLS streams on Android or other non-iOS platforms is to offer a fallback RTSP stream. The main advantage to using an RTSP is that there is no need for Flash or any special client configuration. For example, if you use the JW Player for video playback, setting the player’s fallback to false will cause an RTSP stream to be loaded instead of an HLS M3U8 stream. This technique works great with the Wowza Media Server and is compatible with Android 2.3, 4.0 and 4.2 via the OS’ native player. You can learn more about this on our Apple HLS guide.

Until either a new non-proprietary standard is adopted, or each of the mobile platforms implement native HLS support, it looks like streaming to devices like Android will remain a challenge. Only time will tell…


    • peter

      May 6, 2013 at 9:10 am

      hello, please need help in livestreaming using long-tail can any one help me with step and step on how to use it with flash media encoder.Thanks

    • Thomas Vander Stichele

      May 7, 2013 at 10:30 am

      Rob, why is RTSP proprietary ? It’s an IETF standard AFAIK.

    • Deke

      May 7, 2013 at 12:29 pm

      All delivery types are supported (RTSP, RTMP, HLS, HDS) with the Mirror Image CDN. We have changed over to them to cover all formats, it is working great.

    • Ethan LongTail

      May 7, 2013 at 4:45 pm

      RTSP can be delivered by many CDNs out there, and from our experience, it is the only format that actually works/plays properly from old to new Android devices.

    • Rob

      May 8, 2013 at 11:30 am

      @Thomas Vander – Rather than going on what I was told I did a bit more research and it turns out….
      “The transmission of streaming data itself is not a task of the RTSP protocol. Most RTSP servers use the Real-time Transport Protocol (RTP) for media stream delivery, however some vendors implement proprietary transport protocols. The RTSP server from RealNetworks, for example, also features RealNetworks’ proprietary RDT stream transport.”

      I may have been misled…

    • Ethan LongTail

      May 8, 2013 at 3:44 pm

      Interesting, thanks for sharing this Rob.

    • Jeff Wenslow

      May 10, 2013 at 1:25 am

      Great article

    • Paul Clark

      May 17, 2013 at 12:00 pm

      RTSP is indeed an international standard and is widely used in the IPTV world within managed networks, usually delivering either RTP/UDP or MPEG-TS in raw UDP. Unfortunately in the Web world most people think of the Real Networks implementation which is deeply non-standard.

      You mention Flash-based solutions for HLS in the article. Can anyone recommend a commercially licensable solution which supports HLS on Gingerbread? I have looked at Onlinelib but they say they don’t support 2.3. We have a commercial opportunity for this.


      Paul Clark

    • Charles Linquist

      May 27, 2013 at 8:33 pm

      But what about streaming FROM an Android device? I have some robots that can be controlled from up to 1/2 mile away. I would really like to be able to stream video from them (to act as ‘eyes’) over 4G.

      Apple’s FaceTime is a possible start, but it wastes bandwidth in that it streams video in both directions. My robot does not need to see what I’m doing.

      I just need a low-latency remote camera that would (theoretically at least) have an unlimited range.

    • Ethan LongTail

      May 28, 2013 at 7:02 am

      @Paul – I am not sure of any HLS support for 2.3

      @Charles – I don’t know of devices that do this.

    • Ethan LongTail

      July 18, 2013 at 6:01 pm

      Where are you running this stream?

    • David Wong

      July 19, 2013 at 1:50 am

      Just use the default browser which will then trigger the native player to play the stream.
      Seemed worker properly in my S3. Would anyone share some test cases?

    • Ethan LongTail

      July 19, 2013 at 3:34 pm

      Sorry, I meant a link.

    • Sachin Ahuja

      November 14, 2013 at 7:25 am


      I am also facing the same problem of stream (which gets played on Apple successfully) not getting played on few Android devices OS > 4.0 and above.

      Though few Samsung devices are successfully able to play ABR HTTP stream but on few devices such as XOLO A500S (Android 4.2.2) and Spice (Android 4.2.2) what happens is if 64 kbps audio only profile is defined in playlist in the end then the device is not able to play the stream whereas if 64 kbps Audio only profile is moved to the top in playlist or is removed from playlist then the streaming works fine in these Android devices in the device native player.

      Any idea, does Android devices have problems with 64 kbps audio only file in the playlist?

      Sachin Ahuja

      • Ethan Feldman

        November 15, 2013 at 10:38 am


        Do you have an example of where you have run this set up?


    • Burhanuddin Jamalan

      December 4, 2013 at 6:49 am

      As per Ethan Longtail said :

      Ethan LongTail
      April 16, 2013 – 04:58 EST

      The JW Player still works fine on Android.

      Can you give the link that I can refer to since I’m facing the same problem.

    • Dmitry Sherman

      December 18, 2013 at 3:01 pm

      So how do we actually automatically fallback to RTSP without providing a link under or instead the player?

      • Ethan Feldman

        December 18, 2013 at 5:02 pm

        You need to provide the link. RTSP is not supported in Flash or HTML5 natively, so adding it as a link in the player set up will do nothing.

    • Paul

      March 4, 2014 at 2:28 am

      What’s disappointing about all this is that HLS video WILL play fine on your average Galaxy S4 Android phone in the default browser, or any browser including Chrome and Firefox. I’m guessing it’s the same deal with Android tablets running 4+.

      Yet, JW player detection wisdom forces a denial of the request to play the m3u8 stream and throws a useless error to the poor user. Why?

      Why isn’t there an override flag that developers can use to force JW player to attempt to play the m3u8 stream given such a common device such as a Galaxy S4 is asking to play the video, and is capable of playing it?

      Seems broken to me (JW that is).

      • Ethan Feldman

        March 4, 2014 at 10:57 am

        Once the newer versions of Android reach a higher adoption, we will add support natively. One work around you can use for the time being is detecting Android user the userAgent in JavaScript. Here is a small sample:

        <!DOCTYPE html>
        <script src=""></script>
        <center><div id='container'></div></center>
        if (navigator.userAgent.match(/android/i) != null){
        		file: "",
        		type: "mp4",
        		primary: "html5"
        } else {
          playlist: [{
            image: "",
            sources: [{
              file: ""
              file: ""
          primary: "flash"
    • kgpsss

      December 20, 2014 at 5:27 am

      Till recently I was able to plY the earlier episodes STAR PLUS soaps on my SAMSUNG GALAXY NOTE 10.1. Suddenly I started getting a message ” THIS VIDEO JS NOT ENCODED FOR YOUR DEVICE” . What can I do to restart viewing them. My OS is android version 4.1.2. Pl reply to my email.

    • Dmitriy

      January 30, 2015 at 3:51 am

      Did things change as for now?
      What is the best approach to playback HLS on android 2.3+?
      I know JWPlayer has an SDK for Android, is it stable?

      • Ethan Feldman

        February 26, 2015 at 5:25 pm

        The SDK is out. Please contact support [at] jwplayer [dot] com for more information.

    • Mario

      March 12, 2015 at 1:55 pm

      hola amigos
      el código de arriba me funciona perfecto para ver vídeos mp4 en desktop y en móviles, pero si quisiera ver mi streaming como lo modificaría?

      aqui el codigo

      if (navigator.userAgent.match(/android/i) != null){
              file: "",
              type: "mp4",
              primary: "html5"
      } else {
        playlist: [{
          image: "",
          sources: [{
            file: ""
            file: ""
        primary: "flash"
      • Ethan Feldman

        March 12, 2015 at 6:23 pm

        Please email support [at] jwplayer [dot] com directly about this.

Comments are closed.