Entries By jeroen wijering

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

by Jeroen Wijering on April 19, 2012

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.

Comments (3)   Tweet   Share

Encoding WebM Videos

by Jeroen Wijering on March 06, 2012

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.

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

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.

Comments (1)   Tweet   Share

Introducing The State of HTML5 Video Report

by Jeroen Wijering on January 26, 2012

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.

Comments (2)   Tweet   Share

The Future of Mobile Video is Apple, For Now

by Jeroen Wijering on December 12, 2011

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.

  Tweet   Share

HD Video Everywhere!

by Jeroen Wijering on August 24, 2011

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.

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

Comments (4)   Tweet   Share

Optimize Your Video for Mobile Playback

by Jeroen Wijering on August 12, 2011

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.

Comments (4)   Tweet   Share

What is Video Streaming?

by Jeroen Wijering on April 27, 2011

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.

Comments (19)   Tweet   Share

Supporting Mobile Video on Your Site

by Jeroen Wijering on March 02, 2011

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

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:

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

Resulting videoplayer that works on most devices.

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

Comments (63)   Tweet   Share

W3C WebTV: Adaptive Streaming & Content Protection

by Jeroen Wijering on February 15, 2011

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

Comments (7)   Tweet   Share

Live Streaming Using Wowza EC2

by Jeroen Wijering on February 09, 2011

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.

Comments (65)   Tweet   Share

Browser Video Codec Support - Does it Matter?

by Jeroen Wijering on February 03, 2011

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:

• MC Siegler, on TechCrunch
• Jan Ozer, on Streaming Media
• John Gruber, on Daring Fireball

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.

Comments (7)   Tweet   Share

Understanding Video Analytics

by Jeroen Wijering on September 27, 2010

Online video is slowing becoming ubiquitous - used more and more by publishers to promote their products and services to their customers. So how do you measure just how ubiquitous it has become? Our Answer: Video Analytics.

It is becoming increasingly important to analyze video performance. For example, retailers want to know if their video marketing efforts increase sales. Publishers want to know which type of videos (and accompanying advertisements) have the greatest return on investment. Foundations want to know if their video bulletins are successfully increasing awareness of their mission. Analytics are both intriguing and insightful across many industries.

Luckily, video is just another part of the online mix: embedded in HTML and delivered over HTTP. Thus, the vast array of tools for analyzing the performance of webpages can be used for videos as well. For example, with Google Analytics you can setup a goal that tracks just how many of your users both watched your video and then bought your product, i.e. analyzing its effectiveness.

Webpage-oriented tools like Google Analytics do provide insight into video performance, but due to the time-based nature of video, they lack the proper tools to delivery a deeper analysis. Video portals (e.g. Vimeo and YouTube), video platforms (e.g. Bits on the Run and Brightcove) and video analytic providers (e.g. Omniture and Visible Measures) have risen to fill this gap and offer solid tools focused on the specific time-based nature of video, providing you with reliable and insightful statistics for your videos.

When comparing these offerings, three valuable, video specific metrics are always included: video pageviews/video views, hours viewed, and video engagement.

Metric 1: Video Pageviews And Video Views

Consistent across most websites, users are required to click on a video to make it play. There are two important reasons for this practice. First, playing video is still expensive - both in terms of bandwidth, computing power and battery life. Second, and perhaps more important, automatically starting a video when a user loads a website is a less than desirable user experience.

Understanding exactly how many users click to play a video is important. It tells you how many people are interested in the video, or how many people are able to identify the video on your page. By keeping track of this metric, over time, you can use it to optimize the video's poster thumbnail and the placement of the videoplayer on the page, increasing the number of people that play the video.

A video pageview is a measure of how many times a user loads the page on your site where the video sits (this does not mean the video is played/watched). A video view is a measure of each time a user hits play on your video, and thus views it. Note the distinction.

