Video.js 4.0 now available!

Today we’re releasing Video.js 4.0, which is the most solid, lightweight, and I dare say prettiest version yet. It’s available for download, on Github, and hosted for free on our CDN.

Version 4.0 received the most community collaboration of any previous version, which speaks to the growing strength of the JavaScript community, the growing popularity of HTML5 video, and an increase in Video.js usage. Over the last year the number of sites using Video.js has more than doubled, and each month there are over 200 million hits to the CDN-hosted version alone! Thank you to all of the Video.js community members for contributing code and filing bug reports.

This version is also a milestone in that it’s the first version released since Brightcove acquired Zencoder last year. For those who missed the announcement, it was a very good thing for Video.js. In the past, Video.js was a side project for Zencoder that I maintained on top of my regular responsibilities (as if startup life isn’t exciting enough). Post-acquisition, Brightcove has not only put me full-time on Video.js, but the Brightcove video player team has become contributors to the project. The Brightcove team is probably the most experienced video player team in the world, supporting the most advanced video technology, for the biggest brands, across all the devices. It’s been a privilege to work with them and they’ve made major contributions to this version.

4.0 Major Feature Summary:

Improved performance through an 18% size reduction using Google Closure Compiler in advanced mode

  • Greater stability through an automated cross-browser/device test suite using TravisCI, Bunyip, and Browserstack.
  • New plugin interface and plugin listing for extending Video.js
  • New default skin design that uses font icons for greater customization
  • Responsive design and retina display support
  • Improved accessibility through better ARIA support
  • Moved to Apache 2.0 license
  • 100% JavaScript development tool set including Grunt

Improved Performance

With version 4.0, performance was our top priority, and a major factor of performance is the time it takes to load the library. What would seem to be minor size reductions can have a big impact, especially when a library will be loaded millions of times a month all over the world. We chose to use Google’s Closure Compiler because its “advanced mode” currently provides the most aggressive options for code minification, and so far we’ve seen an 18% reduction in code size, with the potential for more.

Closure Compiler also claims to rewrite code for better runtime performance, though we haven’t had a chance to benchmark this yet.

Some preliminary load-time benchmarking* shows:

  • Player load times in under 50 milliseconds
  • Playback start times in under 150 milliseconds
  • Actual video playback seen in under 0.5 seconds (using a CDN hosted MP4)

*Initial tests used Chrome with an empty cache on a modern MacBook Pro with a Wi-Fi connection. More formal testing to follow.

Greater Stability

Automated cross-browser, cross-device testing is the Holy Grail of testing for a JavaScript library. While building version 4.0, we’ve been able to reach that goal through the use of a number of tools, including:

  • TravisCI - Automatically runs unit tests through PhantomJS on every pull request made to the Video.js source code
  • Bunyip + Browserstack - Allows us to run tests in cloud-hosted instances of any browser from IE6 to the latest Chrome, and also a wide range of iOS and Android devices.

This ability to easily run tests across environments before any new release will give us more protection against regressions, and can allow for a faster feature release cycle.

New Plugin Interface

The new plugins API allows developers to more easily add custom features to Video.js. The API works similarly to the jQuery plugin interface, giving developers access to add to or overwrite any piece of Video.js. Once a plugin has been created, it can be shared on the Video.js plugin list page on the wiki.

New Default Skin

With help from the Brightcove UX team, we’ve created a new default skin that’s simpler, more polished, and more customizable. One of the most interesting features is that we’ve moved from using images for icons to font icons. The use of font icons allows you to change the color and size of the icons simply by changing a CSS value. You can see an example of this on the Video.js homepage.

Improved Accessibility

Greg Kraus, a Video.js community member from, did some great work testing and improving Video.js accessibility through better use of ARIA roles. The changes make it so keyboard-only users, screen reader users, and voice-interface users will be able to interact with the video player. UPDATE: Read more in Greg’s blog post.

Moved to Apache 2.0 License

Earlier versions of Video.js were released under the LGPLv3 license. LGPL often gets confused with its stricter sibling, GPL, which requires that all code the software touches must also be open source. Video.js is meant to be open and free to use in all contexts, and we want that to be clear, so version 4.0 is now released under Apache 2.0, the same license Twitter Bootstrap is released under.

100% JavaScript Tool Set

