Supporting Mobile Video on Your Site

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):

jwplayer("container").setup({ 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.


  1. @dharmaone April 13, 2011 - 02:28 EDT

    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.

  2. Ethan LongTail May 18, 2011 - 09:16 EDT

    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.

  3. JeroenW May 16, 2011 - 09:02 EDT

    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.

  4. Stan May 18, 2011 - 09:34 EDT

    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.

  5. Ethan LongTail May 18, 2011 - 10:26 EDT

    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.

  6. JeroenW March 16, 2011 - 09:28 EDT

    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.

  7. Ferenc May 17, 2011 - 08:55 EDT

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

  8. Ferenc May 17, 2011 - 09:16 EDT

    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?

  9. FRASQ April 3, 2011 - 03:23 EDT

    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.

  10. @dharmaone April 12, 2011 - 09:51 EDT

    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

  11. Michael C. March 29, 2011 - 01:26 EDT

    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?

  12. JeroenW April 14, 2011 - 08:04 EDT

    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.

  13. Ethan LongTail April 12, 2011 - 08:22 EDT

    @Alberto – Can you email us with a link? –

  14. Jakob Hyldahl March 15, 2011 - 01:48 EDT

    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.

  15. Allan March 15, 2011 - 01:36 EDT

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

  16. Wallville March 15, 2011 - 03:27 EDT

    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?

  17. mw247 March 15, 2011 - 04:13 EDT

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

  18. Serge Knystautas March 18, 2011 - 05:12 EDT

    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.

  19. JeroenWijering March 22, 2011 - 01:54 EDT

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


  20. Ferenc May 16, 2011 - 01:41 EDT

    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?

  21. Alberto April 11, 2011 - 01:17 EDT

    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.

  22. JeroenW May 18, 2011 - 02:33 EDT

    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.

  23. Stan May 18, 2011 - 02:09 EDT

    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.

  24. JeroenW April 13, 2011 - 12:12 EDT

    @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.

  25. JeroenW March 30, 2011 - 10:43 EDT

    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.

  26. arunan December 15, 2014 - 10:00 EDT

    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.

  27. Asif February 26, 2015 - 11:02 EDT

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

    • Ethan Feldman February 26, 2015 - 04:13 EDT

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

  28. Cialis bestellen February 1, 2012 - 02:03 EDT

    Hi.. very informative post.

  29. Erwan September 6, 2011 - 04:38 EDT

    There is a bug here, when switching from “hd on” then “hd off” again (try to wait a few seconds between each switch), the movie restart from the beginning but not the progress bar!

  30. JeroenW July 3, 2012 - 02:41 EDT

    Ethan was still monitoring this post, so here you go!

    a) A slight upgrade to 640×360 makes sense at this point. Any recent (2010+) mobile device can play this.

    b) It’s not strictly required to constrain videos to full macroblocks. In the case of 480×270, the decoders basically hide 2 pixels of the bottom row of macroblocks. A bigger problem is a resolution where width or height ends up being X times 16 + 1. There, almost an entire row of macroblocks is not shown.

    c) 480×360 (if correct dimensions are important) or 480×360 (if optimized filesize is important) would indeed work well.

  31. Сialis tadalafil February 1, 2012 - 02:18 EDT

    Good article! Keep it up!

  32. Ethan LongTail September 30, 2011 - 09:03 EDT

    @Antonio – You need to use the JW Embedder, and mobile / HTML5 does not work with rtmp, so the stream must be m3u8.

  33. Jaipraksh September 27, 2012 - 02:00 EDT

    Is any one know that how to get rid of the interim screen which appears on mobile site, for ex. Black-Berry. You will see there is big button screen which we needs to skip & play the video directly, how i can do this ?

  34. JeroenW July 10, 2012 - 10:38 EDT

    Thanks for your additional feedback. I don’t have clear answers to any of your questions though. They can all be answered with an “it depends”.

    Take the 640×360 resolution as an example. If, for your site, broad mobile adoption is super important, you should generate a 480×270 video to ensure pre-2010 BlackBerries play the files too. If you think these edge cases are not important and it’s simply easier / cheaper to have one video (640×360) for both desktop and mobile, you should go for the latter.

    In all cases though, neither option is a bad choice. 480×270 and 640×360 are both fine, sticking to macroblocks or deliberately not sticking to them is fine, and 480×360 or 480×352 are both fine too.

  35. Ethan LongTail September 27, 2012 - 04:26 EDT

    I’m afraid there isn’t a way to remove that.

  36. JeroenW September 7, 2011 - 07:14 EDT

    Yes indeed. This issue may occur in Flash mode when using HTTP pseudo-streaming. The bug has since been fixed and will be part of the upcoming 5.8 release:

  37. Ethan LongTail June 9, 2011 - 07:13 EDT


    width: 384


    width: 384,
    plugins: ‘hd-1′,
    ‘hd.file': ‘your_hd_file.mp4′

  38. Mike December 30, 2011 - 06:00 EDT

    This article is highly appreciated. But, when the iPhone 5 comes around, I think iOS 6 will have all the compatibility functions built it, to allow the iPhone to play almost any kind of media.

  39. Michael July 12, 2012 - 01:50 EDT

    Thank you for your additional info.

    Much appreciated,


  40. Jules July 23, 2011 - 07:49 EDT

    With regards to encoding and a post a few up about it not working on Android when you use handbrake. I also tried handbrake and it didn’t work on my Motorola Xoom which is the only android device I have to check it on.

    I’m fortunate because i’m an editor and so I have QT7 Pro and I used that on Export for Web, changed the .m4v to .mp4 and it works on the Xoom and my 3Gs iPhone.

    Until someone can point me in a better direction I have set that file as the SD file and used the HD plugin on which I put a 2000kbp h264 @ 1280×720 which I also encode in QT7Pro (not the web, just export and tweak the settings). I then set HD to default.

    From my limited testing desktops get the great quality HD first, and SD is there if there’s bandwidth issues (though the QT7 encode for web isn’t too shoddy). on IOS it just works. The only slight bone of contention is my Xoom runs flash and so it defaults to HD: it plays the audio and the start of the video then it says ‘this video isn’t encoded for mobile’ and you have to switch it to SD. Perhaps some people won’t realise that but there’s a big button there saying HD on, so i’m just hoping that people aren’t that devoid of lateral thinking :)

    Anyway, for me at least, QT7 came up good (and this was after a lot of testing and hair pulling out). Oh, I also use the QTIndexSwapper 2 to ensure the .mp4 files have the progressive start thingy at the beginning. This was mentioned in a forum post and is a plugin for Adobe Air and works a charm. There was another thingy mentioned in the post too, but this worked for me so I didn’t bother checking out the other and i forget the name.

    Anyay, we have (partial) lift off :)

  41. Michael July 8, 2012 - 03:01 EDT

    Thank you for the reply/post Jeroen. Much appreciated!

    In wanting to keep this thread alive as the definitive guide from yourself and LT for the optimum web video encoding parameters for mobile devices by “targeting the least common denominator”, I have a couple follow-up questions for clarity:

    a) Is it your position that current mobile use/adoption dictates that pre v.4 iPhones (480×320) are no longer (reasonably) relevant enough to require minimum resolution below 640×360?

    b) Respecting it’s not “strictly required to constrain videos to full macroblocks”, (in that decoders can handle alternatives), would you recommend that “best practices” should still adhere to resolutions in multiples of 16?

    c) Your answer to “c” above, including “or”, would suggest that perhaps you intended to write one of the two resolutions as something other than “480×360”? :-)

    More importantly, it would be extremely valuable, and greatly appreciated, if you could update the following recommendation from your original blog article posted March 2, 2011, (including resolution dims for both 4:3 and 16:9):

    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 (testing iPhone 3G, iPad)
    • All Android 2/3 phones and tablets (testing HTC Legend, Samsung Galaxy)
    • All recent Blackberry phones (testing Bold & Storm)

    A video encoded for these devices will also work on desktops/notebooks (Flash), on many other phones (e.g. Nokias) 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, Baseline profile, 480×270 pixels for 16:9 and XXXxYYY for 4:3, around 400/600 kbps (kilobits per second)
    • Audio format: AAC, Low Complexity profile, 44.1 kHz stereo, 96 kbps)

      Thank you kindly,


  42. rajiv November 7, 2011 - 08:00 EDT

    whenever I try to play this URL

    on blackberry it throws an error
    Cannot find Web address. Verify that this is web address is valid.

    And the page address it could not find per above error is

    It looks like the ; is causing a problem in the url. It should be a ?. Is this being generated from your JW Player?

    Click to play rtsp stream

    It could be a bug in the jw player java script.

  43. E September 8, 2011 - 03:25 EDT

    I have the same issue of the videos not playing on the android 2.2 – play great in the other various browsers. I tried the code as suggested at and that kills everything. I can’t even see the image for the video in Firefox. Here is what I currently have:

    Loading the player ...

    How can I format this so it shows up for the Android 2.2 and all the other browsers it is currently working in? It is a h.264 mp4 file that is web optimized via handbrake.

  44. Antonio Espinal September 29, 2011 - 02:48 EDT

    Could somebody provide me the complete script code for the mobiles and live streaming from a server. Thanks in advance.

  45. Rob August 1, 2011 - 04:18 EDT

    Be sure to setup your servers mime types for the various file types. You can get the “cannot play movie” error if those haven’t been setup.

  46. Ethan LongTail September 8, 2011 - 07:27 EDT

    Please email us here with a link –

  47. Ethan LongTail November 7, 2011 - 08:04 EDT

    @rajiv – Send us an email.

  48. JeroenW July 25, 2011 - 09:36 EDT

    Awesome, thanks for the info. The HandBrake presets must differ by version though, since my encodes did work fine on Android (2.1, 2.2, 2.3 – various phones). QT7 is a good tool to use as well though.

    Note we’re about to release an HTML5 version of the HD plugin, which will allow you to display the HD switch in HTML5 (iPad!) too…

  49. Jesssal June 20, 2011 - 09:41 EDT

    I’ve tried converting .flv files with handbrake but it’s not working. Is it possible to use .flv files with jwplayer and how would you suggest going about it?

  50. Michael July 3, 2012 - 01:42 EDT

    Excellent post Jeroen! Thank you!

    If you’re still monitoring this post I’d really like to ask you a couple questions:

    a) 16 months on from your original post, with the improvements and wider adoption of mobile devices do you have any updates to your original recommendations, (i.e., perhaps increasing your suggested resolution of 480×270, etc.)?

    b) On that resolution of “480×270”, please correct me if I’m wrong, but shouldn’t that be “480×272” as “270” isn’t divisible by 16, and “272” is? Kindly clarify or explain.

    c) What would be your recommended 4:3 equivalent, (e.g., 480×352)?

    Thanking you in advance,


  51. Ethan LongTail June 20, 2011 - 03:55 EDT

    You can’t use .flv files on iOS because .flv files are Flash only. Regarding it not working, please email us a link –

  52. Сialis tadalafil February 1, 2012 - 01:00 EDT

    Interesting site. Great post, keep up all the work.

  53. Antonio Espinal September 30, 2011 - 02:52 EDT

    The following is what I use for regular streaming.
    Please help me providing the codes for mobile.

  54. Ferenc May 23, 2011 - 07:32 EDT

    After some long testing, I finally discovered what the problem was: the streaming capabilities of the server. Moving the video files to another server and redirecting the URL’s solved all my problems. So it had nothing to do with the JW Player nor the videos. Different types of encoding profiles seem to work now.

    For people who are interested I provide two links pointing to exactly the same website. The only difference is that the first one loads the video files locally, while the second one loads them from another server.

    The first one loads on many types of browsers and devices but not on iPhone. The second one also works on iPhone. The helpdesk of my webhoster ( (do not ever host your website here) says I have to contact Apple for this :o.

    I think the error in Safari with HTML5 as first priority is due to the deinstallation of DivX plugin. The problem did not occur on any other computer with Safari.

    Thanks for all the help.

  55. joseph June 9, 2011 - 04:49 EDT

    here is my coding, where do I add the hd plugin ?
    Is there any where else where I can find more details on this subject?

    Loading the player …

  56. Ethan LongTail May 23, 2011 - 04:07 EDT

    Np, thanks for letting us know!

  57. antz March 9, 2011 - 02:19 EDT

    Can this be done using Flash Media Live Streaming? Flash Media Live Streaming can stream H.264 format but When I try publishing it on a webpage it only works on computers not on iPhone,iPad.

    Any idea?


  58. Patrick June 2, 2011 - 05:54 EDT

    You wrote: “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?).”

    Blackberry compatibility is very important to me, as a large, important segment of my users have them. So, I’m very interested in how well this works.

    When I try to load this post in the browser on my Blackberry, the example video that you have embedded above just doesn’t display at all. It doesn’t “revert to download mode”. Am I missing something?

    My phone is a Curve 8330, which is a 4-year-old model, and supports mp4. As a test, I set up a link to the mp4 that is the source for the above embedded video, then tried it again. My phone had no problem viewing the video. So, the problem is just that the player above does not provide the link.

  59. Ferenc May 19, 2011 - 09:07 EDT

    Thanks for the reply. I have used your link to give HTML5 priority over Flash, however the video still doesn’t play on Android 2.2 (HTC Wildfire). It gives the error: “The video could not be loaded because the format is not supported by your browser” I have used a mp4 file created in Handbrake with the Iphone/Ipod Touch preset.

  60. Ferenc May 19, 2011 - 09:08 EDT

    Thanks for the reply. I have used your link to give HTML5 priority over Flash, however the video still doesn’t play on Android 2.2 (HTC Wildfire). It gives the error: “The video could not be loaded because the format is not supported by your browser” I have used a mp4 file created in Handbrake with the Iphone/Ipod Touch preset.

  61. Ferenc May 19, 2011 - 09:52 EDT

    Safari doesn’t seem to like the HTML 5 priority either. It doesn’t display video at all with the new priority. Removing the modes argument solves this problem.

  62. JeroenW June 3, 2011 - 08:31 EDT

    I wonder if this is related to some scripting on the page or in the player. I don’t have a blackberry at hand, but an older Nokia phone shows the video OK.

    Can you try this link on your phone? If you don’t see the thumbnail, I wonder if your phone returns any scripting errors?

  63. Ethan LongTail May 19, 2011 - 08:58 EDT

    Ok, please contact us with a link, thanks. –

  64. JeroenW March 10, 2011 - 08:34 EDT

    Live streaming to a range of mobile devices isn’t possible at present. Only playback of prerecorded MP4 files …

  65. Mandy March 15, 2011 - 09:36 EDT

    Great Article! But, why does the jwPlayer library rely on jQuery ?

    I use prototype and this creates problems for me.

    Please make it library agnostic :)

  66. John March 15, 2011 - 09:09 EDT

    Now all we need is it to automatically preselect SD mode for mobile devices and HD for tablets and computers and swap that great big ugly button for something more discreet on the timline..

    Even fires up the media player on Windows Mobile 6.5 :-)

  67. richiebee March 15, 2011 - 09:14 EDT

    Hi great post!

    any clues on Blackberry devices? you have a picture of one in your post but only the very latest play html5 video….

  68. John March 15, 2011 - 09:44 EDT

    Doh! I knew it was too good to be true, as I haven’t got the Flash or Quicktime plugins in Firefox (3.6.15) it forces a download, why doesn’t it play in Firefox using HTML5 ?

  69. ojobson March 15, 2011 - 10:31 EDT

    Just a reminder to people to click the web-optimized button in Handbrake – otherwise your video might not start playing until the entire file has been downloaded (which could be a long wait!). Web-optimized video has the meta information at the beginning of the file (as opposed to the end) which facilitates playback as soon as a small portion of the file has been downloaded (enough to fill the buffer I think).

    Thought this might help some noobs (like me) as it had me stumped for a while!

  70. Ian March 15, 2011 - 11:12 EDT

    With regards to Firefox – I think Firefox ha some peculiarity in that it will only play back .ogg files in HTML5?

  71. yosoyyon January 15, 2013 - 07:58 EDT

    Thanks for you suggestion is I want to use different formats how will be I have to embed each one? and all this is mate on HTML ? witch program you recommend me to use dor the web builder?

  72. Ethan LongTail January 15, 2013 - 09:56 EDT

    You will have to embed each one, using HTML.

  73. desbest March 3, 2011 - 05:26 EDT

    Whoa! This post is too much. You’ve explained the required codec settings that videos need to play on mobiles, as converting to mp4 is not enough, AND you’ve shown you can use your jw player 5.4 to include an optional HD video tag. I just had to bookmark this page for future reference.

  74. Patrick June 7, 2011 - 04:53 EDT

    Nope… still no link in the Blackberry browser, and no errors. I’m going to do some more testing and see what I can figure out.

Post a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>