The ratio of video views to video pageviews generally ranges from about 10% to about 50%. If more than 50% of your pageviews result in a video view, your page layout and video thumbnail are considered greatly optimized. However, if less than 10% of your pageviews result in a video view, there's work to be done. Alternatively, you might want to re-think if placing a video on that certain page is a good idea, of if there might be more optimal pages within your site.

Every video analytics provider offers these pageviews and video views metrics, although the exact naming differs. Video pageviews are also called embeds or loads and video views are sometimes called plays or starts.

Metric 2: Hours Viewed

With traditional website metrics, a comparison of the amount of site visits to the amount of pageviews gives you a good sense of the stickyness of your content - users that like what you write will read multiple pages. In online video, this same logic is applied to compare the number of video views to the number of total hours viewed by your visitors. For example, if you have a 3-minute video on your site and 20 visitors watch the entire video, the video is reported to have 1 hour viewed (i.e. 20 visitors x 3 minutes = 60 minutes viewed).

It is generally useful to understand just how much of your video a user is watching. In the example above - if you have 20 video views for your 3 minute video, but total hours viewed is only 0.25 (or 15 minutes), then the average visitor is only watching about 45 seconds of your 3 minute video. This statistic can help you evaluate your video content.

If the duration of videos on your website varies greatly, the number of hours viewed is a more effective business metric than the number of video views. This is particularly interesting for those experimenting with video advertising - using advertisements to monetize your content. A long video with fewer views, but 10 ads, might make more money than a short video with more views, and only 1 ad. The former may result in fewer video views, but hours viewed will be higher, and in this case, directly proportional to more revenue. The latter with have more video views, but total hours viewed will be less. So these statistics are not always comparable. Hulu is a great example of a site where the number of hours viewed is more important than the number of video views.

The hours viewed metric is offered by nearly all video analytic providers and naming is generally consistent.

Metric 3: Video Engagement

Since video is a temporal medium (i.e. contains a timeline), the number of views for a given clip doesn't say much about its actual performance. Even the number of hours viewed lacks a true performance metric. For examples, where do viewers drop off? How many viewers watch the entire video? Are there sections in the video that viewer like so much they seek back and replay?

Video engagement is the metric that answers these questions, providing you with a deep understanding of how your visitors interact with your videos. Engagement is usually plotted as a chart, showing you the number of viewers for every second in your video. Steep drops in the chart show that a lot of visitors stop watching your clip at that point. This can help you effectively edit your video. Bumps in the chart show that visitors re-play that section. You might want to insert an advertisement there, or simply keep in mind that the info shown in this section really resonates with your visitors - learning something valuable about user activity.

Video Engagement is a powerful metric. However, while being the most insightful it is also the most technically challenging metric to track. Not all analytics providers offer it. Those that do all call it engagement, with the exception of YouTube, which calls it attention.

Get Started!

With these three basic metrics, you are able to compile valuable reports on the performance of your videos and the behavior of your audience. Note that most video analytics platforms provide more information, such as embeds on third-party websites (useful for UCG video) and unique number of viewers (useful for news reports).

There are plenty of options for people who want to start tracking their videos! We ourselves offer a comprehensive suite of reports with our Bits on the Run platform. We also offer a GAPro plugin, which adds video-specific reports to your existing Google Analytics account. Other highly recommended options are the tools developed by specialists like Omniture and Visible Measures - video analytics is their bread and butter, and they usually offer the widest array of tools and metrics.

  Tweet   Share

Safari & Quicktime are Not Web Standards

by Jeroen Wijering on June 07, 2010

To call HTML5 Video a hype would be an understatement. Every week, major tech companies announce improved support or new breakthroughs. Literally hundreds of new blogposts a day pop up on Google's blog search. In this debate, no company is as vocal as Apple.

