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.

Cheers,
-heff

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.

Cheers,

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.

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

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.

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

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!

Cheers,
-Heff

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.

Apple adds AirPlay to Mobile Safari

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.

AirPlay Feature in Mobile Safari

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.

Google is dropping h.264 from Chrome

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

Google Chrome Drops h.264 Support

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.