Free VP8 vs. Ogg/Theora

Ogg Theora seems to be really good at handling super-saturated images of vegetation

The Free Software Foundation has suggested to Google that it might want to make VP8 “irrevocably royalty free” (whatever that means—will it cover future developments of VP8?). Of course at the same time they argue that Ogg/Theora is as-good-or-better than H264 and of course it’s both open source and royalty free.

I’m not sure if I buy the quality argument (for a start, the article linked is almost entirely about image quality and not, for example, about compression time/effort or playback time/effort; next, Ogg/Theora may be very good at handling supersaturated images of vegetation growing near a river, but how does it do on more realistically saturated fleshtones? Most lossy codecs sacrifice blue detail in particular, so this may be a boneheaded comparison), but certainly Ogg/Theora is at least in the ballpark, and it’s free, so what’s the advantage of having an “irrevocably royalty free” VP8 as an alternative?

There are two major reasons why the world hasn’t embraced Ogg/Theora.

First of all, there’s lack of hardware support. Silicon that will decode H264 (not that desktop PCs or even laptops actually make much use of this hardware) with virtually no effort (for which read battery power) is available free with a box of cereal. No such hardware exists for VP8 or Ogg/Theora.

Let’s look ahead five years or so. We’d presumably like for there to be silicon that decodes our favorite video format free in boxes of cereal. We already have that for H264, is having such a chip available for VP8 going to make Ogg/Theora hardware support more or less likely?

Second, there’s the question of whether Ogg/Theora is actually unencumbered. H264 is, in essence, a known quantity. It’s backed by a huge bunch of megacorporations who have pooled their patents; even if someone comes along who claims to have a vital patent covering some obscure nook of H264’s implementation the participants in the H264 patent pool have lots of money, lawyers, and patents to with which to defend themselves (and they’re juicier targets than we are).

Ogg/Theora hasn’t been sued because no-one is making significant (any?) money with it, which in turn means there’s no reason for someone who thinks they could sue over it (a) to do so, or (b) even to let it be known they think they could do so (which is condemnation enough of our patent system).

If this were 1990 and we were talking about image file formats, “GIF” would be unencumbered. The GIF lawsuit only happened when someone figured there’d be money in it, and that was only true when lots of people became invested in using GIFs.

Here, we assume, VP8 has a huge advantage over Ogg/Theora because, presumably, Google has money, lawyers, and a patent portfolio. But unless VP8 is open sourced, I really don’t see the point. We’ll just be trading one master for another in the long run, since either VP8 won’t continue to evolve and will need to be replaced in fairly short order or it will and then it’s up to Google to figure out whether the new version is covered under “irrevocably”.

Addendum: really nice article on the whole Flash / VP8 / Theora / H264 / HTML5 thing (courtesy of daringfireball as usual). And yup, Theora’s claims to superior quality are a Sad Joke.

Adventures with <canvas>

acumen_asset_viewer
Acumen's Asset Viewer

Acumen is at 1.0 beta, and we finally settled on a hybrid image viewer. Google’s excanvas.js is used to fake a canvas in IE (getting it to work in IE8 was the trickiest part) but because excanvas.js runs pretty slowly and doesn’t support text (there are third-party text implementations of text in excanvas, but they’re also slow and don’t use standard fonts) I ended up using canvas just to render images. All main UI elements are implemented in HTML/CSS using jQuery.

Based on my googling, successfully creating a canvas that transparently works in either decent browsers or IE is not common knowledge, so I thought I’d share the method I came up with. I originally wrote this code for the pure canvas asset viewer (which forced IE users to install Chrome Frame); when I decided to reuse the code, I tried to simplify it, and everything I did to make it simpler broke it. I guess the me who wrote the original code wasn’t as big an idiot as the me who borrowed it thinks he was.

var c; // will contain a working canvas when we're done
var d = $('#div_that_will_contain_canvas');
var ie_version = some_expression_that_is_truthy_for_ie();
if( ie_version ){
	c = document.createElement('canvas');
	c.id = viewer_id;
	c.style.width = d.width() + 'px';
	c.style.height = d.height() + 'px';
	d.append( c );
	G_vmlCanvasManager.initElement( c );
} else {
	d.html('<canvas id="' + viewer_id + '" width="' + d.width() + '" height="' + d.height() + '"/>');
	c = document.getElementById( viewer_id );
}

The main takeaway is that creating the canvas using a blob of html does not work for IE (because it doesn’t recognize the canvas element, and thus ignores its attributes) and using the standard DOM methods does not work for proper canvas elements (because using styles to resize a real canvas stretches the canvas).

If you have a cleaner way of achieving the same result please let me know—I’m not proud of this code, it just happens to work.

HTML5 audio and video tags and Mozilla Firefox

One of the best things about HTML5 is that audio and video can be directly embedded in web pages in the obvious way — i.e. like images — with no weird third-party plugins or JavaScript required. This is a good thing. Unfortunately, while we’ve come to expect IE to not support anything good, it’s pretty disappointing to see that Mozilla has opted to only support the useless Ogg/Theora open source codecs. This means that in addition to having to code workarounds for IE (check for support for the tags, OK no problem) we have to check for support for specific codecs — and these checks are pretty damn annoying.