The company's latest move is the release of an HTML5 showcase that includes a video demo featuring the capabilities of web standards such as HTML5, CSS3, and JavaScript. This effort, while exciting, is misleading and potentially detrimental to the landscape of web development and browser compatibilities. The demo is definitely inspiring and helps to move HTML5 Video along at a fast clip. At the same time though, none of the cool gizmos on this page are actually web standards. Instead, they are specific functionalities found in Apple's Safari/Quicktime product stack (which is why access is restricted to Safari). A breakdown:

The Video

Although the video codec debate has heated up with Google's release of WebM, Apple firmly stands by H.264. The demo offers no OGG or WebM version of the video, just an image fallback:

<video id="videoShowcase" width="848" height="352" 
  src=".../demos/apple-html5-demo-tron_legacy-us-20100601_r848-2cie.mov" 
  poster="... /images/tron_legacy.jpg" 
  loop="loop" autoplay="autoplay" autobuffer="autobuffer">
  <img src="... /images/tron_legacy.jpg">
</video>

The loaded video is actually not an MP4 but a MOV. MOV, 99% similar to MP4, is the container format of Apple's Quicktime technology. This video only works on Safari, and in order to play this video in Safari on Windows, a user must have the Quicktime plugin installed. No other browser is able to play the video.

A more standards-based approach would be to use an MP4 video instead of a MOV one, while simultaneously also offering an OGG video. That will work on all HTML5 browsers.

The Controls

The scale, mask and perspective video controls are very slick, but unfortunately still browser-specific features. Here's how the CSS of the video looks with these options enabled:

-webkit-mask-image: url(... /images/tron_mask.png);
-webkit-mask-repeat: no-repeat;
-webkit-mask-size: 100% 100%;
-webkit-transform: matrix3d(0.64,0,0.64,0,0,0.83,0,0,-0.53,0,0.76,0,0,0,0,1);
-webkit-transform-style: preserve-3d;
-webkit-transition-duration: 0.5s;
-webkit-transition-timing-function: cubic-bezier(0, 0, 0.58, 1);

This chunk of CSS3 will only render on Webkit-based browsers: Safari and Chrome. Firefox and Opera will not recognize these proprietary style rules.

A more standards-based approach would be to use mask, transform and transition CSS rules using both -webkit-, -moz- and -o- prefixes. Apple could be frank about the draft status of these functionalities and the current differences in browser implementations.

The Description

The description below the video mostly talks about Safari's proprietary HTTP streaming technology:

The HTML5 video tag allows you to integrate video within your website’s code. And Safari offers HTTP streaming, so playback quality dynamically adjusts to the available speed of wired or wireless networks — perfect for viewing on mobile devices such as iPad, iPhone, and iPod Touch.

Unfortunately, HTTP Live Streaming only works on the iPad, iPhone, iPod Touch and Mac OSX 10.6 (with Quicktime X). Additionally, the technology requires one to encode videos into an obscure format: hundreds of small MPEG-TS fragments, glued together using M3U8 playlists. These video files are completely useless for any other browser or media player.

A more standards-based approach would be to explain that seeking to non-downloaded parts of the video (like YouTube) is possible. This functionality, using HTTP Range-Requests, is supported by all HTML5 browsers. HTML5 video at large has no capabilities in the area of bandwidth detection and on-the-fly bitrate switching.

HTML5 is About Standards

Undoubtedly, no one has done as much for HTML5 Video as Apple has to date.  However, we must be sure to not overlook the progress Flash made when they started supporting video a couple of years ago. Suddenly it was possible to easily display videos on a page, regardless of browser or operating system. Only one chunk of code and only one video file were needed; plugin daisychains and forced installations were a thing of the past. Due to its ubiquity, Flash effectively enabled the online video surge of the last few years.

Similarly, the big promise of HTML5 Video is of it being a widely adopted and highly standardized technology. While Apple may see it as a means to reach feature parity with Flash, most web developers see it as a simple solution for including video in a webpage without worrying about plugin support. Web standards are about removing incompatibility barriers altogether. They are not about replacing plugins with proprietary browser addons, which is exactly what Apple has done here.

