First of all, check out the new video tag builder. The previous version of this site had an embed code builder, and people were pretty disappointed that the new site didn’t. So I’m happy to announce that it’s available again, now as an HTML5 video tag builder that could probably be used outside of Video.js, it includes track tags, and even lets you test the settings. Let me know if you have any feedback on it.

The most notable change in this release is probably the completely overhauled <track> tag support.

https://gist.github.com/4092295.js?file=html5-track-tag.html

The new version supports subtitles, captions, and even chapters. When you include tracks of different kinds, Video.js will automatically create menus in the player where users can select the language to display, or which chapter to jump to. Video.js also now supports the new WebVTT text format, which is not far off from the previously supported WebSRT format but did take some tweaking in the parser. Not all WebVTT placement features are supported yet, but the basics of displaying text are, and we’ll be working to get more WebVTT features built in.

Additionally there was work done to make some API methods accessible earlier. For any method that isn’t a getter (returns a specific value from the player), if you call the method before the playback technology (HTML5/Flash) is ready, it will now cache the call until it is ready. So where previously you might have had to wait for the ready callback:

https://gist.github.com/4092295.js?file=wait-for-ready.js

You could now do:

https://gist.github.com/4092295.js?file=no-wait-for-ready.js

Again, that’s just for methods where you are setting a value or triggering an action. If you try to get a value back like myPlayer.duration(), you’ll get nothing until the player is ready.