Checking for <video> or <audio> tag support is pretty straightforward:

function supportsVideoTag(){
    return !!document.createElement('video').canPlayType;
}

(I’ll leave figuring out how to do the same thing for audio tags as an exercise to the reader.)

But to check for specific format/codec support you need to actually verify that the specific file you’re wanting to play back is supported, which not only makes the code more complicated, but requires you to figure out the MIME string representing your file type, e.g. ‘audio/mp3’ or — worse — ‘video/x-new-fictional-format;codecs=”kittens,bunnies”‘ as the whatwg’s example puts it.

Here’s the thing — it would be nice to know that there’s some format — mp3 for audio, say — that will work 99% of the time if audio tag support is there. As it is, Firefox won’t play MP3s at all, and Webkit considers mp3s to be “audio/mpeg” while Chrome considers them to be “audio/mp3”. Heckuva job.

All this kind of defeats the whole point of “you can just embed audio/video in your web page without needing JavaScript and it will all Just Work”, right? So what possible reason can the Mozilla folk have for exacerbating this stupidity?

The general argument made by advocates off Ogg/Theora is that it’s Open Source and not subject to patent issues the way MP3 or H264, say, are. But the only reason that Ogg/Theora hasn’t been sued yet is that no-one uses it or cares about it. The GIF lawsuit only occurred when there was a paycheck involved. No-one is going to wake up their legal dream team to sue someone over zero revenue. In any event, calling APIs provided by OS vendors doesn’t expose you to anything. All the graphic rendering in OS X is done via proprietary fonts, using OpenGL and Apple’s implementation of Display Postscript. If you want to stick a pixel on the screen you’re calling OS subroutines that invoke code that infringes on all kinds of possible IP law. It’s. Not. Your. Problem.

Another argument is that Mozilla is trying to Do Good by forcing people away from Evil Proprietary Formats like MP3, AAC, H264, and Flash. But in fact what they’re doing is forcing us to pick an Evil Proprietary Format and Evil Proprietary HTML that will work as well as possible in as many places as possible, and that sure as hell isn’t going to be Ogg/Theora.

If Mozilla would pull its head out of its ass and support H264 then we could use video tags to deal with every platform except (1) Richard Stallman’s crippled netbook and (2) IE. We can support IE by wrapping the H264 in simple HTML which passes it to WMP or hot-swapping an Open Source Flash player into the tags (Flash will still not be open source, but the player can be).

And, in my case, Mozilla is forcing me to stop using Firefox. (Guess what? Webkit’s debugging tools are now ahead of Firefox’s anyway.)

Anyway, I’m now happily using Webkit on my Macs and Chrome under Windows (Chrome is still a bit too crippled on the Mac for me to love it).

Mozilla Firefox UI Fail

OK, I dig that Firefox 3.6 had to imitate Chrome’s UI skin baloney. It’s not Open Source if it won’t let you screw up your UI, right? But — how do I turn the rotten things off? (Edit: it’s buried under Manage Add Ons.) Chrome lets me turn off the skins in the most obvious place, I can’t even figure out where most of Firefox’s preferences have gone — do I need to type in some mystic URL just to unfrack up the UI now?

Chrome is now my default browser for Windows.

Blender 2.5 alpha 0

Sintel early render from Project Durian
Sintel early render from Project Durian

Blender 2.5 Alpha 0 is out and ready for download. The servers seem to be pretty much hammered right now. While the “Alpha 0” part may not inspire a huge amount of confidence, Blender in general is a pretty solid piece of software, so it seems reasonable to expect it not to blow up in your face.

New Features

This is an example of the property browser which is now context-sensitive and sanely organized
This is an example of the property browser which is now context-sensitive and sanely organized
  • Much better UI organization (and appearance). Properties are logically and consistently presented. Lots of context-sensitive controls and functionality.
  • Easy to customize UI on-the-fly (e.g. add commonly used features as buttons to the main tool palette) — although I haven’t figured out the keyboard shortcut customization (or maybe it’s buggy)
  • The spacebar menu now lets you quickly search for commands.
    The spacebar menu now lets you quickly search for commands.

    Much easier to find commands (the “spacebar” menu now lets you search for commands — so you can get to any command by hitting space and then typing the first few letters of its name).

  • Tool buttons have tooltips showing you the tools keyboard shortcut and Python equivalent (unfortunately it looks like it’s the Python equivalent that’s used for mapping keyboard shortcuts, which makes sense from an engineering point of view, but isn’t very user-friendly).
  • Fullscreen mode on Mac
  • Multiple window (and hence monitor) support
  • According to the release notes, there’s also cloth and smoke simulation and improved particles (I’d never used Blender’s particles before and it’s a testament to how much things have improved that I was able to get particles up and running in a few moments without looking at any documentation or tutorials).

My experience of Blender 2.5 thus far (pre-alpha) is that it’s quite stable and a lot more usable. The new version includes a 64-bit OS X version (yay!).