It would be awesome for Apple to start advocating the use of cross-browser HTML5 Video, being honest about what the technology can and cannot do today. Alternatively, it would be great for Apple to tell developers what its demo actually is: an excellent showcase of the video capabilities of its Safari / Quicktime product stack. Regardless, Apple should stop labelling vendor-specific implementations as web standards. It confuses web developers and it will lead to a new era of browser incompatibility that will slow down the overall adoption of HTML5 - and the conveniences it brings to web developers around the world.

Jeroen Wijering and Zachary Ozer

Comments (17)   Tweet   Share

Google's VP8/WebM and What it Means for You

by Jeroen Wijering on May 26, 2010

Several months ago, Google bought ON2, the company behind the successful video codecs VP6 (used in Flash) and VP7 (used in Skype). Ever since the first rumors of this acquisition emerged, the online video community has speculated what this would mean for HTML5 video and its current issues around codec support. Last wednesday, Google finally made the announcement people hoped for: it open-sourced On2's VP8 codec as part of its WebM open media project.

Immediately after the announcement, we started receiving questions from our users: What exactly is WebM? Is it better than H.264? Do I have to re-encode my videos? Do you support WebM? This blog post answers these questions, focussing on the practical implications of WebM. Feel free to comment on this post if you have additional questions - we'll keep an eye on it.

What is WebM?

First, a little overview. WebM is the overall name of the new video format Google launched last wednesday. WebM videos have the extension .webm (e.g. myCoolVideo.webm). They contain three major building blocks:

• The WebM container. A container defines the overall structure in which video and audio are saved. It also stores information on the file (e.g. width and duration). The WebM container is essentially a stripped down version of the Matroska one (.mkv videos are popular in the movie Torrent scene).
• The VP8 video codec. A video codec defines how the original video data is being encoded to achieve a reasonable filesize. VP8 is a so-called lossy codec (like H.264), which means that the compressed video has a lower quality than the original video. VP8 does do a great job at that though (more on quality below).
• The Vorbis audio codec. An audio codec does exactly the same as a video codec: encode the original data to make it easier to store and distribute. Vorbis is a truly excellent audio codec.

What About Rights?

The big issue surrounding HTML5 video - video codecs - is basically an issue of rights. On one hand there is the H.264 codec, which is of superior quality but heavily patented. End users and online video publishers do not have to pay (at least, not yet), but browser and device vendors do pay millions of dollars for incorporating H264 support. On the other hand, there's the Theora codec, which is royalty-free but of inferior quality (in fact, Theora is a heavily modified version of ON2's VP3 codec).

Like Theora, VP8 is released using an open-source, royalty free license. The license also permits free inclusion in closed-source commercial products. Because of its free license, the VP8 codec has the ability to end the HTML5 codec war and become the de facto HTML5 video codec. Like VP8, the WebM container and Vorbis audio codec are open source, royalty-free and liberally licensed.

Is VP8 Better Than H.264?

In its current state, VP8 is not better than H.264. The quality of VP8 video is more or less on par with the lowest quality profile of H.264: Baseline. The two higher quality profiles - Main and High - offer better results. VP8 is definitely better than Theora though.

Is this bad news? Absolutely not. One could say that VP8 video simply is good enough, just like JPEG was good enough for images and MP3 was good enough for audio. On top of that, the majority of today's H.264 videos use the Baseline profile, for efficiency and compatibility reasons. For example, Bits on the Run uses H.264 Baseline because videos transcode faster and more computers (e.g. ATOM-based netbooks) can play the videos without stuttering. Also, most mobile devices (like the iPhone) only support H.264 Baseline.

When Can I Use WebM?

It depends. If you just want to do some tests with WebM, you can get started today. Download Miro Video Converter to encode your videos to WebM. Download Opera 10.54 to play these videos using the HTML5 video tag. Here is a WebM example using the JW Player for HTML5.