Previously Video.js used Ruby for development tools, including Rake for deployment tasks, and zenflow–an internal Zencoder tool that builds on gitflow for development process workflow. With 4.0 we’ve moved to Grunt for tasks and we’re building out a tool similar to zenflow in Node.js. Now Open Source

As part of this release we’ve also made the website open source. So if you see something that should be added or fixed, fork it.

What now?

Even with all of the updates listed above, this is simply a jumping-off point for what will be an exciting year for Video.js. We’re continuing to improve performance, multi-platform stability, and customizability through plugins and skins. Members of the community have already started work on plugins for some of the more requested features, like playlists, analytics, and advertising.

Follow @videojs or sign up for our newsletter to stay up-to-date on new features and roadmap updates.

If you’d like to get involved in the project, check out our contributing guide.


Repo Moved!

In preparation for the next version we’ve moved the source code repository from to

If you have a local clone you can update your clone’s upstream URL with:

git remote set-url upstream git://

The relationship between your fork (e.g. should still be intact, including any pull requests.


Site and Support Updates

After a brief hiatus of helping Brightcove and Zencoder come together, I’m moving full time to developing and supporting Video.js. Thank you to everyone who has continued to commit code and help out in the forums.

As part of this move I’m trying to optimize the tools used for video.js project management and support. The first big change is that the forums are being replaced with Stack Overflow (tag with “video.js”) and Github Issues.

Over the last few years Video.js has become more popular than I ever expected, and at the same time Stack Overflow has come up as an incredible tool for supporting developer communities. So along with many other projects like Facebook, Android, and HTML5 Boilerplate, I’m excited to move support to Stack Overflow’s awesome tool and community. I’ll be leaving the forums up for bit but from here forward please post questions to Stack Overflow and use the “video.js” tag.

I’ve also begun cleaning up and organizing the Github Issues for Video.js, which previously existed, but issues were split between the forum and Github. If you find specific bugs with video.js please submit them there.

On the project management side of things I’ll be using Trello, and exposing boards so others can see the progress of development.

I’m also paring down the site and moving more complex sections to other services that can better handle them. I’ve already moved the blog to Tumblr, and I’m moving the docs to the Github repo, which has built-in docs formatting.

For those starting an open source project today, you can look at this as my guide to supporting an open source project. I wish I would have know to do all this when I started on Video.js.

More project updates coming soon.


Brightcove Acquires Zencoder

Today, Zencoder announced that it is being acquired by Brightcove, the leading online video platform (OVP). You can read more on the specifics in the Zencoder blog post and press release, but I also wanted to be clear on what this means for Video.js. As you may know, Video.js was created by me (Steve Heffernan, Co-founder of Zencoder) and Zencoder continues to be its core contributor and sponsor (like 37signals to Rails or Joyent to Node.js).

This acquisition means only great things for Video.js. To quickly summarize, Video.js will continue to be a free and open source video player & framework, and Brightcove will be investing more in Video.js than Zencoder ever could.

I wrote the first version of Video.js in early 2010 during Zencoder’s time in Y Combinator (while secluded in our rented house deep in the Santa Cruz mountains). Over the past few years I’ve continued to build the library and pull in contributions from other Zencoder team members and the community, but only on the side of my ongoing Founder and VP of Marketing duties at Zencoder. While Video.js has continued to gain popularity among developers and is now being used on over 25,000 websites, there’s still work to be done and room to grow. So one of the more significant changes that will be happening is that Brightcove will be putting me on Video.js full time, freeing me up to work on the core of the project and to better support the Video.js community, both users and contributors.

Beyond this, Brightcove has a first-class player development team backing their platform’s video player. While the specifics of how the two teams and players will work together are still being discussed, we have agreement on our philosophies and views about where player technology is going. This combined knowledge and collaboration is sure to have a positive impact for both players.

While the additional resources will have a big impact, the best open source software projects only got to where they are through the contributions of developers in the community. So if you’ve previously been cautious to dig into the source or push back a specific feature or bug fix, I hope this news only helps encourage you to jump in and help make Video.js the best resource for working with video in the browser.

There will be more info to come as things progress, but please feel free to ask any questions in the comments below.


Steve & The Zencoder Team

Version 3.2 Update

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.

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:

You could now do:

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.


Version 3.1 Update

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.

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


Video.js Version 3.0!

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!


New MPEG LA WebM/VP8 Patent Pool

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.