LongTail Video blogs

Using the Browsers' New HTML5 Fullscreen Capabilities

PabloS — Thu, 24 May 2012 14:25:34 +0000

One of the killer features for HTML5 video is native browser fullscreen support. Without it, a viewer watching video through HTML5 is limited to seeing the video within the browser window, which is clearly not an immersive experience. In our latest State of HTML5 Video report, we reported that 50% of the browsers people are using now support fullscreen features natively. Some sites you probably currently use (Facebook, for one, in their image galleries) are already using the native browser fullscreen APIs. Here at LongTail, we are bringing this functionality into the next version of the JW Player, but in the meantime, I'll walk you through the new feature, and show you how easy it is to implement.

Note: This article is aimed at website developers who are comfortable editing HTML and CSS, and a little bit of JavaScript

What is Native Fullscreen Anyway?

Native fullscreen means that the browser uses your entire monitor to display content. This means that no other windows are visible, and the browser's menu, tabs, and other elements go away. Compare these two screenshots:

Step 0: Use a Fullscreen Enabled Browser

None of this new functionality will work if your browser doesn't support it. Currently only Google Chrome version 15+, Firefox 10+ and Safari 5.1+ support fullscreen mode. Make sure you have the latest versions of those browsers for these examples to work!

Upcoming versions of the major browsers will all include fullsceen support in some form. Internet Explorer 10 (currently in beta) will provide support, and Opera (who were involved in writing the fullscreen draft spec) are likely not far behind.

Step 1: Decide What to Fullscreen

First, you'll need to create a bit of HTML, and decide what element to blow up to fullscreen when the time comes. Here's a little bit of code containing an image which we'll eventually take to full-screen.

Example code:

<div class="example">
  <img class="video_player" src="image.jpg"></img>
  <button>Click Me To Go Fullscreen! (not yet)</button>
</div>

Step 2: Tell the Browser To Go Fullscreen

You'll notice that in the above code, our fullscreen button doesn't do anything yet. We'll need to write some JavaScript which will take the image into fullscreen mode. I'll explain what everything does in the code itself.

Example code:

<script type="text/javascript">
  function goFullscreen(id) {
    // Get the element that we want to take into fullscreen mode
    var element = document.getElementById(id);
    
    // These function will not exist in the browsers that don't support fullscreen mode yet, 
    // so we'll have to check to see if they're available before calling them.
    
    if (element.mozRequestFullScreen) {
      // This is how to go into fullscren mode in Firefox
      // Note the "moz" prefix, which is short for Mozilla.
      element.mozRequestFullScreen();
    } else if (element.webkitRequestFullScreen) {
      // This is how to go into fullscreen mode in Chrome and Safari
      // Both of those browsers are based on the Webkit project, hence the same prefix.
      element.webkitRequestFullScreen();
   }
   // Hooray, now we're in fullscreen mode!
  }
</script>

<img class="video_player" src="image.jpg" id="player"></img>
<button onclick="goFullscreen('player'); return false">Click Me To Go Fullscreen! (For real)</button>

Step 3: Resize Your Elements

You may have noticed on some browsers (Opera and Chrome) that when you clicked on the fullscreen button that the video player was centered in the middle of a big black screen. That's because by default, fullscreen mode doesn't resize your elements for you. Luckily, there's a simple bit of CSS which will allow you to specify how you want your elements to appear in fullscreen mode. It's called something different in each browser, but in Chrome, it's a CSS pseudo-class called :-webkit-full-screen. In Firefox, it's called :-moz-full-screen. We want our player example to strech all the way across the screen, so that's what we'll do.

Example code:

<style type="text/css">
  .player:-webkit-full-screen {
    width: 100%;
    height: 100%;
  }
  .player:-moz-full-screen {
    width: 100%;
    height: 100%;
  }
</style>
<img class="video_player" src="image.jpg" id="player3"></img>
<button onclick="goFullscreen('player');">Click Me To Go Fullscreen! (All the way)</button>

Fullsceen and <iframe> - a technical note

While you can take pretty much any element and take it to fullscreen mode, <iframe> elements are a bit trickier. You'll need to set the "allowFullScreen" property on the tag itself, which allows the contents to be taken into fullscreen mode.

<iframe src="iframe_src.html" width="400" height="300" allowFullScreen></iframe>

Where Do We Go From Here?

You can make all sorts of changes to your fullscreen elements once you're in fullscreen mode, either using CSS or using some more in-depth JavaScript code. For example, if you had a text overlay that you wanted to make visile in fullscreen mode, you could show it using the -full-screen CSS pseudo class (remember, you need to replicate this property for each browser). The rest is up to your imagination!

How to Stream Live Video From Your iPhone to the JW Player

PabloS — Thu, 03 May 2012 22:26:31 +0000

A few people have asked us if they can stream live video from their iPhones directly to the JW Player. If you're willing to install and configure a few applications, the answer is yes! This guide will provide step-by-step instructions on how to do it.

This tutorial is broken up into three steps:

Step 1: Set up Your Streaming Server

First, you'll need to download and install Wowza Media Server. They have a free 30-day trial available. Once you've installed Wowza, you'll need to configure your Wowza server, by editing files in the install directory. This is different for each platform, but you should be able to easily find where Wowza has installed its files.

Find the applications folder in the Wowza installation folder. By default, there will be nothing there except for a folder called vod. Create a new folder for your live streaming application. We'll call it livu.
(screenshot)
Next, open up the conf folder and create another folder called livu. Then copy the Application.xml file from the conf folder to the livu folder.
(screenshot)
Now open up the Application.xml file. Find the <StreamType> property and change it from default to live.
(screenshot)
Still in Application.xml, find the <PublishMethod> property and change it from digest to none. This will turn off authentication for live stream publishing, so you should only do this for testing purposes.
(screenshot)
Back in the conf folder, open up the file called VHost.xml. You'll need to copy and paste the entire <HostPort> section, so that we can set up the port for our live stream ingestion (RTSP). In the new <HostPort>, edit the <Port> property to read 554.
(screenshot)

Note: On Mac OS X, you'll need to set this value to a number higher than 1024. This is because ports below 1024 must be opened by processes with admin privileges. For example, to avoid trouble, set the <Port> value to 5544.
Now, simply start up your Wowza Media Server. If this is your first time running Wowza, you'll be prompted to enter in your trial license number. When it's started up, make sure your RTSP port (554 or 5544) was successfully enabled.
(screenshot)

Step 2: Set up Your iPhone to Stream to Wowza

Now that you've got your streaming server set up, it's time to set up your iPhone to stream live video. We're going to use a $2.99 app called Livu, which is specifically designed to work with Wowza Media Server. Grab it by searching for "Livu" in iTunes, or by clicking here. Once you've downloaded the app, here's how to configure it:

Open up the configuration menu, and in the Host field, enter the IP address for the computer hosting your Wowza Media Server instance.
Under App, enter /livu/iphone. If you named your live streaming application something different in your Wowza setup, use that name here instead of livu.
Under Port, enter the port your configured for RTSP ingestion in step 6 of the Wowza setup.
If you disabled authentication in step 4, you can leave the User Name and Password fields blank.
Once everything's configured, press the Save button.
(screenshot)
The Livu app should now activate your iPhone's camera. Click the icon in the top left to start streaming.
(screenshot)
If you've configured everything properly, a message will display saying "Stream Started." You're now broadcasting!
(screenshot)

Step 3: Set up the JW Player to Play the Stream

If you've made it this far, the hard part is over. Now all that's left is to configure the JW Player to play your live stream. Here's the embed code you'll need to set up your player:


<div id="player"></div>
<script type="text/javascript">
jwplayer('player').setup({	
  streamer: "rtmp://192.168.0.160/livu",  // Replace this with your own IP address
  file: "iphone"
});
</script>

That's all there is to it. If you've set everything up correctly, the player will display the live video stream from your iPhone!

(screenshot)

The State of HTML5 Video Report - JavaScript, Market Share, Fullscreen, and More...

JeroenW — Thu, 19 Apr 2012 14:00:00 +0000

In January 2012, we announced the launch of our online resource, The State of HTML5 Video Report. Since its launch, we have had a tremendous response from our community. The page itself has been tweeted over 3,000 times, received 30,000 visits the day of its launch, and is still actively circulating the digital sphere.

Three months after its initial launch, we have updated the report with some very interesting findings. First, you will find a new JavaScript section, dedicated to video scripting using the video tag. Common use cases for this are the rendering of custom controls (like JW Player does) or page interaction with the video timeline (like Popcorn.js does). Second, you will find all existing tests updated with results from the latest browsers and mobile platforms. We highlight some interesting findings below.

Market Share

Compared with our statistics from last quarter, we already see shifts in market share. By market share, we mean the portion of the online market that is controlled by a particular browser / device:

IE 6/7/8 are declining quickly; their market share has gone from approximately 28% to 22% in the last few months. IE9, however, is growing (up to 11% market share from 9%). Chrome & Firefox are growing as well. Both have surpassed the share of IE 6/7/8.

Additionally, Android now has surpassed Opera. In terms of the mobile market, iOS still controls roughly 2x (4%) more than the other platforms, due to its dominance over the tablet market & recent success with the iPhone 4S. Other mobile platforms are virtually nonexistent.

Android 4.0

While Android 4.0 (Ice Cream Sandwich) was released last year, not every device-maker has updated their devices to the latest operating system. Still, some devices (like the Galaxy S2) now run ICS, so we have included it in our test results. Unfortunately, we found Android 4.0 to exist as a mixed bag of new features and new bugs. Some of the more interesting findings were:

Support for WebM video decoding. It is in software though, so larger or longer videos do not play.
Support for Apple HLS streaming. Unfortunately, quality switching has not yet been implemented.
The video tag controls are still buggy. It is still difficult to start a video in HTML5.
The scripting API is still a bit buggy - no metadata, no errors & no buffering. API for playback and seeking have improved though.
Videos play inline on mobile phones, which creates an awkward UX. A fullscreen button is available, but it is as equally hard to click as the play button (e.g. they are both tiny).

Fullscreen API

There have been several updates on the state of Fullscreen playback in HTML5, which is pretty exciting for online video. While Chrome & Safari already supported the Fullscreen API, Firefox recently introduced support for it too (view our test page here). Thus, between these three browsers, the majority of the browser market supports fullscreen playback in HTML5. Opera is actively working on fullscreen support; presumably IE10 will introduce beta support as well.

Other interesting developments that you should stay tuned for more information on include Firefox's drop in support for the fullscreen button, and the discussion around fullscreen support in mobile devices, which becomes more relevant now that Android 4.0 plays the video inline.

We hope you take a look at the most recent version of our published report, share with your community, and send us your feedback! Feel free to post your comments directly to this blogpost, or join the discussion on our Facebook page.

Encoding WebM Videos

JeroenW — Tue, 06 Mar 2012 15:02:33 +0000

WebM is coming up on its second anniversary. Released by Google as a royalty-free alternative to MP4, the video format has slowly gained traction on the web. MP4 still rules by a wide margin, but WebM has dethroned Ogg as the other leading format for HTML5 video.

This post describes two tools for encoding WebM videos: a desktop client and a cloud service. Both are free, easy to set-up and painless to understand. Which one you choose depends upon your personal preference - or the restrictions your company's IT department imposes.

Desktop Encoding

For desktop encoding, Firefogg is the best option. It is not a standalone tool, but an addon for the Firefox web browser. If you have Firefox installed, go to Tools » Addons to search for and install Firefogg. If you don't have Firefox, get it here.

With Firefogg installed, go to Tools » Make Web Video to start an encode. Now select your original video, select your output preset (360p is a good one) and click encode. Firefogg starts crunching and minutes later your WebM video will be done.

Select Advanced Options in step 2 to customize the video Size and the audio/video Quality. The sweet spot for video quality seems to be 7 (smallest file without artifacts). The sweet spot for audio is 3 (112 kbps). Be sure not to change any of the other options, unless you know what you're doing!

That is it on the desktop side - short and simple. Firefogg may not have the best looks, but it gets the job done. If you're looking for something more professional, check out Sorenson Squeeze . It has many more options, but is also not free.

