5 Reasons Why Google’s WebM Video Codec Will Fail

At Google I/O last week, Google announced that it would be open sourcing what it calls the WebM video codec. Immediately, there was talk about this “open” codec becoming the video format of the web, with browsers like Firefox and Opera jumping on the bandwagon as fast as they could. While I think that it is great to have an open codec, not encumbered by patents, and that anyone can produce and consume freely, I also think that we are already so entrenched with h.264 video that it will be almost impossible to just “switch” to this new codec. Here is why all of the hype around this codec is unfounded:

1. h.264 is already available nearly everywhere – h.264 video is viewable on nearly all devices. It is available on both Mac and Windows computers with no installation necessary, on nearly every mobile device including the iPhone, iPad, and even Android devices. This ubiquity will make it hard to compete with.
2. Lack of hardware decoders – there are hardware decoders for h.264 video in almost every mobile device, and even some laptops and desktops. This makes decoding h.264 video very fast, and uses less CPU cycles than a software decoder would, while raising the battery life considerably. The reason that you can watch a movie for 10 hours straight on an iPad is because the hardware decoder for the h.264 video uses very little power. So why can’t these devices just add a WebM hardware decoder? First of all such a chip doesn’t exist yet, but more importantly, there probably isn’t the room for two decoders in today’s already cramped devices. For instance, all of the video in Apple’s iTunes store is encoded using h.264, and thus they need the h.264 decoding chips in their devices. They are not going to add a second chip just unless several major content producers switch their videos to WebM with no h.264 fallback.
3. Lack of encoders – applications that produce video content do not export WebM video, but they do export h.264. This can be consumer grade applications like iMovie or Windows Movie Maker, or professional applications like Final Cut. Of course, you can get a converter, but that adds an additional step that, depending on how long your video is, could take a long time (video conversions are slow). Also, depending on browser support, they may need to produce a WebM version, an h.264 version, as well as a Flash version. I don’t think that content producers are going to want to do this, just so that their videos can be in an “open” format.
4. Patents – Apple and Microsoft both have patents in h.264 video, and they probably don’t want to lose their investment to an open source codec. In the case of Apple, they also have millions of videos that they sell in the h.264 format. They aren’t just going to convert it to WebM overnight.
5. Content producers will not want to switch – content producers have just begun switching to h.264 and away from Flash so that they can gain support on mobile devices that don’t support Flash, like the iPhone. They won’t want to switch video formats yet again. There isn’t a compelling reason for them to switch – h.264 is supported everywhere, and where it isn’t (like Firefox) they can provide Flash fallback (which plays h.264). One format everywhere.

Question of Openness

While Google touts WebM as “open for anyone to implement and improve,” h.264 is open as well – it just isn’t free. According to Engadget:

Although H.264 is an open standard, in that it was developed by a consortium of companies and anyone can make and sell an encoder or decoder, it’s not free — you’ve got to pay for a royalty fee to use it, and the rates are set by the MPEG-LA, which collects payments and distributes them to its members.

It seems to me that whenever something is touted as “open,” it immediately gets all sorts of hype. Open has become a buzzword like Ajax was a few years ago. It seems that everything open is automatically “better,” and I think that this is wrong. I think that instead of assuming the superiority of an “open” product, we should instead be treating it like any other product, letting the best format win. Mozilla doesn’t really have to pay the royalties for including h.264 support in Firefox because they could just as easily shell out this task to the operating system, which already supports the playback of h.264 video and pays the royalties. While I understand the concerns that Mozilla has with using a closed video format, I don’t think that this should stop them from using the defacto standard for video that h.264 has become.

Bottom Line

Big companies have a lot of money in h.264 video which is already ubiquitously available, easy to encode, and fast to decode with low powered hardware decoders. Content producers have already invested time and money in switching away from Flash to h.264 and will not want to invest more time and money in order to switch to WebM. h.264 has become the defacto standard for video, and I just don’t see this changing overnight. This is why I think that the WebM video codec, as much as it is hyped, will fail.

 

Quickly Make Any Page Print Nicely (with The Printliminator)

This is a repost from CSS-Tricks, where I have been working with Chris Coyier to create The Printliminator.

I had this idea when I was at a lyrics site trying to print out some lyrics. The page didn’t have a good print stylesheet and was full of all kinds of crap. I copied the source code and made a local version of the site and dumped some simple jQuery stuff in there to make it so any thing I clicked on was eliminated from the page. Turns out it’s the current version of the DOM that gets sent to the printer, so I could eliminate things at will and have them not print. Cool!

After the idea was in place, I went back and forth with Devon Govett turning it into a more full-featured bookmarklet. The current iteration has click-to-remove elements, with a really cool feature of option-clicking to remove everything except the selected element. There are more features, and I think the video explains it better than I can with words:

To grab it, head over to the demo page and drag the bookmarklet link into your bookmarks bar. Click it on any page to activate.

 

What Developers Want From CSS3

I was browsing around on http://css-tricks.com/ the other day, and came across a poll asking developers what CSS3 features excited them the most.  The poll had over 4,000 votes on it, and I thought that its results gave a fairly accurate picture.  As we all know, CSS3 has been under development for a long time – since 2005 in fact.  Four years are like a millennium in web terms, and browser developers have been very slow to implement the features.  As a result, web developers have had to resort to crazy hacks, and longer code, in order to accomplish the things that CSS3 would do for us.  I used the data from the results of the poll to create a PDF to help browser developers to prioritize what features they implement first.  You can download it here.

 

Bridging the Gap Between Desktop and Mobile Web Browsers

I have been using my iPod touch a lot more lately to browse the web. Usually, I’ll stumble across a cool web page after checking my Twitter and seeing a link that I want to look at. But, the screen of my iPod is nothing compared to that of my computer, and so I often want to view the page later on a bigger screen. Although I do have the bookmarks on my iPod synced with those on my Mac, I do not plug my iPod into my computer very often. What I usually end up doing, is that instead of bookmarking the page for later, I email a link to myself. This is inefficient because it clogs up my email, which was never intended to be a place to bookmark things in the first place! I call it “bookmarking”, but it may not even be that. I tend to bookmark sites that I know will be useful to me in the future. In many cases I do not know whether or not it will be useful until I view the page on my Mac.

What I think Apple should do, is to make a simple button in MobileSafari, that would send all of my pages that I am currently viewing to my computer so that I can view them there., and vice versa They could go the extra mile and enable syncing of bookmarks and history over their push service, much like email, contacts, and calendars are now. It would be even better if they supported this across multiple browsers and platforms, and did not charge $100 for it like MobileMe.

I would consider ditching MobileSafari if a 3rd party developer implemented this functionality in an iPhone web browser, and had a program for both Mac and Windows that seamlessly did all of this magic! I really think that bridging the gap between the desktop web browsing experience and the web one needs to close, and I think that this would be a good start.

While the App Store is great, I think that it has too many applications in it. As a result, it is hard to find what you are looking for. I may have completely missed a solution that is already out there and working. If I did, please let me know in the comments!