Supporting Mobile Video on Your Site

Update: JW7 is now available. Check it out here.

One of the most often asked questions when discussing transcoding is How do I support iPads, iPhones and Android devices?. The goal of this blogpost is to remove some of the mystery behind transcoding for devices and present a solution that will work across a wide range of them.

The Problem

Many popular video formats, like FLV or WMV, will not play on devices like the iPhone. Even videos encoded in MP4 may not play back, resulting in the following screen:

iPhone Error

Error playing video on an iPhone

The underlying issue is processing power. Today’s desktop computers and laptops are powerful enough to decode just about any video format and size. Sometimes they can do it in hardware, meaning the graphics card (GPU) decodes the video. If a format is not supported by the hardware, desktops can fallback to software decoding. At that point, the player software itself will decode the video frames. Software decoding is slower than hardware decoding, but either option works.

Phones, netbooks and tablets on the other hand are not that powerful yet. Most are only able to do hardware decoding of video. It means the range of supported formats is narrowed down to what the GPU chip supports. Additionally, devices generally have an upper limit on the frame size of the video. For example, while the iPhone 4 supports HD video (1280×720 pixels), older models only supported video up to about 640×360 pixels.

The Solution

Unfortunately, you cannot support every device under the sun with a single file. It cannot be done. What you can do, however, is support a wide range of devices with a single file. We call this targeting the least common denominator. This is what we do within our own video platform. The files we render are targeted at the following devices:

  • All iPad, iPhone and iPod Touch models (iPhone 3G, iPad 1 and above)
  • All Android 2/3/4 phones and tablets (testing HTC Legend, Samsung Galaxy 1, Google Nexus 1 and above)


Some devices that can play our videos (excluding the pencil)

A video encoded for these devices will also work on desktops/notebooks (Flash), on many other phones (e.g. Blackberries, Nokias, Windows Phones) and on settops like PS3, XboX, Roku, Boxee and AppleTV. The specifications of such a video are as follows:

  • Container format: MP4, headers at the beginning of the file (for seeking)
  • Video format: H.264, Main profile, 640×360 pixels, around 500/900 kbps (kilobits per second)
  • Audio format: AAC, Low Complexity profile, 44.1 kHz stereo, 96 kbps

Recommended Implementation

If you don’t have a tool for encoding to MP4/H264/AAC, you should download Handbrake. It is free, works on cross-platforms and produces high-quality results. Handbrake has a built-in present called iPhone & iPod Touch, which has exactly the right settings. Note that Handbrake supports a constant quality feature, which offers smaller files than a target size or target bitrate.

For embedding the video, you should use a recent version (6+) of the JW Player. In version 6, we released a download mode fallback, which allows devices that don’t support Flash or HTML5 to still play the video with their built-in media player. Here’s how the embed code looks with the default setup (Flash » HTML5 » Download):

file: "/static/video-360p.mp4",
height: 360,
width: 640

The end result can be seen below; a good quality video that plays back on any device with a single embed code:

Resulting videoplayer that works on all desktops & devices.