If you want to use WebM in a production environment, the story is different. The ecosystem around WebM (browsers, transcoders, hardware support) is in its infancy. It will take a few years until WebM has the same level of support and end-user penetration (browsers, phones) than H.264 has today. Also expect major improvements to the VP8 quality and processing speed, and solutions for advanced use cases like live streaming or security. This year for sure, H.264 will remain to be the best option for publishing video in a production environment.

When Will LongTail Video Support WebM?

Let's start with our JW Player and its family of products. Since the JW Players are in fact middleware (written in actionscript/javascript), we depend upon support for WebM decoding in the underlying technologies:

• Opera, Firefox and Chrome already released preview browsers that support WebM. This means we support WebM for our HTML5 player today.
• Adobe will also support WebM in a future release of Flash. When that happens, our Flash player will automatically inherit WebM support. Our wild guess is that this will happen in 6 to 12 months.
• Microsoft has not made any announcements for WebM support in Silverlight, so an ETA for our Silverlight player is unclear.

For our video platform, Bits on the Run, expect WebM transcoding support to arrive in 3 to 6 months. We will wait for official releases of web browsers that can play WebM. Luckily, the implementation itself is fairly straightforward, since the WebM project includes an encoding library for the tool we use - FFmpeg.

As to when we will endorse WebM as the video format of choice - it depends upon the speed with which WebM will be adopted by the online community. It could be five years from now. It could also be one year from now, if WebM is adopted as fast as the <video> tag.  Overall, we are very excited about WebM - both in terms of quality and licensing, it has what it takes to become the de facto format for online video.

Comments (13)   Tweet   Share

HTML5 Video: Not Quite There Yet

by Jeroen Wijering on May 10, 2010

Online video is an exciting field to work in.  As creator of the JW Player, I'm privileged to be at the forefront of the industry.  Every week, our team receives thousands of emails from web developers regarding various bug reports, product feature requests and general thoughts about the online video space. In these emails, we've seen a growing interest in HTML5, since its video implementation allows web developers to independently control video content.

Apple's launch of the iPad and its successive arguments with Adobe over Flash accelerated HTML5 video development. One could argue that today's tech industry is in a state of video tag euphoria.  Although many high level discussions regarding online video are circulating through the blogosphere, the practical side of HTML5 video development has been overlooked.  Therefore, when working hands-on with HTML5 for video development, it becomes clear the standard faces a major threat.

The video tag is still in its infancy and misses certain core functionalities. As developers demand these features, browser vendors are tempted to implement incompatible solutions instead of agreeing upon standards.  These hasty developments, already underway, are setting HTML video up for the same chaos  as HTML styling in the pre-CSS era.

Here are a couple of the most pressing issues:

Codecs

The H264 versus OGG debate is ongoing, but all browsers have placed their bets - Firefox and Opera favor OGG, Internet Explorer and Safari choose H264.  Chrome plays it safe and does both.

While their reasoning is noble, Firefox's choice to support just OGG isn't practical. The majority of online video content is encoded in H264. Nearly all mobile devices that support web browsing use H264.   Desktops and laptops can do hardware decoding of H264.  By contrast, content in OGG is virtually nonexistent and the number of mobile devices supporting OGG decoding is devoid. The lack of hardware decoding for OGG makes playback of HD content a resource hog.  Apparently, developers don't want this.

Perhaps OGG (or VP8) will gain traction in the coming years. However, developers want to use HTML5 video today. And today's online video format is H264.

Streaming

HTML5 does not specify a streaming mechanism yet. While this is being worked on (W3C: Fragments, Media Multitrack API), it means that live, DVR and long-form video content cannot be played using a video tag. Most browsers do provide an alternative, such as utilizing the range request header to do pseudo-streaming, but this is no long-term solution.

Safari, however, does provide a working streaming solution. It is easy to use (although a simple ingestion tool is still missing) and follows the emerging standard of chopping up videos into small fragments and delivering those to the browser. Unfortunately there are small differences between Safari's implementation and that of, say, Silverlight and Flash:

