LongTail Community Blog

Blog Archives: March 2011

JW Player 5.5 for Flash and HTML5 Introduces JavaScript Plugins

by Zachary Ozer on 2011-03-14 07:37

When we released the integrated JW Player for Flash and HTML5 in October, we also released an updated JavaScript API and our own Embedder. Both were designed to make it as simple as possible to get your content and code running for all viewers, regardless of their device.

Today, we're making it even easier with JavaScript plugins, an HTML5 dock, and alternative embed configurations.

JavaScript Plugins

Since their introduction in JW Player 4, plugins have always been a popular feature of the JW Player. Over the past several years, our developers have worked hard to create dozens of plugins, adding indispensable functionality and fun features. Additionally, our hosted plugins repository has made it super easy for publishers to start using these plugins.

With the launch of the integrated JW Player for Flash and HTML5, it was possible to write scripts that interacted with the player in both Flash and HTML5 modes, but there was no convenient way to distribute that code - until now. With JW Player 5.5, the player will handle the loading of JavaScript plugins in both Flash and HTML5 modes. Just like with Flash plugins, it's as easy as adding another line to your embed configuration, like so:

<div id="player"></div>
<script type="text/javascript">
   jwplayer('player').setup({
    flashplayer: 'player.swf',
    levels: [
      {file: 'bunny.mp4'},
      {file: 'bunny.ogv'}
    ],
    height: 270,
    image: 'bunny.jpg',
    plugins: {
      'helloworld': {
        text: 'Hello world!'
      }
    },
    width: 480
  });
</script>

This loads the Hello World JavaScript plugin from LongTail's plugin repository and registers it with the player:

(function(jwplayer){

  var template = function(player, config, div) {
    
    function setup(evt) {
        div.style.color = 'red';
        div.innerHTML = config.text;
    };
    player.onReady(setup);
    this.resize = function(width, height) {};
  };

  jwplayer().registerPlugin('helloworld', template);

})(jwplayer);

No need to download plugins and no need to distinguish between Flash and JavaScript plugins. The player takes care of it all.

If you're interested in building JavaScript plugins, be sure to join our developer list and check out our guide to Building JavaScript Plugins.

Alternative Embed Configurations

Since it's original release six months ago, the JW Embedder has matured tremendously. The original release simply allowed publishers to control whether to use Flash or HTML5 as the primary embed method. In JW Player 5.4, it gained a download mode and greatly refined the logic around when to embed.

Now, the JW Embedder allows you to specify different configuration for each embed mode. This is especially meaningful for publishers who want to take advantage of numerous benefits of a streaming server like Adobe's Flash Media Server or Wowza's Media Server while still allowing mobile users on iOS or Android to view their content.

While we still officially recommend using SWFObject for embedding, the JW Embedder will soon be our offically recommended way of embedding the JW Player. This will help ensure that all sites using the player will have HTML5 support for both player and plugins.

There are several other enhancements and small bug fixes which are listed on our developer site.

Download the JW Player 5.5

You can download the JW Player 5.5 for Flash and HTML5 here. As always, we would love to hear your feedback on the release. Just post your comments directly to this blog.

Comments (16)     Share

Supporting Mobile Video on Your Site

by Jeroen Wijering on 2011-03-02 10:50

One of the most often asked questions when discussing transcoding is How do I support iPads, iPhones, Blackberries and Android phones?. 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 (1280x720 pixels), older models only supported video up to about 480x270 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 (testing iPhone 3G, iPad)
  • All Android 2/3 phones and tablets (testing HTC Legend, Samsung Galaxy)
  • All recent Blackberry phones (testing Bold & Storm)

Devices
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. 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, 480x270 pixels, around 400/600 kbps (kilobits per second)
  • Audio format: AAC, Low Complexity profile, 44.1 kHz stereo, 96 kbps

It is important to realize these settings do not result in the perfect transcode. Both H.264 and AAC support higher-quality profiles that result into smaller files (but more decoding complexity). Overall, you are probably looking at a 30% file size increase over an encode that is really tweaked, but works on only few devices.

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 (5.4+) of the JW Player. In version 5.4, 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-270p.mp4", flashplayer: "/assets/player.swf", height: 270, width: 480 });

You could enhance this setup by offering a second, higher quality version of the video for desktops/notebooks. This can be done with the HD plugin. For example, you can encode a second copy of your video to the H.264 Main profile, with a resolution of 1280x720 pixels (all other settings the same). Add one line to your embed code, after the height to display the HD plugin:

plugins: { hd: { file: '/static/video-720p.mp4' } },

The end result can be seen below; a good quality video that plays back on nearly any device with a single embed code. On the desktop, an additional HD quality version can be enabled with one click:

Resulting videoplayer that works on most devices.

Special credit given to Daniel Taylor for his contributions to this post.

Comments (72)     Share