Cloud Encoding

Now let's go online. Our very own online video platform, Bits on the Run, is easy, free and capable of WebM encoding. Sign up for a Free Account and log-in to the dashboard. Go to Account » Settings » Templates and click Add new Template to create an encoding template. Set the format to WebM Video.

On the next page, set the Target width to 480 pixels and the audio/video quality to the good tradeoff option. This gets you the same results as the Firefogg settings above. Next, set the Automate option to Automatically apply, so your WebM video are automatically built every time you upload a new original. Save the template.

Now go to the Videos section to upload an original video. When the upload is complete, go to the Transcodes tab to see the encoding progress. Your WebM template is listed here. When the WebM transcode is done processing, you can click its yellow Publish icon to copy/paste its URL, or to download it to your computer.

Like Firefogg, Bits on the Run provides a basic encoding interface with only the essential controls. A dedicated transcoding service like Zencoder.com offers many more options, but is also much harder to use.

The End Result

If you're reading this post in Chrome, Firefox or Opera, the resulting WebM video can be seen below. It is embedded using this JW Player setup. The unavoidable MP4 version is encoded separately, so Internet Explorer and Safari users are not left out:

Download the WebM video here

Video footage above credited to Matt Trunks, full portfolio here.

That is all for now! Much more info can be found on the WebM project site. In particular, this page has a wealth of information about encoding parameters. Visit their blog for news on hardware, software and ecosystem support.

HTML5 Takes the Lead on Android Devices

PabloS — Tue, 28 Feb 2012 14:30:28 +0000

Even before Adobe's announcement back in November that it would cease supporting Flash on Android devices, it was becoming clear to us at LongTail Video that the JW Player would need to shift its focus on Android devices towards HTML5 mode. We took the first step with the release of the 5.9 player, which now embeds itself in HTML5 mode on all Android devices by default, since our testing has shown that Android is fully capable of playing HTML5 video. But there are several reasons why HTML5 should be the delivery mode of choice on Android, with or without Flash. This blog post will attempt to address a few of them.

Limited Future Support for Flash

This one should be obvious, so we'll get it out of the way. After the current generation of Android devices running Froyo (2.2), Gingerbread (2.3), Honeycomb (3.x) and Ice Cream Sandwich (4.0) are either phased out or upgraded to future Android versions, Flash will no longer be supported in the browser.

Video Player Behavior on Mobile Devices

It is difficult to put forth a general rule for how video players should behave on mobile platforms. In fact, the term "mobile" is itself too general in this context, since viewing a web page containing video is a very different experience depending on whether you are viewing on a smartphone with limited screen real estate, versus watching on a tablet with more room for your fingers to interact with the content.

If you load the JW Player on an Android smartphone in Flash mode, you will get the same version of the player you would have gotten had you loaded it on a desktop browser. However, everything will be scaled to the size of your phone's screen, including all of the button controls. Not only would the buttons be hard to press, but they wouldn't really make sense in the context of watching video on a phone. Conversely, the player's HTML5 mode relies on the phone's own built-in video controls, which are optimized for the screen size. Additionally, HTML5 video will always play in full-screen mode on Android smartphones, which is a much better experience.

Viewing video in a browser on a tablet isn't as cut-and-dry of an issue. The screen is larger, so it is possible to have a usable video playing inside of the page content. This can be done in both Flash and HTML5 modes, so the decision of which to use comes down to performance (despite its reputation, Flash doesn't perform that poorly on most Android devices when it comes to video) and usability (the built-in HTML5 controls are optimized for touchscreens, while the Flash controls would need to be modified to work well on touch devices).

Lastly, we feel that it is important to provide a consistent experience across all mobile devices, not just Android devices. Switching to HTML5 playback for Android means that users on both Android and iOS devices will see the same things:

Fullscreen-only playback (on phones)
No overlays on top of the video player while a video is playing
Built-in touch screen controls

Flash Embedding on Mobile Browsers

One issue we've noticed with Flash for Android is that it "steals" interaction events from the browser. For example, if you're scrolling down a page using the one-finger swipe gesture, and your finger happens to brush over a Flash element on the page, Flash will interpret this as a mouse click. In the case of the JW Player, the player will begin to play, when what you actually wanted to do was scroll down the page. Using native HTML5 elements eliminates this sort of behavior, since those elements distinguish between different types of gestures.

HTTP Live Streaming (HLS)

Beginning with Ice Cream Sandwich, Android devices will support HTTP Live Streaming (HLS), which has become the de facto standard for streaming video over HTTP. This is the same format which is used to stream video content to iOS devices. Unfortunately, HLS is not supported natively in the Flash player, making this another reason to favor HTML5 over Flash on Android. For an explanation of what HLS is and why it's important, check out our blog post on the subject.

Android Support in the JW Player Going Forward

For all of the reasons described above, we feel that it is necessary to focus our Android development efforts on HTML5 and not Flash. Flash mode will still be used as a failover on Android devices which support it; for example, if your player configuration specifies an RTMP stream (which can't be played in HTML5 mode), the Flash player will still be used. And if you disagree with our decision, you can still specify Flash as your primary renderer by setting the modes block in your player configuration. But we think you'll find that for Android, HTML5 is the best way to go.

HTML5 Video Ads: Coming To a Mobile Device Near You

PabloS — Tue, 21 Feb 2012 20:00:59 +0000

As HTML5 grows its share of the online video market, web video publishers are beginning to look for ways to monetize videos being played outside of the traditional Flash advertising methods. But when someone watches a video in HTML5 mode, what should that experience be like? What's possible, given the current state of the tech?

HTML5: Desktop vs. Mobile

Before we begin talking about the challenges that face HTML5 video ads, it's valuable to acknowledge that video in HTML5 can behave very differently on the desktop compared to the same HTML code running on mobile devices. Here are some of the primary differences:

	HTML5 Desktop	HTML5 Smartphone	HTML5 Tablet
Clickable Overlays	Yes	No	Depends*
Clickable Video	Yes	No	Depends*
Companion Ads	Yes	Not visible	Yes
Fullscreen mode	Optional	Always	Optional
Customizable controls	Yes	No	Yes
Available Bandwidth (probable)	LAN/WAN	3G/4G/WAN	3G/4G/WAN

* Platform-specific

As you can see from the table above, some concepts that advertisers take for granted, such as video ads which cause a web page to be displayed when clicked, are not possible on smartphones. For example, on most mobile devices, once an HTML5 video begins playing, whether it's an ad or not, the phone will enter fullscreen video playback mode. In this mode, the user has full control over the playing video, including the ability to seek to the end of it.

Technical Challenges

As the major ad networks are beginning to offer support for HTML5 video ads, they face several important challenges.

Video Codec Incompatibility (WebM vs. MP4)

One issue which HTML5 video publishers are already familiar with is that to support all platforms, video must be encoded into multiple formats — WebM (or Ogg Theora) for Firefox, and H.264 for everything else. Second, someone (whether the browser, ad network, video player, or publisher) will need to select the appropriate format and display it to the user. This can be difficult to implement in an ad scenario, especially if ad networks don't account for the user's browser when generating an ad response.

Crossdomain Issues

An additional technical concern is that loading external assets (a VAST XML response from an ad server, for example) brings with it certain restrictions in JavaScript. These restrictions need to be worked around on the server hosting those assets.

<Video> Tag Access

Depending on the implementation, most ad networks require direct access to the player's <video> tag in order to play an ad in HTML5. This makes sense, considering that in iOS, each distinct <video> tag placed on a page needs to be clicked by the user in order for the video to be played. If the ad were to be played in a new <video> tag which was placed on top of the player, the user would need to click "play" twice - once for the ad and another time to watch the main video. This presents some interesting problems. While the ad is playing, the player needs to treat the events flowing from the <video> tag differently than if the main video were playing. After the ad has played, the video tag needs to be restored to its original state (the video playing, its position, etc).

Industry Roundup

Considering the relative newness of HTML5 video (and the challenges listed above), it's unsurprising that not many video ad networks have implemented full HTML5 support yet. That being said, there are a few ad networks who have made some progress on this front:

Google recently released HTML5 support in their Interactive Media Ads (IMA) product. This implementation allows publishers to set up VAST ads, with certain limitations based on device compatibility. The JW Player's Google IMA Plugin includes beta support for HTML5 mode.
YuMe has been steadily improving their HTML5 support, which is now supported in the JW Player's HTML5 mode via the YuMe plugin.
Most other video ad networks (Tremor, SpotXchange, BrightRoll, and others) have either announced, or are currently implementing support for mobile devices, which will mean HTML5-compatible ad media.

Future Considerations

As in Flash, as more publishers attempt to handle more sophisticated scenarios, new techniques must be devised to handle them. Dynamic bitrate switching, for example, allows publishers make on-the-fly optimizations for video ads based on screen resolution and available bandwidth. Apple HLS (HTTP Live Streaming) is on its way to becoming the standard streaming format on mobile devices — with competition coming in the form of MPEG DASH, which was ratified as an ISO standard last week. Both HLS and DASH are based around the idea of a manifest file, which keeps track of smaller chunks of video that can be stitched together into a single seamless video. To insert an ad into this stream can be as simple as adding the ad chunks inside of the manifest file at the appropriate times, a technique known as dynamic ad insertion. A more general optmization we'll be moving towards is ad delivery which is optimized for variable-bandwidth environments, as many mobile users are viewing content over slower wireless networks.

In short, we're still a long way from having a turnkey video advertising solution for all HTML5 viewers, but we're closer than ever before to achieving that goal.

Using Closed Captions for Online Video

Meagan — Mon, 13 Feb 2012 15:45:21 +0000

Web video accessibility is a broad term that refers to making videos usable for all types of viewers. Traditionally, it refers to those with impairments, but more recently the definition has broadened. At LongTail Video, we feel strongly about creating the means of equal access to online video content. By building products that support features such as multi-language video captions, we aim to increase viewer accessibility. Though there are many pieces to making a video fully accessible, in this post we focus the discussion on closed captions.

Understanding Video Captions

Video captions are very similar to subtitles. The major difference is that captions describe all of the relevant audio detected in the video, whereas subtitles focus solely on the words spoken in the film. For example, if a phone is ringing in the background a caption will display something like, "the phone is ringing", and a subtitle will display nothing. Captions are "closed" when a user can toggle the captions on/off during video playback. Captions are "open" when they are burned directly into the video, which means they are displayed 100% of the time. Making sure your captions are closed is important - it allows you to support all types of users with the same piece of media, increasing both accessibility & inclusiveness.

The Current State of Video Captions

Captions have conventionally existed for television, but only more recently have been introduced into online video. Although The World Wide Web consortium (W3C) has established a set of guidelines known as Web Content Accessibility Guidelines that provide a standardized and definitive set of rules for how to develop accessible online content, online video accessibility federal regulations are still in their infancy.

Since 2010, American accessibility advocates have urged Congress to modify an existing bill that would mandate captions for any online video that has also appeared on TV. Just last month, the Federal Communications Commission (FCC) released their final rules on closed captioning for IP-delivered video programming. Though only a small step towards a more universal regulation, it applies to all full-length video television programming in the United States, previously distributed with closed captions.

As closed-captioning of online video programming emerges, speed of adoption is key. Whitehouse.gov is an early adopter who uses the JW Player with our Captions Plugin to display their cataloged live broadcasting footage.

Hulu's CTO, Eric Feng quotes that “users send us feedback about closed captions more often than almost any other feature, so what started as a small side project has turned into a very important part of our user experience...”.

Video Captioning Tools

In our own product development at LongTail Video, we see similar requests, and have recently pushed two product updates for online video captioning:

Bits on the Run Video Captioning - we now allow users to upload captions in the SRT and DFXP formats to the Bits on the Run Dashboard. Users can then publish their videos with closed captions for accessibility and Section 508 compliance. In addition, videos can now be published with multiple subtitle tracks, for viewers language selection.
JW Player Captions Plugin for HTML5 - we recently updated our Captions Plugin to support both Flash and HTML5 mode. This means closed captions will now appear in both the Flash and HTML5 rendering mode for videos embedded with the Captions Plugin.

Aligning with the trends in industry, the tools in which closed captions are created have improved as well. Services such as Subtitle Workshop and Jubler are offline tools used to edit text-based subtitles, or in our case, closed captions. Online services that we recommend are Universal Subtitle and our partner, dotSUB.

Added Benefits of Video Captioning

What video publishers may not yet realize is that there is more to captioning videos than simply increasing accessibility among the hearing-impaired. In fact, there are quite a few side benefits such as:

Mobile video - when users watch mobile video, sound is not always available, or loud enough.
Language barriers - for non-native-language viewers, closed captions make it easier to follow the video.
Search engine indexing - as quoted by Google: “When you start adding text to all of your videos, search is aided tremendously.” Textual descriptions of your video footage increase the accuracy of the content indexing.
In-video search - with your text indexed, it becomes easy to implement an in-video search which allows a user to jump directly to a particular section within the video. Check out Hulu's implementation of their captions search feature.

As video captioning enters the HTML5 market, and standards are developed around the element, captions will become even easier to publish.

With big names in video like Hulu and YouTube (where captions are included on all English-language videos uploaded after April 2010), putting emphasis on closed captions, we can be certain that the future will indeed be captioned. We encourage you, as a video publisher, to start experimenting with video captioning and create a workflow where closed captioning is a regular part of your video publishing process.

JW Player 5.9: HTML5 Now Default on Android

PabloS — Thu, 02 Feb 2012 16:59:41 +0000

As we continue to bring HTML5 support in the JW Player closer to parity with Flash mode, we've focused the 5.9 release on a variety of HTML5 stability and user experience updates:

HTML5 is now the default playback mode on Android Devices

In early November, Adobe announced it would stop developing its Flash Player for Android devices. As a result we've decided to focus our energies on optimizing HTML5 support on Android rather on a legacy platform.

Cleaner User Interface (Especially on iOS devices)

We've taken a number of steps to clean up the way the player looks and behaves, focusing on iOS. Although they're subtle, we think you'll appreciate them. Among the improvements are:

The preview image now fades in when player loads
Video is not displayed until it is sized correctly and ready to play
The buffering icon appears on the iPad while video is loading

Saved Volume in HTML5

One feature from Flash mode that you told us you wanted to see in HTML5 was the player's ability to keep track of the last volume level selected by the user. Now, if a user reloads a page, or goes to a different page on your site, the player will be set up with the same volume (or mute state) as the last time they set it. (Note: this won't work on iOS, since websites are not allowed to set the volume of those devices)

