This is part of our larger effort to bring open video to the web. We’ve been glad to work with NVIDIA and Youtube on this project building the solution entirely on open standards like WebM and HTML5. Our hope is that by lowering the barrier for 3D video on the web, we’ll see more interesting apps being build on open web technologies.

This feature requires that you have 3D Vision hardware. If you do have 3D Vision Hardware, go to youtube.com and search for ‘yt3d‘. Files encoded with 3D have this tag. You will also have to set your 3D mode for the type of hardware you have.

Even if you don’t have the hardware, trust me. This feature is pretty cool. I was able to load up some 3D trailers on youtube and it was pretty amazing to see a little world appear in the video box.

It’s a super-easy tool for Windows and Mac users that converts video files. Just drop a video file onto it, pick the device you want the file to be used for and click the “Convert!” button. Nothing else required.

It supports a pile of different devices (G1, iPhone, etc – they are all different) and also supports outputting Theora video as well.

This comes from the same guys who do Miro, another wonderful video tool that lets you browse and subscribe to various video podcasts.

Anyway, it’s great to have a tool that makes this problem much easier for a lot of people. Great stuff!

Lawrence Lessig by Joi Ito, CC-BY

The Open Video Alliance will be hosting an online chat with Lawrence Lessig tomorrow at 6pm eastern time / 3pm pacific time (see more time zones here.)

There are a lot of events in person as well. I will be at the event near San Francisco.

The event will also be broadcast live with open video, thanks to Fluendo. The best client for you to watch it in will be either Firefox or VLC. More instructions on clients can be on the openvideo wiki.

One Cloud? by liberato

This really wonderful post by Anil Dash echos a lot of what I’ve been talking about in the context of the larger web. I had a discussion with Ben Galbraith recently about this topic during a Mozilla lunch. He and I took (intentionally) different positions on topics to see what kind of discussion we could stimulate around how developers see the web platform.

Ben has some concern that the web platform isn’t as coherent as those that you find from the other big players – the iPhone platform, Silverlight, Java or any of the other giant siloed stacks. (Actually Ben was more interested in the capabilities of those platforms vs. the web, but I’ll talk about that later.) I’m basically of the opinion that the web that we have, and as messy as it seems, actually produces pretty good results. That the incrementalism and experimentation that we’ve seen from web browser vendors results in what I call “developer-friendly incompatibility.” That those changes are eventually codified to standards and taken mainstream because they degrade well and we can learn as we go. (Kind of like life!)

But it does raise an interesting question – what capabilities do we need to have for the web that are found in these stacks? And can they be applied in an incremental fashion? We’re starting to see that with video being promoted as a first class citizen with Flash as a trailing edge fallback. We’re starting to see the web pick up 3D capabilities with participation from Google, Apple and Mozilla. And we have the pretty wonderful library model that has produced jQuery, jQuery UI, mootools, YUI, dojo and many others – all of which come from pushing complexity to the edges of the web community.

But is it enough? Discuss. What’s missing, and what’s interesting? I would particularly love to hear from Java and Silverlight developers. What do you really love about those platforms? Is source-as-delivery and incrementalism enough?

I’d like to personally thank the wonderful people at Dailymotion, along with Paul and Tristan who helped bring this project to the point where it is today.  Dailymotion has been an excellent test case for us because they haven’t just encoded with the formats that we support but also built a full-fledged player using HTML, CSS and JavaScript that looks, feels and acts like the flash-based players we see on the web today.  They also make it possible to embed open video using an clever <object> tag that loads the video content safely in an HTML page.

Standing on the twin pillars of the HTML5 video API and royalty-free codecs, the movement to bring open video to the web is well underway. Dailymotion, along with Wikipedia and the Internet Archive, have all committed to start serving up open video.  The free encoders are getting better and better over time and we’re starting to see more interest in the technologies.

Dailymotion, Mozilla and a large number of other partners will be at the Open Video Conference on June 19th and 20th.  If you’re interested in talking with us you might want to come down to the conference and learn what’s happening with video on the web.

The headlines include:

1.  They have made substantial improvements to Theora’s encoder.  The images which I include below really show off the improvements in sharpness at the same bitrate.

2. That the encoder is now creating higher-quality streams than H.264 at many bitrates. The data includes some comparison with x264 without ffmpeg bugs which show on this test that x264 does do better than Theora in this particular test. However, there’s an important side note worth reading on this topic.

3. That the original tests that gave Theora such a bad name were done with incredibly bad tools.  See the squiggly line on the graph in monty’s post for evidence of that.

Anyway, a picture speaks a thousand words so I’ll include them here.  Open them up in two tabs and switch between them for the full effect.

Theora 1.0:

Theora.next:

Monty points out that this was largely other people’s work and they should get most of the credit. So Greg, Tim and many others – thanks. Keep up the great work.

Ryan points out that there are significant differences between what Google has built here and what we’ve built. I thought it might be worth it to expand on that a bit since it isn’t explained in depth in the Ars article.

Google’s 3D work is a plugin.  So much like how Flash or Silverlight works you get a rectangle in the browser to draw into.  They provide a high level scene graph API which uses the COLLADA format for loading objects underneath.  It’s a very large chunk of code.  If you take a look at the API and click around at the packages and classes you can see that there’s a lot there.  Their use case is games and game-like things – virtual worlds.  So it’s a great piece of work, but it’s also at a very high level.