One other feature that was requested in the forums was automatically translating relative video URLs to absolute URLs for the flash fallback. This was an issue with the CDN hosted version which involved loading a remote SWF file which didn’t have the same context as the player. Before we would just tell people to use full URLs (http://) but that shouldn’t be an issue anymore.

Thanks to everyone that’s helped contribute code lately, and apologies for any long response times in the forums as I continue to try to push out code.

Here’s the full change log for the release.

3.2.0 / 2012-03-20 / baxter

• Updated docs with more options.
• Overhauled HTML5 Track support.
• Fixed Flash always autoplaying when setting source.
• Fixed localStorage context
• Updated ‘fullscreenchange’ event to be called even if the user presses escape to exit fullscreen.
• Automatically converting source URL to absolute for Flash fallback.
• Created new 'loadedalldata’ event for when the source is completely downloaded
• Improved player.destroy(). Now removes elements and references.
• Refactored API to be more immediately available.

Cheers,
-Heff

This is the first release since the initial 3.0 launch, aside from some hotfixes that went out immediately. It includes a number of fixes for things that users in the forums found right off the bat.

One feature that’s optional for testing in this release is iFrame Mode for Flash. One the of the unique things about Video.js is we haven’t built any controls into our Flash player, and instead use HTML and CSS to create the controls for the Flash side as well. This keeps the experience consistent and the Flash player very lightweight, however there’s a number of issues that you run into with Flash when you take an approach like this. If you’ve ever tried to resize the parent of a Flash object, or hide a Flash object and then show it again, you’ve probably run into the issue of Flash reloading in Firefox. This is a bug that’s been in Firefox for quite a long time however it looks like it might be fixed by version 13 (currently 9). To add on top of this, with the new browser fullscreen API, the other browsers now also reload Flash when you go to native fullscreen.

We’ve found a bit of a fix where if you embed the Flash object in an iframe first, it can get around the reloading in some of these cases. So in the new version there’s an option to turn this on and try it.

https://gist.github.com/4092929.js?file=iframe-mode.js

We’ll be doing some more testing to make sure it’s stable before we push it out to everyone.

Here’s the full change log for the release.

3.1.0 / 2012-01-30 / leonardo

• Added CSS fix for Firefox 9 fullscreen (in the rare case that it’s enabled)
• Replaced swfobject with custom embed to save file size.
• Added flash iframe-mode, an experimental method for getting around flash reloading issues.
• Fixed issue with volume knob position. Improved controls fading.
• Fixed ian issue with triggering fullscreen a second time.
• Fixed issue with getting attributes in Firefox 3.0
• Escaping special characters in source URL for Flash
• Added a check for if Firefox is enabled which fixes a Firefox 9 issue
• Stopped spinner from showing on ‘stalled’ events since browsers sometimes don’t show that they’ve recovered.
• Fixed CDN Version which was breaking dev.html
• Made full-window mode more independent
• Added rakefile for release generation

Cheers,
-Heff

After months and months of work we’re happy to announce Video.js version 3.0. Some of the exiting new features include:

• Same HTML/CSS Skin for both HTML5 and Flash video
• Super lightweight Flash fallback player for browsers that don’t support HTML5 video
• Free CDN hosting by Level3 A lot more releases and developments are on their way!

Cheers,
-Heff

I recently filmed a series of HTML5 video tutorials for Lynda.com, a really great service for online training. It was a great experience, and the videos are now available for viewing. You can get a 7-day free trial here and check them out. Let me know if they’re helpful at all.

-Heff

I’d love to hear where and how people are using video.js. If you’re using it somewhere, leave a note/link in the comments.

Cheers,
-Heff

One of the things that browser and device vendors stand behind when deciding to support MP4/h.264 over Google’s Webm video format and VP8 codec, is that while VP8 is open source, it may still be encumbered by patents. So far none of these submarine patents have surfaced, but now MPEG LA has put out a call, and hopes to form a patent pool that would create a license for VP8, and essentially put a price on it. In Google’s own license, it says:

“If you or your agent or exclusive licensee institute or order or agree to the institution of patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that this implementation of VP8 or any code incorporated within this implementation of VP8 constitutes direct or contributory patent infringement, or inducement of patent infringement, then any patent rights granted to you under this License for this implementation of VP8 shall terminate as of the date such litigation is filed.”

So if you claim VP8 infringes on a patent and sue, your license to use VP8 is terminated. Not sure exactly how that would affect a patent pool, but an interesting battle could be ahead.

AirPlay is a video feature on iOS devices that lets you play video from your device on your TV, by streaming it to an Apple TV on the same wireless network. Before now this was only available in the iPod and YouTube apps, but with iOS 4.3 (now in beta) it will be available through Mobile Safari as well.

In order to allow AirPlay as an option, video publishers have to add an attribute to the HTML5 video tag. <video width=“480” height=“300” controls x-webkit-airplay=“allow”> … We’ll be adding this as a default attribute in the next VideoJS version.

Read the whole story on MacRumors.

UPDATE: Added a chart that shows what format support will look like without Chrome supporting h.264.

Google has decided to support the open source community by dropping h.264 support from Chrome. Previously Chrome was the only browser that could play all 3 major HTML5 formats—MP4/h.264, WebM/VP8, and Ogg/Theora. This is probably a strategic move at the same time, since h.264 seems unlikely to be beaten at this point, especially with IE9 supporting h.264 while requiring an extra plugin to use VP8. In my opinion, there’s two major events that could end the format war.

1. Apple adopts WebM/VP8 (which would require adequate hardware to include in iOS devices)

2. MPEG LA removes all royalties from h.264

Read the original post.

As we roll into 2011, HTML5 video hits a major milestone. 50.5% of web users now support HTML5 video playback. This number was gathered by comparing browser versions that support HTML5 video with StatCounter’s world-wide browser version statistics.

This is a 66% growth in HTML5 video user support since December of 2009. With the expected release of Internet Explorer 9 in the near future, 2011 could see a major increase in websites adopting HTML5 video as their primary playback method. Of browsers that support HTML5 video, Mozilla’s Firefox is the clear leader, with Google’s Chrome in second place. Much of the growth in HTML5 video support can be attributed to Chrome’s success in stealing market share from Internet Explore over the last year.

Video Formats

The format war continues to be a deterrent of HTML5 video adoption, and there’s no clear end in sight. While Apple has helped accelerate HTML5 video by requiring it for video playback on the iPhone, it’s also the one vendor that will not support Google’s WebM/VP8 format, which has the highest potential for becoming the standard format for HTML5 video. Among other reasons, Apple has invested a lot of money in the mp4/h.264 format, including hardware built into iPads and iPhones to decode/encode it. Meaning even if Apple decided to support WebM, it would take more than a simple software update to get WebM to the many iPhone and iPad users. Microsoft has said they will support WebM/VP8 in Internet Explorer 9, however only “when the user has installed a VP8 codec”. Which basically means they won’t support it. Microsoft’s preference for MP4/h.264 was made more obvious with their release of a plugin that allows h.264 to be played back in Firefox on Windows. The following graphs show the support and growth of the different video formats.

WebM had a sharp rise in August as Google released Chrome 6 and pushed out updates to its users. In the following charts you can see different views of how formats are divided among HTML5 video users. The first chart shows user support by combinations of formats. The second compares support of open vs. closed formats.

From an HTML5 video perspective, open formats win out significantly over closed formats, with Apple and IE9 hanging on to the last 10%. This may change over the next year with the official release of IE9, unless Microsoft decides to support WebM/VP8 without the need for an additional installation. Finally, if you are interested in the Flash vs. HTML5 debate, Flash is well entrenched and HTML5 video still has a long way to catch up. According to Adobe, Flash is supported by over 99% of web users. Statistics from other sites seem to support this, though according to Omniture (now Adobe), the internet average is 116.8% (sic).

As of Flash 9 update 3 (9.0.115), Flash has supported the MP4/h.264 format for video playback. In the following chart, you can see how considering Flash affects the comparison of video format support.

However, Adobe has said they will support WebM/VP8 in a later release of Flash. The rate that users upgrade to the latest version of Flash is relatively fast, so this could have a big impact on WebM support when it happens. Overall, Flash will be difficult for HTML5 to dethrone. Beyond user support and format discrepancies there is a long list of features that Flash players have supported for years, which will take time for all browsers to build in. However, many of those features can be built with JavaScript, which allows them to be used across browsers immediately. It’s up to the open source community to build the features people need to accept HTML5 as their primary means of video playback. VideoJS is an open source HTML5 video player and framework that makes it easy to support HTML5 video as well as Flash for older browsers. It provides a consistent interface across browsers and solves many browser/mobile device bugs. There are still quite a few rough edges with HTML5 video, but the many contributors to VideoJS are smoothing those over and expanding VideoJS to meet the needs of web users.

Mozilla has a cool demo of playing a video while drawing a line on a Google map similar to what you’d see in an Indiana Jones film. Check out the original post and the demo.