Download the JW Player 5.9

You can download the JW Player 5.9 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.

Check out our release notes for this version. For a complete list of the tickets addressed in JW Player 5.9, please visit our developer site.

Introducing The State of HTML5 Video Report

JeroenW — Thu, 26 Jan 2012 18:07:12 +0000

Today we announced the public launch of our latest resource, The State of HTML5 Video Report. For two years our JW Player team has researched and monitored the evolution of HTML5 video capabilities so that we could effectively support it. Beyond our own products, we believe that the community at large will benefit from this work. We are extremely pleased to share our detailed research with the community.

We grouped our test results into the few topics we've found to be the most critical. Each section is fleshed out, and to the best of our ability accurately represents the state of HTML5 online video today - complete with our published test pages & results. The topics covered in the report include:

Market Share of Browsers and Devices
Media Formats
Tag Attributes
Fullscreen Playback
Adaptive Streaming
Accessibility

Get full access to the online report here. Each time we update the report, we will post a notification on our Facebook page, as well as on our Twitter account. Be sure to like us on Facebook and follow us on Twitter to stay informed.

Whether you are well-acquainted with HTML5, or just getting started, the content presented in our report is an indispensable resource for tracking the progress of HTML5 video. As HTML5 video progresses, we will update and amend this report to accurately reflect the state of the industry.

We have already received such a great response from our community, and as always appreciate the support. In addition to the applause, we have also received valuable feedback from other HTML5 experts, and intend to edit the report where necessary.

The JW Player team will be participating in discussions with the community around HTML5 video. Visit us on Facebook to join the conversation.

2011: Year in Review

Dave — Mon, 09 Jan 2012 15:46:35 +0000

With 2011 behind us and beginning of 2012 well on its way, I thought that it would be a good time to share some of our progress over the past twelve months.

In short, 2011 was an amazing year for LongTail Video. We experienced incredible customer growth across all of our products (more on that below) and successfully released a number of fantastic new products and features. Here are a few of the highlights:

Over 1.5M sites now actively use our products
Launched HTML5 support in the JW Player
Released our new content syndication product called LongTail.tv
Introduced Bits on the Run Free accounts for our users
Achieved positive net income and cash flow for the entire year

Of course, all of this could not have been possible without the ongoing support of our customers and community, which provide us with an invaluable feedback on what the market needs. Our entire team cannot thank you enough for all of your input.

Looking forward, we have several exciting product releases on the horizon that we think will further cement our position as the leading provider of affordable video tools for publishers seeking to manage and monetize their online video. We look forward to working with you to ensure that we are meeting your expectations.

Thanks again for your incredible support. Here’s to another great year in 2012!

Best Wishes,

Dave

The Future of Mobile Video is Apple, For Now

JeroenW — Mon, 12 Dec 2011 16:00:26 +0000

Consolidation has begun in the mobile video space. In early November, Adobe announced it would stop developing its Flash Player for mobile devices (read: Android). Going forward, HTML5 will be the only method to play back videos on mobile phones and tablets. This is a big win for Apple, the company that most strongly opposed Flash in the last few years

According to Adobe, Android 4 (Ice Cream Sandwich) will be the last mobile platform to get a Flash plugin. The OS is launching without one, though. Given the terrible track record of Flash for mobile, we shouldn't be surprised if it never arrives. Ergo, video publishers should ensure their video works in HTML5 on Android today.

Apple is winning under the hood as well. The H.264 codec is baked into the CPU of every single mobile phone today, while WebM is still confined to a software-only (and non-HTML5) implementation on some Android devices. Google is working on hardware, but the path from reference designs to integration in phones and, eventually, market share is a long one.

Until WebM hardware decoding is supported by a decent slice of mobile devices, video publishers will continue to focus on H.264. Seeing this, Google continues its support for H264 in Chrome, despite the announcement to drop it "soon" almost a year ago. For all intents and purposes, H.264 is the baseline codec for HTML5 video at present.

Completing its hat trick, Apple is well on its way to providing the de facto streaming protocol for mobile video: HLS. Built on top of HTML5, this protocol allows publishers to deliver their videos securely with high quality. I should note that this is relevant only to roughly 10 percent of all publishers, but these publishers account for 90 percent of all mobile views.

What Is HLS?

The acronym HLS stands for HTTP Live Streaming. It is a protocol that allows publishers to stream video using plain HTTP web servers, as opposed to often expensive and hard to scale dedicated streaming servers. This streaming is achieved by chopping up the video hosted on the server into small (usually 10 seconds) fragments, stitching them together again in the browser. The browser only requests the next fragment in line, instead of loading the entire video and wasting bandwidth, as happens in vanilla HTML5. See diagram below for a single fragmented stream:

A video streamed through HLS is usually encoded into multiple qualities, ranging from a mere 180px to full-blown 720px and beyond. Every time the browser returns to the server to load the next fragment, it decides which quality level to load. The browser thus continuously adjusts the quality of the stream to best match the available bandwidth. This is hugely important in mobile, with devices perpetually swapping between 2G, 3G, 4G and WiFi connections. See diagram below for an adaptive fragmented stream:

In addition to this, the fragments of HLS streams can be encrypted for secure delivery. Users who intercept these fragments will not be able to play them at all. This is a big security advantage over plain HTML5 video, where every savvy user can find the URL of a video and download it for his own use.

Why Use HLS?

Today's wide usage of the HLS protocol is a result of the success of iOS. Apple designated the protocol as the one and only way to stream video to the iPhone and iPad. No Flash, no Silverlight, no RTP or RTSP. On top of that, HLS is required for in-app video. Even simple MP4 downloads, which do work for in-browser playback, are not allowed in iOS apps.

Every major publisher therefore needs to use the HLS protocol, and every major encoding tool (e.g. Sorenson Squeeze) and streaming server (e.g. Flash Media Server or Wowza Media Server) supports it nowadays. This broad ecosystem, in turn, now has many devices that support the protocol as well. Nearly every popular set-top box can play HLS (Xbox, PS3, Roku, Apple TV, Boxee), as will Android phones running the new Ice Cream Sandwich release.

Wondering if there are any competing protocols? Absolutely. Smooth Streaming from Microsoft is one, but it requires the non-mobile Silverlight plugin. There is also Dynamic Streaming from Adobe, which requires the soon to be retire? Flash plugin. HLS is built on top of HTML5, which makes it easy to implement by both browsers and devices.