Mozilla’s current proposal to Khronos is a very simple API that’s a wrapper around OpenGL ES 2.0.  It’s currently available as an extension to Firefox 3.5 and is likely to be rolled into a version of Firefox after 3.5.  The proposal is very focused on 3D.  For example, we didn’t try to include video or audio because those are being covered by other web standards and we’re interested in making sure they are well integrated instead of trying to wrap those into a 3D spec.  We’ve bound it to the canvas element so you can use it in much the same way you use the current canvas 2D context.  Things like asset loading (via COLLADA or other systems) are things we haven’t dealt with because those can be handled entirely outside of the 3D api and layered on top of it.  (Later in this post you’ll understand why this is important.)  But the important thing is that it’s something that you can easily mix with the rest of the open web.  Open Video and Audio, CSS, HTML, Canvas 2D, Canvas 3D, etc – you should be able to mix them all together and that’s our goal.

So these two 3D things from Mozilla and Google are pretty different.  Not really competitive, either, because they have such different goals.  The Google software is a very high level API 3D graphics API and what we’re proposing is more akin to the low level graphics API that those high-level systems are built on.

Given the title of the google blog post (“Towards an open web standard for 3D graphics”) it’s important to point out these differences since they affect how the standards process might look, and what the output might be.  We’ve been through this a few times with different standards and it’s easy to point out what the key success factors are to build a successful standard.  Here’s a quick iteration on those principals in my mind:

1. It’s important to keep the scope as small as possible.

The smaller the scope of the standard, the easier it is to understand the interaction of the various parts, what your goals are and what it takes to build an interoperable implementation.  It’s also the easiest thing you can do to remain as future-proof as possible.  It’s easier to add new APIs later if your scope is very very small.

2. Clear rules for interaction with the rest of content.

How does it work with the rest of the HTML spec?  CSS?  Video?  Images?  How can you copy content in and out?  Can you use them as textures?  These are just some of the questions that you have to raise as a way to describe how something like this might work with content.  Once again, this is gated on #1 above – if the functionality is simple then the interactions can generally be pretty simple as well.

3. Allow the scope to change slowly over time.

Understanding that technology – especially on the web – does not exist in a vacuum outside of time.  Standards do change over time and understanding how people use technology in the real world is the best possible way to understand how something should change and improve.  Understanding that standards are an iterative process is important.  Note that in #1 above – controlling scope – I mention that it’s important to keep things future-proofed via small and simple APIs.  This is why – because you know that you will need to improve that API once you understand how people are using it in the field.

4. Allow most of the innovation to happen next to and on top of your API.

Last point – your standard should allow as much iteration and work to happen on top of your API as possible.  This allows you to learn as much as possible about how people are using your software and gives them huge amounts of freedom to experiment and teach you about what you need to improve in the next iteration.  If people are stretching your APIs and finding gaps in performance, you can add convenience APIs to make things faster – as long as they are simple APIs.  We saw this in the real world with the JS libraries (dojo, jQuery) – we’ve been optimizing our engines and APIs over time to assist them as they have pushed our browsers to the limits.  But we would not have known had we tried to implement everything that the libraries could have possibly done at the browser level.

OK, so those are the things that we think make for a successful standards process.  I’ll point out one particular example of a dichotomy that I believe illustrates these rules so that people understand what I’m talking about: Canvas vs. SVG + SMIL.

Canvas is a very simple API (more info), much like what we’ve proposed to Khronos for 3D support.  It’s well-scoped, well understood and integrates very well with other web technologies.  And it’s been getting a huge amount of traction on the web.  People are writing all kinds of really neat technology on top of it, including useful re-usable libraries for visualization.  Have a look through Google’s own promotional site for Chrome – a huge number of them use canvas.  It has traction.  And we’ve gone through a couple of iterations – we’ve added support for text and a couple of other odds and ends once we understood what people were trying to do with it.

Now compare this to SVG and SMIL.  Each of those specs are multi-hundred page documents with very large APIs and descriptions of how to translate their retained-mode graphics into something that’s usable on the web.  (SVG 1.1 is a 719 page PDF.  SVG 1.2 Tiny is 449 pages.  The spec for SMIL is a 2.7MB HTML file.)  We’ve seen some implementation of SVG and SMIL in browsers, but it’s been slow in coming and hasn’t seen full interoperability testing nor any real pick up on the web.  The model for these specs was wrong, and I think it shows.

So I’ve spent some time talking about the context for standardization and what makes standards successful.  How does this related to our stuff or Google’s stuff?  Well, quite a bit actually.  If we want something that browser vendors can easily implement, we need to understand that context and what we’re trying to standardize.  Much of the work that Google did happened before browsers got as fast as they have, so there’s a good reason why they felt that they needed to implement so much of the code as native code and deliver it as a plugin.  Their API is a good example of what a scenegraph API would look like on top of Canvas 3D.  JS engines have gotten a lot faster since they started their plug-in and we think that it’s time that we start using them.  Hence a low-level API that we can build on.

There’s a lot of great stuff going on with 3D on the web.  We’ll be working with Google (and others!) via the Khronos group to try and standardize on a low-level API that browsers can support.  It’s going to be a really fun year and I’m happy that we’re working to drive the web forward.