Note you can enhance this video even further by adding an HD quality video version. JW Player will enable this on select devices. See the HD Video Everywhere post for more info.


    • Jakob Hyldahl

      March 15, 2011 at 1:24 pm

      I was just to ask my team to upgrade our player to 5.5, until I read in this blog, that 5.5 doesn´t support live streaming? Did I understand that right? I believe we are currently using 4.5 and we dont have any issues with live streaming. We have a complete setup with encoder, wowza and JW. If this is not supported by 5.5, when do you expect to be available? I hope it will be in the next release. This is a major feature.

    • Allan

      March 15, 2011 at 1:45 pm

      How about a simple way to stop on the last frame, people has been asking for that for years.

    • Wallville

      March 15, 2011 at 3:05 pm

      I have 300 Gigs of archive video that needs to be converted from .flv to h.264 ACC (mp4). I was able to get this up and running pretty quickly, but I have a massive audio drift. This could be a problem.

      HTML5, from what I understand requires a file fragmenter or segmenter, is this true? If so, is there a product other than the ffmpeg that can do this through a simple tool?

    • mw247

      March 15, 2011 at 4:07 pm

      Will the buffer option affect the video for the iphone/ipad?

    • JeroenW

      March 16, 2011 at 9:36 am

      Thanks for all the feedback! Some answers:

      @Mandy: JW Player does not rely on jQuery – it is completely library agnostic. Only our beta HTML5 player from a year ago was based upon jQuery.

      @John: You can set the option “dock=false” to display the HD button on the controlbar instead of on the dock.

      @Richiebee: Only the latest Blackberries play HTML5, but on older blackberries our player reverts to a “download” mode, leveraging the built-in mediaplayer from the device. This works on all Blackberries that support MP4 video (all from the last 5 years or so?).

      @John: Firefox indeed requires an Ogg file for HTML5 video. In above example, I presume every Firefox user has Flash installed. You could encode an additional Ogg file and load that as well in the JW Player (the player automatically selects the right file). However, it defeats the purpose of this article (one file for most devices), and Ogg in particular is a “dead” format. Firefox 4 will support WebM, that’s more interesting!

      @Jakob Hyldahl: JW Player 5.5 does support live streaming – in more formats than JW 4. However, live streaming to HTML5 isn’t possible since HTML5 itself doesn’t support live streams. The only option is M3U8 streaming to the iPad/iPhone (which the player also supports).

      @Wallville: The audio drift indeed doesn’t sound good. Perhaps there’s some tweaking possible with the handbrake settings to get this right? You should check the handbrake Wiki. And HTML5 doesn’t require a file fragmenter per se, only the M3U8 streaming to iPad/iPhone does. And that’s only needed for streaming of live or long (10min+) videos. For short clips, an MP4 is fine.

      @MW247: The buffer option should not affect iPhone/iPad streaming, but let me doublecheck that.

    • Serge Knystautas

      March 18, 2011 at 5:39 pm

      This was very helpful to understand how to encode video so that it could reach many platforms. Do you know what the ffmpeg settings will create this video format? ffmpeg is the basis for many video converters out there, so I thought it would be helpful to all to know the specific details of the conversion.

    • JeroenWijering

      March 22, 2011 at 1:26 pm

      Not sure about the FFmpeg settings, but the specific x264 flags are shown in Handbrake:


    • Michael C.

      March 29, 2011 at 1:07 pm

      The post assumes that the content is in a widescreen 16:9 format when it talks about the multi-platform video resolution (480×270). If my content is an older, 4:3 ratio video, and I wanted to retain cross-platform compatibility (lookin’ at you, iOS…), would I scale the video to fit in 480×368, or 368×270?

    • JeroenW

      March 30, 2011 at 10:53 am

      Better to go for 368×270, or 400×300. The number of pixels on screen should be rougly similar, since that’s one of the main factors that determine how “tough” decoding is for a phone.

    • FRASQ

      April 3, 2011 at 3:29 pm

      A lot of information about transcoding video and audio files on this site :

      The article is quite dense but very practical and worth reading several times.
      Once you have found the command which works for your device, save it!

      The section for transcoding media files for an Android or an iPhone or the web is at the end of the page.

      There is also an article about broadcasting video or audio files from a website with the Longtail Flash player :

      Thanks for your comments.

    • Alberto

      April 11, 2011 at 1:08 pm

      I have a puzzling problem.

      I encoded an iMovie project to mp4 as I have done hundreds of times, and I uploaded it to a folder on my server, where I keep all the videos in use with JW Player.

      I embedded the player in a webpage, as I have done it many times, but when I play the video, all I can hear is the sound. The screen is completely black.

      The only difference in this instance is that the video is 113 minutes long.

      I can watch the mp4 file with Quicktime.

      Please help.

    • @dharmaone

      April 12, 2011 at 9:27 am

      Great article. I would use x264 for encoding the video for best quality.

      Couldn’t you use javascript or media queries to detect the screen resolution, and serve different file based on that? It doesn’t feel right to serve the same video file to a an old 320×240 mobile and iphone 4 at 960×640

    • JeroenW

      April 13, 2011 at 12:04 pm

      @DHARMAONE: Yes, you can indeed do that. This functionality is e.g. included in the video embeds of our video platform, Bits on the Run. It’s excluded from this article to keep it basic.

      Screen resolution is only one parameter though. There’s other important parameters: the connection speed and device decoding power. Both are quite hard to detect to date, though much work is being done right now around e.g. HTML5 video and Apple HTTP Live Streaming to solve that.

      Perhaps the best option for now is to default to a fairly low-quality (e.g. 320×180) MP4, then move to a good quality MP4 (e.g. 640×360) on a few known devices (iPhone, Nexus One, Samsung Galaxy) and then show the HD toggle only on the iPad and on the desktop. We are working on incorporating such device-specific conigurations (through matching of user-agent strings) in the JW Player.

    • @dharmaone

      April 13, 2011 at 2:14 pm

      cool – I didn’t know that – I’ll check out Bits on the Run. Looks like very good value – considering it does multiple format encoding, storage, streaming and analysis! Out of curiosity, does it do adaptive bitrate detection like Apple HTTP Live Streaming – ie changing bandwidth midstream if network conditions change? Are you using Akamai or CloudFront?

      Apple HLS seems to be a good option too – while W3C standards for HTML5 video streaming are still lacking. Slightly annoying that it won’t work on future versions of Chrome or Mozilla because of h264 – no fault of Apple’s though.

      Look forward to the user-agent implementations in JW Player as well – great idea. I agree it’s difficult to detect connection speed client side, and even more difficult to detect device CPU/GPU power. There should really exist an open, regularly updated resource of specs of common mobile devices with device specific resolution, CPU/GPU etc matched to user-agent strings.

    • JeroenW

      April 14, 2011 at 8:16 am

      Bits on the Run does use adaptive streaming indeed. So far only Flash, but we are working on adding Apple HLS. And we’re using both Edgecast and Cloudfront as our CDNs.

      As to the HLS / HTML5 / UA choices: after we added in support for Apple HLS, Bits on the Run will likely run the following streaming setup:

      1. Flash dynamic streaming for all desktop browsers.
      2. Apple HTTP streaming for iOS and Android 3.
      3. A basic download (likely the 480px we talked about above) for all other devices.

      When we add live streaming support to Bits on the Run (is on the roadmap), it will work for both Flash dynamic and Apple HLS.

    • Ferenc

      May 16, 2011 at 1:33 pm

      This article contains exactly all the information I was searching for the past few days! However it doesn’t work on Android. :(

      When I encode a video with HandBrake using the Iphone & Ipod Touch preset and embedding it according the user guide (with a container div) I can watch the video on Chrome and Iphone, but not on Android 2.2 (tested on a HTC Legend and HTC Wildfire).

      When I visit this site with Android the video example also doesn’t seem to work. I only see a loading bar.

      Does anyone has a solution for this?

    • JeroenW

      May 16, 2011 at 9:04 pm

      The demo does work on my HTC Legend, BUT it is running in HTML5 mode (I turned off Flash). Is your Legend/Wildfire running in Flash or HTML5 mode? It could be that Flash, not the encoding, is breaking things here.

    • Ferenc

      May 17, 2011 at 8:36 am

      Thanks for the quick reply. Did you turn off Flash on your phone or in the embedding code of the JW player?

    • Ferenc

      May 17, 2011 at 9:37 am

      Turning off flash in android isn’t an option for me, because these people will skip the video then. Can I give HTML 5 a priority over Flash in Android?

    • JeroenW

      May 18, 2011 at 2:46 pm

      At present, you can only globally prefer HTML5 over Flash. That will make the player use HTML5 for desktops too though. Do this by adding a “modes” block. Example:

      We are working on a spec/feature for configuring players per device. With that, you will be able to set HTML5 first for Android and Flash first for desktops. That’s a 5.8 / 5.9 thing though.

    • Stan

      May 18, 2011 at 2:54 pm

      I like this solution very much, but I don’t understand how to integrate the code into WordPress using the JW Player plugin. Could you be specific? I’m not a coder, just a documentary fim maker. Thanks.

    • Ethan LongTail

      May 18, 2011 at 9:13 pm

      If you use our WordPress plugin, and use a video that is encoded correct (h.264), it should be supported on mobile by default, without you having to do anything.

    • Stan

      May 18, 2011 at 9:54 pm

      Thanks for your response: “If you use our WordPress plugin, and use a video that is encoded correct (h.264), it should be supported on mobile by default, without you having to do anything.”

      Right, and it works amazingly well with the recommended Handbrake settings. My problem is that I don’t understand how the HD plugin works with the desk/tops and lap/tops. You are supposed to encode a version at 720p and then what? I just don’t get the relationship between the two plugins.

      With the player plugin, for example, I have been unsuccessful in adding a flashvar to the players. For example, I have added frontcolor to the short code but nothing happens. Yet some of the players will pick up the color with no problem.

    • Ethan LongTail

      May 18, 2011 at 10:47 pm

      The HD plugin is a file swapper. Essentially, you have a variable for file, and you use the HD plugin, and then set the variable for HD.file.

      In our demo of the HD plugin we use bunny.flv as the file, and then bunny.mp4 as the “HD” version of the file. I hope that makes sense.

    • arunan

      December 15, 2014 at 10:32 pm

      I developed an android app by just opening webpages on the background of the app. The site opens well in android app, but i just tried linking this demo page with video, this page video is not opening in my mobile app. What should i do for this.

    • Asif

      February 26, 2015 at 11:49 am

      I can’t watch any vedio please help me regarding issue

      • Ethan Feldman

        February 26, 2015 at 4:51 pm

        I suggest contacting the website of where you are trying to watch videos.

Comments are closed.