A standardization effort is on its way as well, in the form of MPEG DASH (HLS, as well as RTMP and RTSP. However, as things go with standards, progress is slow and broad support is years away.

The Apple Standard

So, for the foreseeable future, we'll watch our mobile video the Apple way: embedded using HTML5, encoded using H.264 and streamed using HLS. Any platform that wants broad support for quality video (Windows Phone?) must implement HLS and any publisher that wants many mobile viewers must leverage HLS.

Now, is this a bad thing? Quite the contrary. The alternative to a central protocol is fragmentation: multiple plugins, multiple codecs and multiple protocols. Which is bad for large media corporations, as it reduces their bottom line. Even worse for smaller video publishers though, since they lack the resources to even make their video available at all. And that, in turn, is a detriment to mobile video at large. The key to mass adoption is broad-reaching availability across a wide variety of content.

This blogpost is a modified version of our article first published on Mashable. Read Full Article Here.

JW Player 5.8 Released with Support for HTML5 Video Ads

PabloS — Tue, 18 Oct 2011 13:00:21 +0000

This release of the JW Player 5.8 focuses heavily on stability HTML5 playback and secure plugin loading. The major addition is support for HTML5 video advertising for Google DFP and YuMe users. Read more to find out what's new.

Ads in HTML5 Mode

JW Player 5.8 introduces support for HTML5 video advertising. Users of the JW Player have become accustomed to providing a consistent user experience independent of the browser or device of their viewers, but until now the player didn't offer HTML5 video advertising support. With JW Player 5.8, we now enable HTML5 video ad support for both Google DFP and YuMe publishers - allowing users to run video and companion ads on iOS devices (iPhone/iPad). Check them out: Google Interactive Media Ads (IMA) & YuMe.

Increased Stability in HTML5 Mode

With the release of JW5.8, we took the opportunity to focus on video playback in HTML5 mode. Thanks to all the feedback you have given us, we've been able isolate the outstanding issues, and greatly improve the stability in HTML5 mode. We are always working to seamlessly integrate Flash and HTML5 modes, so please keep the feedback coming. For a detailed list of specific HTML5 improvements, see our developer site.

Secure Plugin Loading

If you manage a secure website, then you are probably familiar with the mixed content security warnings generated by browsers, particularly IE, when embedding the JW Player on a secure page. This was due to the fact that the JW Player always loaded its plugins over HTTP. JW Player 5.8 now detects if it is running on a secure page and loads its plugins over HTTP or HTTPS accordingly. Publishers embedding on Facebook should find this particularly helpful!

Download the JW Player 5.8

You can download the JW Player 5.8 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.

For a complete list of the tickets addressed in JW Player 5.8, please visit our developer site.

HTML5 Video: Still not there yet, but making headway

PabloS — Mon, 10 Oct 2011 14:00:29 +0000

Last year, we declared that HTML5 video was not quite there yet. Well, it's nearly 18 months since that post, so what's happened in the intervening time?

Let's start off with the positive: compared to 18 months ago, the browsers' implementations of the <video> tag have become much more stable. They also all have built-in support for pseudo-streaming (i.e. the ability to seek to an unbuffered position in the video file). The tools surrounding HTML5 video — streaming servers, transcoders, etc. — have also improved.

On the other hand, many of the issues we pointed to in our last post have not yet been resolved. HTML5 video is still "not quite there yet", but we'll take a look at the developments over the past year and make some predictions on where this is all headed.

Answering some open questions

In our last post on the subject, Jeroen mentioned three major issues which prevented HTML5 video from taking off. Let's see where these issues are today.

Codec support

The major question surrounding codecs revolves around whether open video codecs such as Google's WebM and Ogg Theora would overtake proprietary formats such as H.264. As before, this still comes down to browser and device support. Though the open-source browsers have decided on an open format — WebM — no current mass-market mobile device has hardware drivers which can decode VP8 (the video codec used in WebM).

On the desktop, the sides seem firmly entrenched. Apple has no interest in moving away from H.264, considering the investment they've made in the technology. Microsoft doesn't support WebM natively (users need to manually install the codecs). Firefox and Opera still have no desire (or, possibly, ability) to support H.264. And although Google announced in January that H.264 support would be removed from Chrome, more than 8 months later, there's been no indication when (or even if) this will happen.

The codec wars are still being fought full-steam. And the end result of the lack of a standard video format is that many publishers simply encode once — in H.264 — and rely on Flash for support in browsers that don't support it.

Streaming

We predicted that the browsers would choose to implement their own streaming mechanism to compete with Apple's HTTP Live Streaming (HLS) format (built into desktop and mobile Safari). The question would be what open standard would be chosen to build upon?

What happened instead is that this area was more or less overlooked. Safari Desktop and Mobile, and Android 3.0+ are still the only browsers with built-in support for an HTML5 streaming protocol. Publishers who require that their content be streamed (rather than simply downloaded) on any other device or browser must fall over to a Flash or Silverlight player.

Moreover, a common streaming format has still not been agreed upon. The browser vendors are reluctant to hitch their wagon to any one method of HTTP streaming — for technical reasons, and because they're waiting to see which formats users begin implementing themselves. Of course, this is something of a chicken-or-egg proposition.

Fullscreen

A draft standard for adding fullscreen support to browsers has been written up and more or less agreed upon. Safari has already implemented support for this in version 5.1. While no other browsers have implemented the necessary APIs, Chrome (which uses the same rendering engine as Safari, called Webkit) is probably the closest to making this a reality. ~~Although Mozilla wrote the spec, there's currently no word on when Firefox will implement it~~ Firefox has implemented fullscreen support in their nightly build, but the feature is disabled by default. In short, true fullscreen functionality is still lacking on most browsers.

It's worth mentioning that on most mobile phones (not tablets), HTML5 videos will always play in fullscreen mode. This is partially due to limitations in hardware, but it also makes sense from a usability perspective — if you're watching video on a web page on a 3.5-inch screen, do you really want to see anything other than the video itself?

What's coming up

So what can we expect within the next 6-12 months? We recently attended the Open Video Conference in New York, and rubbed shoulders with the people who are making HTML5 Video happen — browser engineers from Apple, Google, Mozilla and Opera were all in attendance (not to mention YouTube, Netflix, Internet Archive and many more). Everyone had a ton to bring to the table (Silvia Pfeiffer, who organized the conference's Open Media Developer track, has written a great summary of the work that went on). And while there's a lot of exciting technology being built, the core problems I mentioned earlier which are preventing HTML5 from becoming the de facto standard in web video (format compatibility and streaming) are still not being addressed in a unified way.

That being said, some of that new stuff is pretty cool, and may end up moving the needle. Let's take a look.

The <track> Element: Adding Text Elements to Media

The HTML5 <track> element is for adding timed textual metadata to a media element. This enables video players to add functionality to support subtitles, closed captions, chaptering and more. While none of the browsers currently support <track> natively, we got to see a cool JavaScript demo which added captioning functionality into a <video> tag.

Once this becomes a reality, text tracks will be an exciting new development in HTML5. It will help make video accessible to the seeing- and hearing-impaired, enable subtitles for foreign language speakers, and make video files indexable (and therefore searchable). All of these will pave the way for video and audio to become first-class citizens on the web.

MediaSource API: Direct access to video data

Google is working on a feature for Chrome, called the MediaSource API, which will allow JavaScript developers to manipulate video data at the lowest possible level (the byte stream). One application of this mechanism would be for video players to piece together small bits of video, serving as the basis for an adaptive streaming application.

This approach puts the onus on JavaScript video players, such as the JW Player, and on video content providers, to come up with their own solutions for streaming video in HTML5. While I'm sure there will be attempts at making this happen, the jury's still out on whether this method can become the basis for HTML5 video streaming, for the usual reasons — browser fragmentation, and the ever-present format wars (Chrome's implementation will only support WebM at first). My personal opinion is that until the browsers present a standard for HTTP streaming to developers and publishers, you'll see a couple of cool demos, maybe even an end-to-end solution (think Netflix or YouTube), but not an overall standard.

Conclusions

Yes, progress has been made. The tools are better (for example, the popular desktop encoder Miro Video Converter now includes support for WebM). The servers are better (Wowza Media Server and Adobe Flash Media Server (FMS) support both Apple HLS for HTML5 streaming and RTMP for Flash streaming). And the browsers are better, especially the mobile ones (many of the HTML5 video bugs in Android and iOS were fixed in versions 2.3 and 4.0, respectively).

So why did I say at the beginning of this article that HTML5 still isn't there yet? Why isn't Flash losing more ground, considering its own drawbacks (poor resource utilization, lack of support on iOS, to name a couple)? The simple answer is that Flash offers a safer, more uniform cross-platform environment for video developers and publishers, while HTML5 presents a dizzying array of browsers to test against, and competing formats to support. You still need both Flash and HTML5 to cover all of your bases, but most publishers are still choosing Flash as their primary video delivery platform for these reasons.

The JW Player will continue to stay close to the bleeding edge of HTML5 video, and we'll continue integrating both Flash and HTML5 together as seamlessly as possible. We're rooting for HTML5 and its promise of open standards, better accessibility and better performance. But it'll still be some time before HTML5 has everything it needs to take its place at the head of the table.

Social Sharing - Publish Your Videos to Facebook, Twitter & YouTube

Meagan — Sun, 25 Sep 2011 14:10:42 +0000

Video shared within your social networks - you've seen it, you've watched it, you've probably even Liked it. Online video sharing is becoming increasingly popular among social media users, consistent with the upward trend of overall online social media usage. Social media now accounts for 22.5% of the time that that Americans spend online. These sites are where users are going to look for news, entertainment, and social engagement. In this post, we discuss why and how you should leverage Facebook, Twitter & YouTube for distributing your videos.

Why Publish my Videos to Social Media Sites?

We've grown accustomed to a culture where sharing content is second nature, social media is now an established part of the web, and video is undeniably more engaging. The content we share is often a personalized reflection of the publisher. It allows for a more intimate connection with the person, the product, or the goals of the business.

Sharing video is easy and effective

Take Facebook for example, which is currently dominating the social media scene. In fact, usage statistics for Facebook are still growing. These are some exciting trends, and provide reason to believe that they align with the numbers for online video sharing within Facebook.

Video shared on Facebook performs better than video watched elsewhere - that is, Facebook users are more engaged and tend to watch more (if not all) of the video clip. Back in April 2011, we published a blogpost on the ease of getting your videos on Facebook. One of the more exciting Facebook features introduced this year was the ability for third parties to publish & playback video content directly within their Newsfeed, allowing individuals to watch videos from all over the Internet without ever leaving Facebook. As a result, Facebook drives 11.8% of all referred video traffic to media companies.

Friends trust what friends recommend

Its no surprise that there is a direct relationship between social media referrals & viewer engagement rates. Friends, or niche online communities statistically have similar interests, and they trust each other. Social networks give users access to particular & pertinent content that they may not find elsewhere. Users give more weight to content suggested by their friends. This is the essence of viral video marketing - create good content, and it spreads by word of [virtual] mouth.

This trend holds consistent within Twitter. As a Twitter user, you've chosen to follow specific "tweeters", and are more apt to trust the links they post. If someone you follow pushes the content, its probably both relevant and interesting. Unlike Facebook users that expect to stay within the platform, Twitter users are already comfortable with clicking through to watch recommended content. This often works to video publishers benefits, in that it sends traffic directly to the source (i.e. your main site or product page).

Video stays online, forever

Just like online content, online videos are indexed by google and over time draw traffic to your site. YouTube.com has become the largest repository of online public video, much of it user-generated content. YouTube videos are watched more frequently and stay popular longer.

YouTube.com is not only the world's biggest video portal (and free TV), it is also the world's most popular video search engine, following the footsteps of its parent company, Google. According to their 2010 Stats, each minute 48 hours of video are uploaded, and over 3 billion videos are viewed every day. Since 70% of YouTube traffic comes from outside the U.S, its a great tool for expanding your content's reach. To make it even more accessible, it has a variety of specific applications for direct integrations with a wide range of devices, from smartphones to settop boxes and connected TV's.

What Actions Should I Take Next?

As you begin to build your video presence across key social media tools, we offer a few tips for getting started with each:

Twitter - When posting on twitter, we recommend using a URL shortener for the full video URL. This allows you to focus your message on describing the content, and add in any desired external tracking links. The beauty of Twitter exists within its "retweet" functionality. Retweets from your followers help your content gain popularity across borders. Word travels in seconds from the US to China. In the end, its impossible to track who is at the receiving end of the content you post.

Facebook - Publishing video to Facebook is simple. You can either publish the video URL directly, or embed it on a website with a customized JW Player (through the use of opengraph to share video online). If you prefer the latter, click here for implementation instructions.

YouTube - YouTube allows you to create a real video presence. You can brand your channel and create a social media landing page. By using extensive titles, tags, and descriptions your video content will be better indexed by their search engine. Our own online video platform, Bits on the Run, offers an easy way to upload directly to YouTube, occurring simultaneously with your upload to the platform. Read our Upload to YouTube Tutorial for more information.

From Your Site - The JW Player offers a variety of social media plugins that publish your video content directly to social media sites. We recommend starting with the Sharing Plugin. This plugin supports several sharing options: video embed code, video URL, and direct posts to Facebook or Twitter.

Conclusion

Whether your ultimate goal is producing video as core marketing material for your business, or you are an individual looking to create an online presence for yourself, social media will help you. It helps spread your name, your cause, and your goals. It brings viewers to your site, creates engagement around your content, and certainly gives you and your team instant feedback.

HD Video Everywhere!

JeroenW — Wed, 24 Aug 2011 06:05:27 +0000

These days, HD quality video is no longer an option - it is essentially a requirement. On the other hand, there are still quite a few viewers out there that are unable to play high quality video, due to connection or device constraints. A simple way to fix this is by offering an HD toggle in your player. Viewers that want the full experience select the high quality option, while viewers that don't have the capabilities (or interest) select the low quality option.

With a combination of some thoughtful encoding and the HD plugin for JW Player, creating such a setup is very easy. This post explains how to encode for and embed a player with an HD toggle that works on the desktop, as well as on the Android, iPad and iPhone. We'll even discuss how to support HTML5 everywhere by including a WebM HD toggle.

HD video on Chrome/Windows, the iPhone an Firefox/Mac.

Encoding

First, we have to render two versions of our video: an HD one and a lower quality one. Since the iPad, the latest iPhones and Android flagships - like the HTC Desire and Samsung Galaxy S - all play 720p video, let's use that as the HD version. Full HD (1080p) is still a bit overkill, in my opinion.

For the lower quality version, it's best to stick to settings that older phones such as the iPhone 2G/3G, HTC Legend and Motorola Droid can play. For example, 270p will work fine. At this size, we can also have the video play without stutter over a 3G connection. Plus, even those rusty 5-year old laptops should be able to play the clip.

Here's a quick overview of the main encoding parameters for our video. For more details on the encoding side, check a previous blog post about supporting mobile video on your site.

	HD version	SD version
Container format	MP4	MP4
Video format	H.264, Main profile	H.264, Baseline profile
Video dimensions	1280x720 pixels	480x270pixels
Video bitrate	about 2000kbps	about 500kbps
Audio format	AAC, Low Complexity	AAC, Low Complexity
Audio frequency	44.1 kHz, stereo	44.1 kHz, stereo
Audio bitrate	96 kbps	64 kbps

Embedding

With the two versions of our video encoded, let's move on to embedding. In addition to the two MP4 files, you must also upload jwplayer.min.js and player.swf (available on the JW Player download page), as well as a nice still image (JPG) from your video. Note: we recommended the JPG as the video image - just for good looks. Next, include the player in the <head> of your HTML page:

<script type="text/javascript" src="http://example.com/jwplayer/jwplayer.min.js"></script>

With the player included, move on to place the actual embed code:

<div id="container">HD video coming up!</div>

<script>
var options = {
    file: "/assets/video-270p.mp4",
    height: 270,
    modes: [
        { type: "html5" },
        { type: "flash", "src:/jwplayer/player.swf" }
    ],
    plugins: {
        hd: { file: "/assets/video-720p.mp4" }
    },
    width: 480
};
jwplayer("container").setup(options);
</script>

With this setup, the player is setup into the <div> when the page loads. The 270p video is loaded into the player by default. The HD plugin is used to offer a toggle to the 720p video. This toggle is:

Displayed as a button in the top-right of the video on desktop browsers. Viewers can click the button to enable and disable the HD version.
Displayed as two big buttons in the middle of the video on Android and iOS. On their small touch screens, viewers can easily see and click these buttons.

WebM Support

Note the modes block in the above embed code define which playback mode is used first: Flash or HTML5. In this case, HTML5 is used first, because it enables the video to resume after doing an HD toggle. When clicking the HD toggle in Flash, the video will re-play from the beginning.

Unfortunately, not all HTML5 browsers (Firefox / Chrome ^† ) support the MP4 files we use. The player will therefore fallback to Flash. In order to profit from HTML5 playback in these browsers too, you should do two additional WebM encodes of your original video. You can use the same dimensions and bitrates as for an MP4.

On the embedding side, we add one small check. In between defining the options and setting up the player, we sniff if the browser is able to play WebM video. If so, we swap out the MP4 files for WebM ones:

...
    width: 480
};
if(!!document.createElement('video').canPlayType('video/webm')) {
    options.file = '/assets/video-270p.webm';
    options.plugins.hd.file = '/assets/video-720p.webm';
}
jwplayer("container").setup(options);
</script>

Now you're all set! Glorious HD video in HTML5 mode, on every browser and device that matters. Check out the live example:

example

† Though Chrome announced they would drop MP4 support last year, it is still working in the current version (Chrome 14).

Optimize Your Video for Mobile Playback

JeroenW — Fri, 12 Aug 2011 14:24:53 +0000

With the Android and iOS platforms growing like weeds, online publishers are scrambling to mobilize their video players and profit from these additional viewers. Since Apple’s iOS doesn't run Flash, most of these publishers turn to the HTML5 <video> tag for delivering their clips to mobile devices.

While this is a critical first step (better to have your videos play than not), it is also just the start. The mobile user experience (UX) model is vastly different from that of the desktop computer, which means additional work is needed in areas such as interface, streaming and advertising. These UX differences have several implications for video players.

Touch Versus Mouse

The most obvious difference is user input. A mouse controls video players on the desktop, whereas both iOS and Android rely on capacitive screens which users touch with their fingers. Since a fingertip is both bigger and harder to position than a mouse cursor, buttons on mobile video players must be larger than their desktop equivalents.

When using a mouse, there is the so-called "mouse-over" state: the mouse is positioned over a button, but not clicked. Some video players rely on this state to pop up a volume slider or selection menu. This state is not available on touch devices, so mobile players can not rely on it.

On the other hand, touch devices do allow users to control applications by sliding one or more fingers across the screen. This type of interaction (found in features like gestures and multi-touch) is relatively new and still unexplored, but could become widely used over time. Some basic gestures, like sliding over a webpage or playlist to scroll, are already widely accepted and can be used today.

Full-screen Versus Windowed

Another key differentiation is screen size. Mobile screens are 3 or 4 inches in diameter, which is a big difference from 14-inch laptops or 20-inch desktop monitors. Therefore, on both Android and iPhone, videos are always played back in full-screen, instead of inside an HTML page. This means that visual interaction with other parts of the page - including companion ads that pop up - is lost on mobile devices. Publishers should not rely on this advertising model.

In this full-screen mode, both Android and iOS expose only system-provided video controls (pause, seeking). Important online video components such as share buttons and overlay ads are simply not possible. Therefore, any custom controls or graphics are best displayed before the video is started and/or after it has ended.

On-The-Go Versus At-The-Desk

Mobile devices are indeed frequently used on-the-go, meaning their internet connection may be poor and unreliable. The connection speed can change dramatically, even within a single video playback session if a user switches from 3G to WiFi. Therefore, iOS devices support a specific type of video streaming that continuously adapts the video quality to the available bandwidth connection: HTTP Live Streaming. It is highly recommended to use this functionality for mobile video playback.

Unfortunately, Android only supports this type of streaming as of version 3.0. To ensure optimal video quality, players can offer an up-front video quality selection. As Android manufacturers migrate from the 2.x to the 3.x platform, HTTP Live Streaming can, and should, replace this manual quality selector.

One nice additional touch is a "watch later" feature in mobile players. Users who are casually browsing while waiting somewhere can tag a video and forget about it. The publisher can then remind the user about the video at a later point. Publishers can implement “watch later” functionality using cookies, log-ins or one of the emerging services dedicated to this functionality.

Conclusion

In sum, the vast differences between desktops/laptops and mobile devices require a major redesign of existing video players. But things don't stop at the player. The surrounding website needs optimization as well, with less content, less sidebars, less clutter and more focus on the video itself.

Mobilizing your video is not about swapping Flash for HTML5. It is about adapting your content to the device and facilitating a different type of user experience. Mobile video consumption is exploding, but it’s also still evolving, as are the platforms that serve this content to consumers. By going above and beyond the bare minimum now, you’ll be well positioned as mobile continues to explode.

As developers of one of the most widely used online video players, we constantly strive to provide optimal playback experience for our users. As we move towards the future generations of the JW Player, stay tuned for more and more exciting UI and UX improvements.

Introducing: Bits on the Run Free

LongTail Video Support — Wed, 20 Jul 2011 12:44:27 +0000

We're excited today to announce the introduction of Bits on the Run Free, a new type of Bits on the Run account which provides a zero cost way for publishers to get started with video. Instead of our previous 30-day Trial Membership, customers can now sign up for Bits on the Run and keep a Free Account... forever.

Bits on the Run Free

Our new Bits on the Run Free Account is recommended for bloggers, individuals and sites just getting started with video. Bits on the Run Free allows users to store and stream their videos at no cost, with full access to the Bits on the Run dashboard - including its player customization options, transcoding system, JW Player plugin support, API and rich video analytics.

What's in a Free Account?

1 GB of Platform Usage - allowing users to manage a roughly 1 hour video library free of charge.
5 GB of Video Delivery Per Month - which supports about 20 hours of video streaming per month.

Interested? Give it a try! Sign up for Bits on the Run Free.

Bits on the Run Pro

If you're looking for more than what Bits on the Run Free offers, we recommend you upgrade to Bits on the Run Pro. A Pro Account removes monthly limits and follows our unique Pay-As-You-Go Pricing, meaning you only pay for what you use. Included in a Pro Account is premium support, priority transcoding, an extensive reseller program and more!

We generally recommend a Bits on the Run Pro Account for medium to large sites with an online video presence. Read more about the new Bits on the Run pricing plans, and decide which account is best for you. If you're unsure of what account best suits your needs, contact us more information.

Ready to Get Started?

Sign-up for your Free or Pro Account today, upload and publish video to your site with ease and get your video workflow rolling! To learn more about Bits on the Run Free, read the official press release here.

Our Tips for Shooting Web Friendly Video that Compresses Well

remco — Mon, 11 Jul 2011 15:30:37 +0000

When it comes to bringing an attractive video experience to your website, the real star is of course the video itself. If your videos look attractive, viewers will be more engaged, and less likely to navigate away. Not only do quality videos look better, they will also compress better, which helps with two important factors - you save on video delivery costs, and smaller files mean your viewers need less bandwidth to watch the videos smoothly.

Here are a few tricks for making your videos look and sound as good as possible. Web friendly video should be easy to compress, and continue to look good even after it has been encoded to a low bitrate.

A general rule of thumb is that you should always make sure to start with a video in its original format and in the highest quality possible. Video compression is lossy, which means it will always degrade the image quality of your video (see image below).

The Right Equipment

By bringing the right equipment to the job, you can do a lot to improve your video quality.

Tripods - Make sure your image is stable. Use a tripod whenever possible and only use handheld shots as a deliberate choice (e.g. to give your video more of a in-the-moment feel), or when you have no other choice.
External Microphones - The cheapest way to improve audio quality with your video is by using an external microphone. Built in microphones generally don't perform well. Audio quality improves as the microphone is closer to the audio source. Almost all cameras have a microphone input, so with a simple handheld microphone you can improve your audio quality.
Lighting - If there isn't enough light, you will get a lot of noise in your picture (see image below). Noise doesn't look good and won't compress well. There are a couple of things that you can do to make sure that there is enough light:

Shoot in locations where there is a lot of natural light, preferably during the day time.
Bring your own light. Note that you don't need to break the bank with an expensive studio lamp. You can start out with just a couple of cheap halogen floodlights and work your way up to more professional equipment over time.
If your camera and/or lens support it, use a higher aperture (lower f-stop) in low-light situations, so more light will reach the sensor. This option is generally only available for higher-end video cameras, although newer consumer-end digital SLRs are now capable of shooting high-definition video.

Planning Your Shots

When choosing your shot there is also a lot you can do to make sure that your video compresses well.

Reduce Background Movement - Make sure there isn't a lot of movement in the background; use a static scene. While a background of an ocean or blowing trees in the wind can give your video a nice touch of nature, it means that the video encoder will spend time and bandwidth properly encoding your dynamic background instead of focusing on the main subject.
Reduce Horizontal Movement - Panning shots are difficult to compress because new information is continually entering the shot. Flash in particular is inefficient when it comes to decoding panning shots when they are encoded in H.264. Zooming, on the other hand, is much easier to encode.

A cool setting found in most high end cameras is filming with a shallow depth of field. This means that closer objects in focus stay in focus and anything outside, behind or around the shot will blur faster. This is beneficial since blurry parts of an image don't have sharp edges and compress far more efficiently. In addition to it being a nice effect, a shallow depth of field improves the image quality.

Last, if possible, configure your camera to shoot video in progressive mode. It might save you a lot of headaches during editing or encoding. If video is interlaced, chances are your end result will have interlace artifacts like in the image to the right below.

Conclusion

All in all you get the best results by making the original picture as clean as possible, and removing any unwanted movement. Using a separate microphone will help your audio quality a lot. These are just a couple of simple pointers to get you started, if you have any other tips, feel free to leave a comment!

JW Player 5.7: All about HTML5 Playlists

PabloS — Thu, 23 Jun 2011 16:15:13 +0000

This release of the JW Player 5.7 focuses heavily on lifting HTML5 support closer to parity with Flash. The most glaring gap had been the lack of support for XML playlists and for a visual playlist UI component. We're happy to announce that those features are now available. Read more to find out what's new.

RSS Playlists in HTML5

The title says it all. You can now load RSS and mRSS (RSS with "media" extensions) directly into a player running in HTML5 mode. Please note, JavaScript applications must comply with browsers' Same-Origin policy, although there are a couple of workarounds.

Visual HTML5 Playlist Component

You can now scroll through your playlist with a visual component in HTML5 mode. This much-requested feature comes with full skinning support and works in desktop browsers as well as in iOS. Here it is in action:

This example even works on iOS!

Improved Plugin Control Over UI Elements

Calling all plugin developers: plugins can now keep track of when UI elements appear and disappear. This enables interactive plugins (e.g., sharing or advertising) can position themselves properly depending on whether or not the player's built-in controls are visible.

Stability and Performance Enhancements

This release contains 38 bug fixes and player enhancements, making the player more stable than ever before. See the release notes for more details.

Download the JW Player 5.7

You can download the JW Player 5.7 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.

Using a Web Proxy to Test and Debug the JW Player or: Why Charles is our Best Friend

Zach — Thu, 12 May 2011 15:42:07 +0000

One of the tools that we've come to rely on quite heavily over the past several years is a web proxy. Frequently, we see support requests come in where a publisher has misconfigured the player by pointing it at a video file or skin which does not exist on their server. Using a web proxy, it's possible to log all requests, making it quite easy to see when requests are failing because the file they're trying to load isn't there. Additionally, since some web proxies allow you to modify requests, publishers can test out new player versions, plugins, or skins without modifying any code on their live site. In this blog post, we'll show you how to use a web proxy called Charles to help you debug your current JW Player configuration and test out new configurations.

How a Web Proxy Works

When you're running a web proxy, it acts as a middleman between your web browser and the website you're trying to access. Normally, your web browser makes requests directly to a website. When a web proxy is running, it acts an intermediary for all of your traffic, receiving all requests and then dispatching to the website as needed. This means that it's able to log requests, modify them, or allow them to pass through normally - and all of this occurs transparently to your web browser.

Setting up a Web Proxy

Getting and setting up a basic web proxy is easy! Browsers like Chrome, Safari, and Opera have developer tools with a basic proxy built in. For Firefox, there's the popular Firebug extension. These allow you to monitor outbound requests and see what your server is returning for each request.

Around the office though, we use Charles Proxy. Rather than simply logging requests, it allows you to modify them as well - pointing one network location to another, or pointing network files to files on disk. Additionally, because Charles exposes its proxy to the general network, it's possible to use a desktop running Charles as a web proxy for devices like the iPhone, iPad, and Android handsets.

A Few Examples

There are a few common cases where a web proxy is exceptionally useful. These examples only scratch the surface of the power of a web proxy, but they should get you well on your way.

Inspecting Your Web Browser Traffic

The most widely used feature of a web proxy is it's ability to monitor web traffic and it's the basis for all of the other examples that we'll talk about in this post. Once you've successfully installed Charles, go ahead and launch the application. You'll see a screen that looks like this:

Once the application has finished loading, open up your web browser and navigate to a page where you'd like to monitor the web traffic, like so:

As your web page loads, you'll see the request log growing in Charles. Clicking on any individual entry will give you detailed information on the file loading including HTTP response code, size, and time to load:

Validating Your File Paths

The example below shows a standard player configuration using a player with a video, thumbnail, and skin. After opening the web page containing this player in our web browser, we found that the thumbnail image wasn't appearing. Next, we launched Charles, cleared our web browser's cache, and reloaded the page in our web browser. It turns out that the file location we used for the thumbnail doesn't exist! To indicate that the file is missing, Charles placed a red circle with a question mark next to the filename and listed "404 Not Found" in the response code field, as demonstrated in the highlighted entry below:

You'll want to be sure to check the entire request log for 404s - it's pretty common for things like crossdomain policy files to be missing as well.

Confirming that the GAPro Plugins is Tracking Correctly

When you first start using the GAPro plugin, the process of testing your configuration and waiting for new data to appear is quite time consuming, as it may take up to 24 hours for Google to process the new event data. Rather than wait, simply boot up Charles, navigate your web browser to a page containing a JW Player configured to use the GA Pro plugin, and look for a call to Google Analytics in Charles, like so:

Testing Your Site with a New Player Version

We always recommend testing out our new player versions with your site's configuration before upgrading. Charles provides a powerful tool, called Map Remote which will help you accomplish this without any special testing pages for your site. First, upload the new player.swf and player.js files to your site, but don't overwrite your existing player. Next, open Charles and point your web browser to a page that currently contains a JW Player, and that you'd like to test with your new JW Player. Look through the requests in Charles to find your player in the list of requests and right click it. You'll see a menu like this:

Select "Map Remote". A dialog box will open. The original address will automatically be populated in the top section, labeled "Map From". Now, enter the address for the player you're trying to test in the box labeled "Map To", like so:

Finally, if you clear your web browser cache and reload the page in your web browser, you'll only see a request to the new file, with a note indicating "Mapped from remote URL: ".

Assuming your configuration worked, you can go ahead and replace your original player.swf and jwplayer.js with the new player or update your site configuration to use the new player. Be sure to close Charles when you're done testing, otherwise you might continue to map to a file that doesn't exist!

Note - In addition to testing out a new player, you might also want to test out an entirely new player configuration. Rather than using "Map Remote" as you would when testing a new player, you'll want to use "Map Local", which allows you to point to a file on your file system. Thus, to test out a new configuration, simply download a copy of the page you'd like to test onto your desktop, make the changes to your embed code locally, and then point the remote address with that file to the version on your desktop. Everything will remain the same on your live site, but you'll be able to test your new configuration locally with all of the images, scripts, and advertising loading as they would for your viewers.

Configuring iOS to Use Charles

You can also configure your iPhone and iPad to use Charles for testing. First and foremost, it's important to make sure that your iOS device and your computer are using the same network (wifi or wired) - none of this will work otherwise. Once you've verified this, go ahead and fire up Charles. After Charles has finished starting up, you'll need to figure out your computer's network IP address (instructions are readily available for Windows and Mac). In this example, the IP address of the computer is 192.168.0.116. Next, open up the network configuration on your iOS device and set the HTTP Proxy to your IP address on port 8888, as demonstrated in the highlighted box below:

The next time you open up Safari on your device and navigate to a page, Charles will prompt you with the following message:

Simply click "Allow", and all of your iOS device requests will be logged and routed through Charles just like your normal browser requests.

Limitations of Web Proxies

Web proxies work great for many player configurations, but they have certain limitations as well. For example, Adobe's RTMP streaming protocol uses a lower level network connection, thus bypassing most proxies. If you're using RTMP, you can still use a proxy to confirm that your thumbnails, plugins, and skins are properly configured, but there's no way to ensure you've pointed to the correct video assets.

Hopefully you've now got a good grasp on what a web proxy is conceptually and how it can help you setup, configure, and troubleshoot your JW Player. As you use web proxies more, you'll continue to find new and amazing possibilities. Please be sure to share your discoveries in the comments!

Adding Video to Your WordPress Blog

Cameron — Fri, 06 May 2011 13:57:46 +0000

The amount of video content on the Internet has exploded over the last few years. This is due in large part to products like the JW Player and services like YouTube and Vimeo. More and more users have come to expect the sites they visit to contain video content. As a result many bloggers are seeing the value in having video content on their site. Not only does it make their site more engaging for their users, it can also be a source of revenue for them through the use of video advertising.

If you are a WordPress user you do not have to be left out. It is extremely easy for you to include video on your site and even monetize it with some advertising. In this post we'll be looking at how to post video on your WordPress blog using the JW Player and the JW Player Plugin for WordPress.

WordPress as a Video Platform

WordPress currently powers the vast majority of blogs on the Internet and for good reason. It's lightweight, easy to use and very flexible. It is this flexibility that makes it excellent as a tool for managing video content.

WordPress has a built in media manager allowing you to easily upload your video content and manage video meta data. In addition, WordPress treats your videos like any other page or post so it's very easy to tag and categorize them. When writing a new post, your library is easily accessible via a convenient overlay.

Unfortunately, out of the box, WordPress has a severe limitation when it comes to video. Unless you know how to write embed code, WordPress doesn't actually handle embedding video content in your posts. Instead of rendering a video player it simply inserts a link to the video file. This is far from the engaging experience most people are looking for and is where the JW Player Plugin for WordPress comes in.

What Does the WordPress Plugin Offer?

In a nutshell, the WordPress plugin allows you to use the JW Player to present your video content to users. It allows you to take advantage of the JW Player's major features including HTML5 support, skins, plugins and the AdSolution without writing a single line of code. It also substantially expands WordPress' built in Media Manager. Some highlights include the following:

Player embedding and management: Customize multiple JW Player's all within your WordPress site and embed them without writing any code.
Playlist management: Create and manage playlists using the videos already in your library.
Plugins: Take advantage of the JW Player's many plugins including social plugins like Tweet It and Facebook It or playlist plugins like Flow.
Advertising: Run the LongTail Video AdSolution to monetize your content. It's a great way to pay for your hosting costs and to make some extra money.

For additional information about these features please refer to our JW Player Plugin for WordPress documentation.

WordPress Video Examples

Now that we've gone over some of the highlights we'll go through some examples of the plugin in action. Here are the most common ways in which bloggers use the WordPress plugin. Keep in mind that all of these examples were done using just the features of the JW Player Plugin for WordPress. You don't need to write any code to reproduce them on your own site.

A Post With a Single Video

Here you see a JW Player with a single video directly in the body of a WordPress post.

A Post With a Playlist

Much like a single video, a playlist appears directly in the post body. Note the additional controls for users to select each video in the playlist.

A Post with Sharing

Here we've posted a JW Player with a single video. This player is using the Facebook It and Tweet It plugin. Users can click the appropriate icon and share the post on Facebook or Twitter.

Conclusion

Getting started with the JW Player Plugin is easy. It's accessible via your WordPress dashboard just like any other plugin. Search for "JW Player." and it will be the first result. Or if you would like to download it directly you can visit the WordPress Plugin Directory.

For additional information about the JW Player Plugin for WordPress you can refer to the following documents:

JW Player 5.6 Adds Support for Audio Files in HTML5, plus YouTube HD

PabloS — Thu, 28 Apr 2011 21:16:36 +0000

While the JW Player version 5.5 release added some exciting new developer capabilities, JW Player 5.6 focuses on bringing publishers a few useful features.

Support for Audio Files in HTML5

Ever since the JW Player introduced support for HTML5 mode back in JW 5.3, we've had a lot of feedback requesting that audio files be playable in HTML5 mode as well. With 5.6, you can now play your MP3, AAC or Ogg Vorbis audio files in HTML5 mode. Just remember that the player relies on each browser's support for any particular media format.

Better YouTube Integration, Including YouTube HD

The player has upgraded its internal integration with YouTube to their latest "chromeless" player. This impacts JW Player users in a couple of ways:

YouTube HD support — One of the first things you'll notice is that YouTube videos will automatically switch to the HD version if it's available (and if the player window is large enough to accommodate it). If your player window is smaller than the HD version, don't worry - the player will automatically switch to HD in fullscreen mode.
No more yt.swf — Previous versions of the JW Player included a little helper file, yt.swf. This file is no longer needed; as of JW5.6, the player's YouTube integration is now internal.
Ad-supported content — As we pointed out in a recent blog post, YouTube has begun blocking certain content that they or their partners consider monetizable. JW 5.6 includes support for ads placed by YouTube over this content, allowing it to be embedded on your site.

This release also consists of some additional enhancements:

Better tabbing support for browsers and screen readers
Ability for plugins and JavaScript to show / hide the dock and controlbar
Ability to pass complete JavaScript (JSON) objects into the player via the JW Embedder
New onSeek event in the JavaScript API

For a detailed list of tickets, please see this list.

You can download the JW Player 5.6 for Flash and HTML5 here. As always, feel free to post your feedback in the comments section directly below.

What is Video Streaming?

JeroenW — Wed, 27 Apr 2011 06:34:17 +0000

With all of the buzz around HTML5 and the iPad, there's been a lot of talk about the technologies underlying digital video. Besides the inevitable codecs (H264 & VP8), experts are discussing video delivery mechanisms, using indecipherable acronyms like RTMP, CDN and HLS. This blog post will give an overview of the various video streaming methods in plain English and bring the all-round developer and publisher up to date.

In a nutshell, there are three widely used ways to stream a video: Progressive Download, RTMP/RTSP Streaming, and Adaptive HTTP Streaming. We'll look at the three in detail here, describing their pros, cons, and various technologies that support each.

Note: more streaming methods (like MultiCast or Peer 2 Peer) exist, but are of little use to the regular publisher. They are not widely adopted and/or only useful in specific situations.

Progressive Download

Progressive Download is the most widely used video delivery method by far (in part because it's what YouTube uses). It's also easiest to implement: just put a video on your webserver and point your player to the URL. Once a user hits play, the player immediately starts downloading the file. The player will start video playback as soon as it has enough data to do so, but it will continue to download until it has received the whole file (hence the progressive).

Progressive Download is supported by Flash, HTML5 browsers, the iPad/iPhone and Android. On the server side, every regular webhoster supports downloads, as does every CDN (Content Delivery Network; webhosters that special in large-scale delivery). In most cases (Flash needs a small server module), it is possible to seek in a player to a not-yet-downloaded part of the video. At that point, the player re-downloads the video, starting at the seek offset instead of at the beginning. We call that feature pseudo-streaming.

The simplicity of Progressive Download also has its downsides. For one, bandwidth is wasted on data downloaded but not watched. Consider a user watching a ten minute video. They may leave the page after having watched only one minute of the video, but at that point the other nine minutes have already been downloaded. This means that the publisher has paid to transfer nine times as much data as the user actually watched - an expensive proposition on a large scale.

Another downside is the inability to change the quality of the video mid-stream: once the download starts, the video quality is locked. After switching a player to fullscreen, you generally see a blurry video, because it was intended to be watched at a much smaller size. Or, when you watch video on an iPad, your connection may switch from WiFi to 3G. Playback then stutters, because the download speeds are much lower on 3G.

In sum, Progressive Download works fine for short clips (a few minutes). For longer videos, the downsides start to impact playback too much. Plus, live streaming is not possible, as there's no downloadable file.

RTSP/RTMP Streaming

Because of the downsides of Progressive Download, RTMP/RTSP Streaming is widely used by professional media organizations like Hulu. This method uses specialized webservers that only deliver the frames of a video the user is currently watching. No data is downloaded in advance and data a user has seen is immediately discarded.

The most widely solution is used is RTMP (Real Time Messaging Protocol), the streaming protocol of Flash. It is supported by servers such as FMS and Wowza and most CDNs (but not by regular webhosters). HTML5 does not include a dedicated streaming protocol, nor does the iPad/iPhone. Android has support, for RTSP (Real Time Streaming Protocol). Unfortunately, RTSP is not widely supported by servers and CDNs.

This lack of support, especially on the server side, is the biggest drawback of RTMP/RTSP Streaming. Most publishers do not want to maintain expensive, dedicated servers to stream their videos. Additionally, the dedicated protocols (RTMP and RTSP) are often blocked by corporate firewalls.

On the plus side, RTMP streaming can change video quality mid-stream. This allows for optimal playback quality in the fullscreen and WiFi/3G scenarios described above. However, if the connection speed drops below the minimum bandwidth needed for the video, playback will be continuously interrupted. Unlike progressive download, users cannot pause a video and wait for enough data to download to ensure smooth playback.

In sum, RTMP/RTSP Streaming works great even for long-form or live video. It has specific server and protocol requirements, which makes it less accessible and adds significant complexity and cost as compared to Progressive Download.

Adaptive HTTP Streaming

Adaptive HTTP Streaming is a fairly new streaming format. It attempts to join the merits of RTMP/RTSP Streaming (bandwidth efficiency, quality switching) with those of Progressive Download (no special servers or protocol needed). Adaptive HTTP Streaming works by storing your videos on the server in small fragments (a few seconds each). The player then glues these fragments together into a continuous stream.

At present, Adaptive HTTP Streaming is supported by both Flash and the iPad/iPhone. Android supports it as of version 3 and support in HTML5 is currently under development. Since Adaptive HTTP Streaming leverages standard webservers, it is supported by webhosters and CDNs alike.

Although Adaptive HTTP Streaming eliminates many of the downsides of RTMP/RTSP Streaming and Progressive Download, it still has issues of its own, the biggest being the lack of standardization. Because it is a new technology, there is no single, widely used implementation. The most popular is currently Apple's HLS (HTTP Live Streaming), which is supported by the iPad/iPhone and Android 3.0. However, both Adobe and Microsoft have competing offerings (Zeri & Smooth) and the MPEG consortium is working on a standard named DASH.

It's also worth noting that none of the Adaptive HTTP Streaming implementations work with regular MP4 files. They all require your files to be converted from a regular MP4 into a specific fragmented format. Apple, Microsoft and Adobe each supply a tool for this, but support for these formats doesn't exist in regular video editors and transcoding tools (yet).

In summary, while Adaptive HTTP Streaming will likely become the single video streaming method over time, the technology is still fragmented (no pun intended) and ecosystem support is only beginning to arrive.

Summary: Streaming Support

This table sums up support for the various streaming methods across devices and servers.

Devices	Progressive Download	RTMP/RTSP Streaming	Adaptive HTTP Streaming
Adobe Flash Player	MP4, FLV	RTMP	HLS, Zeri, Smooth
HTML5 (Safari & IE9)	MP4	-	-
HTML5 (Firefox & Chrome)	WebM	-	-
iOS (iPad/iPhone)	MP4	-	HLS
Android Devices	MP4, WebM	RTSP	HLS (as of 3.0)
CDNs (e.g. CloudFront)	MP4, FLV, WebM	RTMP	HLS
Web Servers (e.g. S3)	MP4, FLV, WebM	-	HLS

Publish Your Videos to Facebook with a JW Player

Zach — Wed, 13 Apr 2011 16:25:37 +0000

Over the past few months, you may have noticed that an increasing number of items in your Facebook News Feed had a play icon in the bottom left hand corner, like so:

This is because Facebook recently opened the News Feed to third parties, allowing individuals to watch videos from all over the Internet without ever leaving Facebook. While getting this to work requires making some minor modifications to your website, publishers have been quick to implement the changes because of the number of video views Facebook can help drive (especially when a video goes viral).

In this blog post, we'll describe how publishers can use the JW Player with the Facebook News Feed and enable viewers to have the same experience regardless of where they're watching it.

What You'll Need

A video, audio file, or any other piece of content that is playable by the JW Player
A copy of the JW Player SWF, hosted on your web server
A web page for your content
This document (pretty meta, huh?)

Getting all of this to work is pretty simple, but it can be difficult to manage if you've got a large library of content. Additionally, Facebook does not store a copy of the content or player, so they will be loaded from your server every time they are watched on Facebook. If you're worried about management or your ability to handle the load when your video goes viral, it's worth taking a look at services like LongTail.tv and Bits on the Run, both of which support this type of Facebook integration natively.

Updating Your Site

Whenever someone publishes a post with a link to their News Feed, Facebook scans that page for metadata about that page. By including some specific metadata in the <head> of your page, you can instruct Facebook to embed your JW Player with your content in the News Feed. However, this also means that you'll need a unique web page with this metadata for each piece of content, which can become quite difficult to manage if you're not using a CMS like Wordpress or Drupal.

When scanning a page, Facebook examines the <meta> tags. Specifically, it looks at Open Graph tags - those with with an og prefix to the property attribute - and uses the data contained in the content attribute.

An Example

<html>
  <head>
    <meta property="og:type" content="movie" /> 
    <meta property="og:video:height" content="260" /> 
    <meta property="og:video:width" content="420" /> 
    <meta property="og:video:type" content="application/x-shockwave-flash" />
    <meta property="og:title" content="Big Buck Bunny" /> 
    <meta property="og:description" content="Big Buck Bunny is a short animated film by the Blender Institute, part of the Blender Foundation." />
    <meta property="og:image" content="http://www.example.com/bunny.png" />
    <meta property="og:video" content="http://www.example.com/jwplayer/player.swf?file=http%3A%2F%2Fwww.example.com%2Fbunny.flv&autostart=true" /> 
  </head>
  <body>
    …
  </body>
</html>

So what do each of these tags mean?

og:type - The type of content described by this page, should always be "movie".
og:video:height / og:video:width - the height and width (in pixels) of your video player will occupy within the news feed.
og:video:type - The type of video playback you'd like to use, should always be "application/x-shockwave-flash".
og:title / og:description - the title and description of your video. Note that the title attribute is different from the HTML <title> tag, and it will not show up in the browser's title bar.
og:image - the poster image. This is what will be displayed on the viewer's wall with the play button over it.
og:video - the URL to your JW Player, with the configuration passed in as part of the URL string.

Constructing the Video String

Coming up with a usable og:video tag is a bit of a challenge. Since many of our plugins require similar configuration, we've got some documentation that should come in handy. However, you can also follow these steps to build the string:

Start with the absolute path to your JW Player (ie, "http://www.example.com/jwplayer/player.swf").
Next, add a "?". Everything after this will be interpreted as player configuration, and ensures that your web server will serve up your video player.
For each configuration option you'd like to specify, add the name of the configuration option, then a "=", and finally the URL-encoded version of the value you wish to specify (ie "file=http%3A%2F%2Fwww.example.com%2Fbunny.flv&autostart=true"). Be sure to separate each configuration option with a "&".

As always, you'll need to make sure that you're using absolute paths to reference your content and skins. Also, you'll need to make sure that you have the proper cross-domain security restrictions in place.

Posting to Facebook

Thanks to all of your hard work, posting into Facebook is a snap! Simply drop your into the share box, like so:

You'll notice that there's no play button in the preview image. Once you hit the share button, the play button will be added and your content will be posted for the whole world to view and enjoy within their News Feed!

Security Limitations (HTTPS)

Recently, Facebook has received some bad press because the site's login is not encrypted, making it easy for someone using the same WiFi as you to take over your Facebook account. To get around this, Facebook began offering the option to use a secure version of the site (HTTPS). When using this version of the site, Facebook does not always allow you to view content within the News Feed and may link you off to the original source of the content to view it. This is because most sites do not serve up their content via HTTPS, and loading standard HTTP content in an HTTPS site will result in an aggravating mixed content warning in all browsers.

JW Player 5.5 for Flash and HTML5 Introduces JavaScript Plugins

Zach — Mon, 14 Mar 2011 11:37:26 +0000

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.

Supporting Mobile Video on Your Site

JeroenW — Wed, 02 Mar 2011 14:50:34 +0000

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:

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)

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.

What is Flash Stage Video, and How Does It Affect Me?

PabloS — Tue, 22 Feb 2011 18:50:01 +0000

Last week, Adobe released a new version of Flash - 10.2, containing a new hardware acceleration mode for H.264, called Stage Video.

Common Questions:

Doesn't Flash already support hardware acceleration for H.264?

In general, the answer to this question is "yes," if you're using Flash version 10.1. Your mileage may vary, depending on system hardware capabilities and Flash's support for various hardware. Here's how standard Flash hardware acceleration works:

Video content is downloaded or streamed from content server.
Flash passes the video bytes directly to the hardware H.264 decoder, if available.
The decoder sends back the raw decoded video to Flash
Flash composites the video with all of the other non-video visual elements (in the JW Player's case, this includes the controlbar, playlist, plugins, etc.). This happens for each frame of the video, assuming there are no skipped frames.
The Flash plugin places the composited image into the web browser.

This method is vastly more efficient than the non-hardware-accelerated alternative, where Flash performs the H.264 decoding in software.

If Flash already has hardware acceleration, why do we need a new method?

In general, enabling hardware acceleration for H.264 decreases the load on the CPU. However, because Flash is still rendering video once per frame and compositing all of the Flash graphics with the video, there is still significant overhead involved. This manifests itself more clearly with larger videos (1080p and above) and slower CPUs.

Adobe's solution is to remove the video from Flash's rendering pipeline entirely. Enter Stage Video.

Here's how it works:

Video content is downloaded or streamed from content server.
Flash passes the video bytes directly to the hardware H.264 decoder.
Flash instructs the decoder to render the video directly to the screen.
Flash renders all of the non-video elements and places them on top of the rendered video.

Because Flash no longer has to make any calculations to render the video, this takes even more load off of the CPU.

Are there any limitations to Stage Video?

Yes, there are a couple of limitations, and for some applications, they can be a deal-breaker. Luckily, for most web video player applications, such as the JW Player, these limitations aren't as big of a deal:

Since Flash is no longer involved in the video rendering pipeline, features such as visual effects, translations and transformations are not available in Stage Video mode.
The "wmode" (window mode) Flash parameter must be set to "direct" in most browsers. This means that the Flash plugin can't be placed above or below any HTML entities on a web page. Stage Video is available in full-screen mode regardless of what "wmode" you use.

When will the JW Player support Stage Video?

We haven't nailed down a timeline for Stage Video support, but it's on the short list of future player improvements. We've already created a player with experimental support for Stage Video. You can download it here, and enable Stage Video acceleration by setting the provider option to stage. For now, only standard progressive download mode is supported (no HTTP or RTMP streaming).

To benchmark the new player, open up your Task Manager (on Windows) or Activity Monitor (on Mac OS X) and take a look at Flash's CPU utilization while watching an HD video. Try your video with provider set to stage, (Stage Video on), then switch provider to video to see how the player performs without Stage Video.

As always, we'd love to hear your feedback in the comments below.

W3C WebTV: Adaptive Streaming & Content Protection

JeroenW — Tue, 15 Feb 2011 15:36:41 +0000

Last week, the W3C held its Second Web & TV Workshop in Berlin. The workshop focused on the convergence of web technology and broadcasting. In other words, how will web and television work together to eventually merge?

Along with sessions on second-screen scenarios and accessibility, the workshops covered adaptive streaming and content protection. Both sessions were very compelling considering that streaming and protection are two important limitations of today's HTML5 video support.

Adaptive Streaming: DASH

Adaptive streaming is a technology that enables high-quality video streaming from any regular web server. Each adaptive stream is stored in multiple quality levels. Video players continuously request small fragments from these files (e.g. through range-requests) and seamlessly glue them together into one presentation. This technology is especially well suited for mobile (3G, 4G, WiFi) video delivery because video players can quickly adapt to changing bandwidth conditions by loading fragments from another quality level.

In the workshop's adaptive streaming session, the main focus was on MPEG DASH, a just-released specification from the Motion Pictures Experts Group. DASH aims to standardize streaming of video over HTTP, since today's solutions from Apple, Adobe and Microsoft are 95% the same but 100% incompatible.

In a nutshell, DASH specifies the format of the XML file that lists the available quality levels (the manifest). The spec provides guidance around encoding video for adaptive streaming (mostly for MP4) and around stitching the fragments together in a video player. See this paper and these slides from MPEG DASH co-author Thomas Stockhammer for more information.

Moving forward, two outstanding issues must be resolved in order to make DASH a widely used standard. First, DASH should be cleared of patent claims (if there are any), so it can be used in free software (e.g. for WebM). Second, specifications should be written for connecting DASH to HTML5, so adaptive streams can load in a video tag. For example, simply through the @src attribute.

Content Protection: PIFF

Content protection is another hot topic for online video. Currently, HTML5 video provides no content protection mechanisms, while closed systems like Flash and Silverlight do. Again, there is no standard for this, forcing companies like Netflix to encode their content multiple times for various DRM systems. And since DRM (by nature) is hard to specify in an open format, standardization seems far away.

There is progress though, in the form of PIFF (Protected Interoperable File Format). PIFF is based upon the MP4 file format and specifies what encryption should be used and how it should be applied. The beauty of this format is that it solely focuses on a common encryption mechanism, while leaving the rights management part untouched. This allows content owners to encrypt and store their videos once, even when using multiple DRM systems. See this paper by John Simmons for a more in-depth explanation.

The separation of encryption and rights management also opens the door for scenarios in which only encryption (no rights management) is used. Such scenarios should appeal to both publishers (for basic protection or privacy reasons) and open browsers like Firefox and Chrome. Next step in this area is the investigation of a common decryption workflow, in either HTML5 or DASH.

More News Soon

In summary, the Second Web & TV Workshop was exciting and productive, but there is still work ahead. Recognizing this, the W3C started a Web+TV Interest Group, which will continue work on such things as investigating the legal state of MPEG DASH. Stay tuned for more updates down the road...

Live Streaming Using Wowza EC2

JeroenW — Wed, 09 Feb 2011 16:00:00 +0000

Publishing a few on-demand videos can be cheap and simple: just upload the videos to your site and use a tool like the JW Player to embed them on your site. Historically, publishing a live stream has been challenging and a lot more expensive. Most publishers use dedicated upload and streaming software for live streams, which can cost hundreds or even thousands of dollars and often require high cost server hardware. However, there are some cheap alternatives. This blog post explores a combination of tools that will allow you to get a live stream up and running for just a buck!

Wowza Media Server for EC2

First the server. There are various streaming servers out there: some have a license fee (Flash Media Server, Wowza Media Server) and some are free (IIS Media Services, Flumotion). For each of them, you’ll need to buy, install and run a webserver. This is a lot of work and costs a lot of money.

Enter Amazon EC2. It's a service from Amazon that allows you to rent webservers by the hour (you also pay per GB transferred, but that’s just a few cents). The pre-built EC2 offerings include webservers that run Wowza Media Server 2.0. This means you can boot a webserver with Wowza, stream a live event, and terminate the webserver shortly afterwards. No monthly contracts, no server management.

Setting up a Wowza server takes about an hour the first time around, since you have to sign up for EC2 and 'Wowza for EC2' before you’re able to configure your server instance (which can be done using the ElasticFox Firefox plugin). When that's done, booting your server for a live event takes a few clicks. See the Getting Started section at the Wowza Media Server for EC2 page and make sure to follow all steps.

Note you won’t have to access the webserver itself. Instead, the default Wowza installation boots up ready to broadcast a live stream – you’ll just need to connect to it. Also, be sure that you open TCP port 80 (HTTP) and 1935 (RTMP) to any IP (0.0.0.0/0) when configuring the "security group" permissions. Finally, make sure you terminate a server after you’ve finished your live event - the meter keeps ticking regardless of whether or not you’re using the box.

Boot a server instance and wait until ElasticFox says it is "Running". You're now ready to start the stream!

Flash Media Live Encoder

On to the tools for uploading the live stream. There are the expensive tools (Inlet, Telestream), there are the hard to use tools (VLC, FFmpeg), and then there’s Flash Media Live Encoder from Adobe. It is free and fairly easy to use. It is intended for use with the Flash Media Server, but works equally fine with the Wowza Media Server. Download the tool (available for Windows & Mac) to get started.

Once inside the tool, you’ll need to select a video capture device. This can be a built-in webcam, but you can also use a professional camera connected to your computer using USB or Firewire. On Windows, you can even stream your desktop after installing the VH Screen Capture driver. We recommend using the following settings:

Use H.264 as your video codec. Something in the range of 400 kbps will look great for a professional (640x360) broadcast. Something in the range of 200 kbps will be fine for a webcam-style (320x180 pixels) broadcast.
Use AAC as your audio codec. If you have a "pro" audio input, use e.g. stereo audio at a samplerate of 48 kHz and a bitrate of 64 kbps. Otherwise, use mono, 22 kHz and 48 kbps.
The "FMS URL" should be the link to your Wowza EC2 instance. It will look something like this: "rtmp://ec2-79-125-37-3.eu-west-1.compute.amazonaws.com/live". The "rtmp://" lead and "/live" trail are always the same. If your server is running, you can press the "Connect" button right below to test the connection.
The "Stream" will be the name of your stream. Call it something like "mystream.mp4", including the .mp4 extension to circumvent a few quirks in both the server and the player.

Press the green "Start" button and your stream is up and running. You're now broadcasting!

JW Player

The last step is embedding a player on your site where viewers can watch your live event. The JW Player is an excellent (free for noncommercial use) option. Download the JW Player and upload the "jwplayer.js" and "player.swf" files to your website. You can now use the following code template to embed the live stream into your page:

JW Embedder

Make sure to update all the options in this code with your configuration. This includes:

The location of "jwplayer.js" and "player.swf" on your web server.
The "file" (same as the "Stream" in FMLE) and "streamer" (same as the "FMS URL" in FMLE).
The width, height and preview image (optional) that appears before a visitor clicks the play button.

Navigate to the web page where you’ve inserted the embed code and click on the player to watch the stream. You're now live!

Next Steps

This tutorial has given you some hands-on tips for setting up a live stream in an easy and affordable way. Let us know if you run into issues, and we high recommend following the above instructions (especially the server setup and configuration) to the T!

Once you have your server up and running, it’s pretty simple to start adding other features, including:

Simultaneously streaming to Flash and the iPad/iPhone using the Wowza Server + JW
Using JavaScript to display a countdown before an event starts and a "replay" button for after the event ends.
Streaming your broadcast through Cloudfront (Amazon's CDN offering), which allows you to broadcast a stream to a massive audience without worrying about scalability.

Also, feel free to post a comment below if you'd like to see any of these (or others) explored in a future blog post.

Browser Video Codec Support - Does it Matter?

JeroenW — Thu, 03 Feb 2011 15:27:34 +0000

The Google Chrome team recently announced it would drop support for the H.264 video codec. Dropping H264 is beneficial for Google in several ways: it may help Google's WebM format gain additional traction in the market and solidifies Google's stance as a supporter of open media formats in the WebM versus H264 debate, as most of Google's other properties (including YouTube) still support H264.

Shortly after the announcement, a truckload of blog posts popped up, explaining the impact this would have on the adoption of WebM over H264. A couple interesting reads:

In spite of all the comments about this announcement, most commentators seem to gloss over its practical irrelevance. There's a short, simple reason for this.

Flash

Suppose Internet Explorer 9 ships tomorrow and in the middle of the night, the IE team abandons H264 and ships the browser with WebM instead. Next, suppose every single Internet Explorer installation out there is instantly updated to v9, making WebM support widespread.

Nothing would change. Why? Because all video watched on the desktop is played through Flash, and Flash isn't going away any time soon.

Publishers currently cannot move from Flash to HTML5, because HTML5 lacks vital technologies like adaptive streaming (for long-form / live content), content protection (for premium content) and playback locking (for advertising). On top of that, today's entire online video ecosystem (ingestion, transcoding, advertising, analytics, viral sharing, etc.) is Flash based. Both obstacles will be overcome in time, but this will be a slow process of incremental technological advances.

To force a transition, some bloggers have suggested Chrome should entirely drop support for Flash. This definitely won't happen. Flash is absolutely vital to the web. In addition to video, there's applications like advertising (a $25B industry) and gaming (Farmville!) that fully depend on it. Any browser dropping Flash would instantly get dropped by both publishers and users in turn.

In summary, desktop browsers are stuck with Flash, and publishers will simply continue to use Flash. As the migration to HTML5 starts to happen, publishers will leverage Flash in browsers that do not support their video format of choice (be it H264 or WebM). Video platforms like Bits on the Run or Brightcove and video players like the JW Player facilitate such functionalities today.

As it pertains to WebM/H264, desktop browsers will not move the needle either way. But something else will.

Devices

Devices (phones, tablets, settops) do not have a history of supporting Flash and many will choose not to (as Apple has done for iOS). On devices where Flash is supported, CPU limitations will make it impossible to play video using software-based decoding. This means that even Flash will be limited by whatever video codecs the devices support in hardware. In other words: Flash cannot be used as a fallback for unsupported codecs as it is today for desktop browsers.

The choices device vendors (hardware + software) make will have the greatest impact the adoption of WebM. Publishers will be forced to choose between publishing their videos in whichever formats are natively supported on the most popular devices, or choose not to support certain platforms. While it's still possible to distribute your content without worrying too much about the discrepancy between the platforms, the incredible growth of the phone, tablet and settop market will soon take that option off of the table.

That said, the odds are against WebM for now. H264 is available on nearly any phone, tablet and settop out there and WebM isn't available on any device. Only after the launch of WebM hardware decoding can we expect to see announcements that can influence the uptake of WebM versus H264. Who will support WebM decoding? How good will it be (performance, streaming, protection) compared to H264? And who (besides Google) will dare dropping H264 decoding support?

Only after the various device vendors have picked their side (and users have picked their devices!), can we re-evaluate. Until then, announcements like the one made by the Chrome team will only have symbolic value.