1) Safari requires the video fragments to be wrapped in an MPEG TS container, while both Flash and Silverlight use MP4 containers.
2) Safari uses M3U8 text files to tell the browser which video fragments are available. Silverlight and Flash both use XML files. 

Since streaming is the single biggest block missing in HTML5 video, other browsers may rush to implement their own streaming solutions (for example, IE9 might support Silverlight's fragmentation and manifesting). A single standard is needed for HTML5 video streaming to ensure its usefulness. 

Fullscreen

While a small feature at first sight, fullscreen playback is essential to the success of HTML5 video. Fullscreen video captivates the viewer, greatly enhancing the visual experience, and tends to increase viewer engagement.  Without fullscreen, HTML5 video is mostly useful for presenting short clips.

Browser-wise, things get a little complicated. The W3C video draft specifically states that browsers should not provide a public API to cause videos to be shown full-screen. The underlying reasoning (phishing) is valid, but technologies like Flash and Silverlight have already proven that simple restrictions can mitigate these risks.

Meanwhile, developers have demanded fullscreen playback and browser vendors worked around the W3C spec to implement custom solutions. In Firefox 3.6, fullscreen viewing is available by right-clicking a video (no API). In Webkit (the rendering engine both Safari and Chrome are based on), fullscreen mode can be activated by means of ALT-clicking (semi-API). Both options are too obscure to gain any traction. A single public API with clear restrictions is needed. 

Conclusion

Video is an important part of today's internet. It deserves to become a first-class citizen and the video tag provides the opportunity to make that happen.  Browser vendors should be stringent when building solutions that are both practical and compatible.  If not, crossbrowser HTML5 video will be too difficult, not to mention expensive, to implement.  This presents the risk of web development regression. 

In favor of its advancement, we cannot allow this to happen.  Online video will go mobile and big screen.  It also needs to become accessible and searchable.  HTML5 video will advance the progress in these areas, if developed carefully and intelligently.  However, without compatible solutions, online video is in definite jeopardy of a setback.

Comments (46)   Tweet   Share

So Have You Heard About Bits on the Run?

by Jeroen Wijering on April 29, 2010

Bits on the Run is the newest addition to our family of products; an easy to use and affordable online video platform for streaming, hosting, and transcoding. The cool thing about Bits on the Run is that you can actually access all functionalities through our API, allowing you to build video transcoding, management and streaming capabilities in your own site or CMS.  

Already serving thousands of customers, Bits on the Run is fully compatible with the JW Player and provides Web Publishers with affordable and flexible video publishing tools. Some of the most exciting features (in our opinion) are: 

• A complete integration with our JW Player, making setup and embedding dead easy.
• Integration with our AdSolution, allowing you to monetize your videos.
• Conversion of videos to various formats and quality levels.
• Built-in video analytics reporting system (or easy integration with Google Analytics).
• Automatic streaming of the best possible quality video to each of your visitors.

Features aside, we merged with Bits on the Run because the platform is built upon the same ideas that made the JW Player so successful:

• Affordable, pay-as-you-go pricing
• Self-served, easy workflow
• Fast-responding, hands-on-support

I encourage you to start a free 1 month trial and check it out for yourself!   

Of course, there's a lot to be done still, especially in terms of complete product integration. The Bits on the Run documentation will move to this community site; the dashboard will get a re-styling; and we still have to upgrade to JW Player version 5 (with PNG skinning!). As always, we'd love to hear your suggestions and feedback!

  Tweet   Share

Welcome to the LongTail Community

by Jeroen Wijering on April 12, 2010

Welcome to the new Community Support section of our site.  Its purpose is to bring together the people and knowledge that surround the JW Player.  Here you'll find documentation & examples, receive news & tips about our products, and be able to interact with our support team, developers, and other members of the community.

We hope you like what you find here, and we encourage you to make suggestions for the future.

Comments (4)   Tweet   Share