In a somewhat (but not entirely) surprising announcement, Google is removing support for H.264 video from Chrome. This change to their implementation of the often controversial HTML5 <video> tag is both a major step by Google and a furtherance of the already complicated world of video online.
… To that end, we are changing Chrome’s HTML5 support to make it consistent with the codecs already supported by the open Chromium project. Specifically, we are supporting the WebM (VP8) and Theora video codecs, and will consider adding support for other high-quality open codecs in the future. Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies.
When Google released WebM (a royalty-free codec which Google acquired as part of On2), it was clear that the intention was to take on H.264 and with this move there seems little doubt that the gauntlet has been thrown down. Although, now that H.264 has such a strong base (it’s included in Flash, IE9, Safari, Mobile Safari, and Android), it really makes one wonder if Google has picked a fight that has long since been lost.
So why would Google do this?
Here’s my best guess: Money (specifically, patent licensing).
H.264 is heavily encumbered by numerous patents owned by companies like Microsoft, Apple, and Cisco, and controlled by MPEG LA, the consortium charged with turning these patents into profit (here’s the 70 page list of patents for those interested). While I’m sure many people recall that MPEG LA made a very public pledge that H.264 would be free forever, as is often the case, things aren’t quite that simple.
Peter Csathy wrote a fairly detailed post on the matter, pointing out some key details that many in the media skipped. Here’s the core of what wasn’t discussed after the MPEG LA announcement (but should have been):
But, you say, MPEG LA recently announced that it will no longer charge royalties for the use of H.264. Yes, it’s true – MPEG LA recently bowed to mounting pressure from, and press surrounding, WebM and announced something that kind of sounds that way. But, I caution you to read the not-too-fine print. H.264 is royalty-free only in one limited case – for Internet video that is delivered free to end users. Read again: for (1) Internet delivery that is (2) delivered free to end users. In the words of MPEG LA’s own press release, “Products and services other than [those] continue to be royalty-bearing.”
Mike Shaver, Mozilla’s VP of Engineering offer’s a somewhat similar take in “Free as in Smokescreen:”
What MPEG-LA announced is that their current moratorium on charging fees for the transmission of H.264 content, previously extended through 2015 for uses that don’t charge users, is now permanent. You still have to pay for a license for H.264 if you want to make things that create it, consume it, or your business model for distributing it is direct rather than indirect.
What they’ve made permanently free is distribution of content that people have already licensed to encode, and will need a license to decode. This is similar to Nikon announcing that they will not charge you if you put your pictures up on Flickr, or HP promising that they will never charge you additionally if you photocopy something that you printed on a LaserJet.
I’m just waiting for one of the licensors to reinterpret the license and claim that ads constitute a form of payment or some similar excuse to exclude them from the exception they granted. I’ve yet to get my hands on the latest licensing agreement to see exactly what it says about this, but I wouldn’t be surprised at all to see this card played at some point to wring extra revenue from these patents.
Given that Google owns the massive video sharing site YouTube, which uses H.264, plus whatever unknown projects relating to Google TV – it stands to reason that Google would certainly save some money by moving away from such an encumbered technology; not to mention avoid future risk should rules change. Though personally, I also have to wonder if it could be fears of a repeat of the GIF patent debacle.
Now where does this leave us?
Right now HTML5 <video> is a mess, at best. There is a war for which codec becomes the de facto standard, and there is a lot of money at stake depending on who wins. At this point there is no single codec that works across all major browsers; to get full coverage the best option now looks to be a combination of H.264, WebM, and Flash. Doesn’t really sound like the progress that was promised with HTML5 does it?
It’s worth noting though that Google isn’t the first browser developer to reject H.264; both Firefox and Opera have decided against including it in their browsers as well. As painful as the fragmentation is now in regard to who supports what, this move by Google actually does little to change the landscape. Support has been fragmented from the beginning, and all this really does it push H.264 a step away from being the de facto standard; a title that it has been very close to seizing.
Had Firefox added support for H.264, I think the fight would be over and would have made today’s announcement almost suicidal for the project. Though with such a major player holding out against it, Google’s move becomes a minor tactical shift in the short-term (though the long-term impact could be significant).
I could go on for pages about what works are where we are now, but Mark Pilgrim (an infinitely better writer than I) sums it all up here: “Dive into HTML5: Video on the Web” – well worth reading if you want to really understand what’s going on.
So in summary – video needs to be encoded to multiple formats, which today’s announcement does little to alter due to the fragmentation that was already in place. In the long run, WebM may be better for the community due to its license, though many of the internet’s biggest players have a vested interest in H.264. So when you factor in politics and propaganda between competing companies, distrust, and possible patent claims that haven’t been addressed yet; this all leads me to an even simpler summary:
Yesterday, HTML5 <video> was a mess; tomorrow it will still be a mess.
When you move on to your next challenge how will those that inherit your code think of you? Noble or notorious, innovator or insane? This is a question that all developers should ask themselves frequently; though too few ever do. You should always write with the assumption that someday a new developer will take over your code, and they will question every decision and assumption you’ve made. When this happens, what will they think of you?
Perhaps I’m more aware of this because I maintain an internally developed shared library that my company uses in every application; but regardless of the scope of the project you should always assume that someday you will hand the project off. Many developers think little about what happens to their code after it passes on to another; what other developers will have to deal with, or how their efforts will be perceived.
When I’m training a new developer there are a few points I try to reinforce as much as possible:
- Code is only good if other developers can work on it without extensive training. If it takes days or weeks of introduction to get a new developer up to speed, then you’ve done something wrong1.
- Clever solutions are no better than an ugly hack if it’s not clear what you are doing. If the code isn’t clear then it’s not maintainable, if it’s not maintainable then it’s junk.
- Assume you’ll be hit by a bus. Always write code with the assumption that you won’t have the opportunity to cleanly pass the code off to a new maintainer. Never assume that you’ll have time to come back and clean things up later.
- Always perform design reviews, no matter the size of the project2. Once you have a design in mind, talk it through with a at least two other developers. Just because you think it’s clean and clear doesn’t mean that others will see it that way as well.
- Be consistent, always. I’ve seen more projects ruined by people doing things “their way” than anything else. Match style and design when working on an existing project. Be careful when adding new techniques, technologies, or methodologies to an existing project; unless you are willing to update the entire code-base, you can easily create a minefield without realizing it.
If you want your work to be seen positively after you move on, start thinking about your heirs today. The opinion they have of you will be almost entirely based on what they see in your code – not the stories or memories left behind.
1 – There are always exceptions; these are generalized guidelines, not hard and fast rules.
2 – This includes “throw away” projects, many projects that are intended to have a short life end up living far longer than intended. This is the most likely place that your heirs will find code that makes them question the quality of your work.
In December 2002 I made my first purchase from GoDaddy, since then I’ve spent $1,200 with them. Over the years I’ve seen them grow up to be a major force both in the registration and web hosting markets; I’ve also seen them go from lean and efficient to annoying and unfriendly.
Once upon a time GoDaddy had the best prices and the best search of any registrar; unfortunately things often change, and not always for the best. As time went on they added more products and adopted a very “in your face” style of marketing. For years I’ve dismissed the aggressive marketing as the cost of the low prices, but times have changed.
The aggressive marketing style, incredibly difficult to cancel subscriptions, feature lock in, and many other annoyances and issues. And why do I put up with this? It’s not the low prices, as for many things my current hosting company is far cheaper. I’m no longer locked, it’s not that. Loyalty? That it, well, that was it.
After 7 years, and $1,200 – I’ve started moving my domains over to my hosting company; and so far I couldn’t be happier. No aggressive marketing, good service, and they don’t nickel and dime me to death.
Loyalty can be a good thing, but how much is loyalty costing you? Is it worth it?
While trying to renew a few domain names recently, I found that cancelling the Privacy service that GoDaddy offers (via Domains By Proxy) is much more difficult than I had expected. The $8.99/year service conceals your name, address, and phone number from the public WHOIS listing.
Being concerned about privacy as most people are (or at least should be) it seemed a reasonable option but when multiplied by quite a few domains, it gets rather expensive. So during this last round of renewals I decided to cancel the service; figuring it would be no harder than removing the item from the shopping cart. To my surprise, it wasn’t nearly so easy.
Turns out that you have to sign into the DomainsByProxy web site with a Customer ID and password to cancel the service; so I tried the obvious and used my GoDaddy ID and password, though no such luck. I searched my email archives and didn’t find a single email from DomainsByProxy, at this point I was pretty sure whatever email address they had on file wasn’t valid, which is bad news for me. While there is an option to recover your customer ID, if their records aren’t accurate then it’s of no real use.
But there is hope.
It took a fair bit of reading and testing, but I finally found a method to get to your account IDs, and it’s fairly simple:
- Go to the Private Registration Page on GoDaddy’s site (make sure you’re logged in to your GoDaddy account)
- Type in some random characters into the search box
- On the results page, click “Continue to Registration”
- Click “No Thanks” on the ad page
- Scroll down to the section labeled “3. Select Your Domains By Proxy® Account“
You should now see your customer IDs for the DomainsByProxy web site. The web site only shows the first four account IDs, if you have more than that you can contact DomainsByProxy and have them merge the account IDs you know. Just continue the process until you have all of your accounts merged into one.
Unless you’ve changed your password on the DomainsByProxy web site, your GoDaddy password should work. From there, you can update your information – or like me, cancel the service completely. Now you are free to renew the domain without paying the extra annual fee or transfer to another registrar.
I’ve been working on a project recently that uses avatars, while planning out this specific feature it occurred to me – why should we re-invent the wheel? There’s already at least one service that specializes in doing it right: Gravatar.
While building something as simple as avatar support takes a relatively small amount of time, when working against a tight deadline or a tight budget every minute counts. In the world of an ISV (especially a young one) the balance of user satisfaction and development time is critical. Using a service such as Gravatar is a great way to give the users what they want with minimal impact to the timeline.
With a super-simple implementation we were able to get it running within a few minutes – compare that to at least a few hours to build a custom system. Plus, reduced server load as we aren’t hosting the images and a cleaner, simpler interface as it’s one less option the user has to look through.
For those that have been looking forward to seeing the final result of Microsoft’s attempt at AJAX, your wait is over. ASP.NET AJAX 1.0 has been released.
I’ve not had time to test this yet, but it sure looks like it has promise. I’ll be playing with this one soon, I’ve got a couple new projects this might be perfect for.
