Posts Tagged‘codec’


YouTube Now HTML5 by Default*.

Flash, after starting out its life as one of the bevy of animation plugins for browsers back in the day. has become synonymous with online video. It’s also got a rather terrible reputation for using an inordinate amount of system resources to accomplish this feat, something which hasn’t gone away even in the latest versions. Indeed even my media PC, which has a graphics card with accelerated video decoding, struggles with Flash, it’s unoptimized format monopolizing every skerrick of resources for itself. HTML5 sought to solve this problem by making video a part of the base HTML specification which, everyone had hoped, would see an end to proprietary plug-ins and the woes they brought with them. However the road to getting that standard widely adopted hasn’t been an easy one as YouTube’s 4 year road to making HTML5 the default shows.


Google had always been on the “let’s use an open standard” bandwagon when it came to HTML5 video which was at odds with other members of the HTML5 board who wanted to use something that, whilst being more ubiquitous, was a proprietary codec. This, unfortunately, led to a deadlock within the committee with none of them being able to agree on a default standard. Despite what YouTube’s move to HTML5 would indicate there is still no defined standard for which codec to use for HTML5 video, meaning that there’s no way to guarantee that a video you’ve encoded in one way will be viewable by HTML5 compliant browsers. Essentially it looks like a format war is about to begin where the wider world will decide the champion and the HTML5 committee will just have to play catch up.

YouTube has unsurprisingly decided to go for Google’s VP9 codec for their HTML5 videos, a standard which they fully control. Whilst they’ve had HTML5 video available for some time now as an option it never enjoyed the widespread support required in order for them to make it the default. It seems now they’ve got buy in from most of the major browser vendors in order to be able to make the switch so people running Safari 8, IE 11, Chrome and  (beta) Firefox will be given the Flash free experience. This has the potential to set up VP9 as the de facto codec for HTML5 although I highly doubt it’ll be officially crowned anytime soon.

Google has also been hard at work ensuring that VP9 enjoys wide support across platforms as there are already several major chip producers whose System on a Chip (SoC) already supports the codec. Without that the mobile experience of VP9 encoded videos would likely be extremely poor, hindering adoption substantially.

Whilst a codec that’s almost entirely under the control of Google might not have been the ideal solution that the Open Source evangelists were hoping for (although it seems pretty open to me) it’s probably the best solution we were going to get. I have not heard of the other competing standards, apart from H.264, having such widespread support as Google’s VP9 does now. It’s likely that the next few years will see many people adopting a couple standards whilst the consumers duke it out in the next format war with the victor not clear until it’s been over for a couple years. For me though I’m glad it’s happened and hopefully soon we can do away with the system hog that Flash is.

HTML5, Video and The War For Web Standards.

Whenever I find myself in the depths of coding for a mobile handset or browser HTML5 always seems to be the panacea to all my problems. Its promises of cross platform compatibility and ability to leverage the vast amount of work already done with Javascript has seen me lose several weeks of productivity in the hopes of forgoing much more work later on.  It always ends the same way with me getting some rudimentary functionality working before trying it in a different browser and seeing all my work fall in a screaming heap, forcing me to do the work I had so aptly delayed. The source of this problem is that whilst HTML5 may one day be the norm for how web pages are done on the Internet it is still a work in progress and the implementation of the standards vary from browser to browser.

This lack of standard implementation across the browser market is just another form of a format war. Whilst they might all appear to be collaborating on the future of the web realistically they’re all fighting for their version of the web to become the standard. No longer is a company able to release a product like IE6 onto the market that plays fast and loose with the standards in favour of delivering more functionality as that will more than likely end up being ignored by the web development community. Now the war is mostly being raged through standards committees, but that doesn’t mean the same old strong arming tactics aren’t being used.

Last week Google announced that it would no longer be supporting the H.264 codec for the HTML5 <video> tag. The post triggered wide spread discussion about the future of the HTML5 standard and Google felt the need to clarify its position:

Why is Google supporting WebM for the HTML tag?

This week’s announcement was solely related to the HTML tag, which is part of the emerging set of standards commonly referred to as “HTML5.” We believe there is great promise in the tag and want to see it succeed. As it stands, the organizations involved in defining the HTML video standard are at an impasse. There is no agreement on which video codec should be the baseline standard. Firefox and Opera support the open WebM and Ogg Theora codecs and will not support H.264 due to its licensing requirements; Safari and IE9 support H.264. With this status quo, all publishers and developers using the tag will be forced to support multiple formats.

On the surface it would appear that Google is attempting to use its share of the browser market to put some pressure on the HTML5 standards committee to make WebM or Theora the default codec for <video> tag. For the most part that’s true and should they get their way Google will have control over yet another aspect of the web (in contrast to now when they’re just the dominating player thanks to YouTube). However whilst such a move might at first appear to only benefit Google, Mozilla and Opera I believe that a push away from H.264 is beneficial for everyone on the web, except for Microsoft and Apple.

You see whilst there’s no official agreement on what the default codec should be for HTML5 there are in fact 2 groups within the standards committee that agree wholeheartedly on which one should be the standard. Google, Mozilla and Opera all believe that WebM or Ogg Theora (or both!) should be the default standard whilst Apple and Microsoft both want H.264. The reason behind that is quite obvious when you look at the patent body responsible for licensing the H.264 technology, the MPEG-LA. Both Apple and Microsoft are have patents in the MPEG-LA patent pool meaning they have a vested interest in making it the default standard. This is the main reason why having H.264 as the default is bad Internet users and web standards as it would force anyone who develops HTML5 products using video to license the H.264 codec, something which could be quite devastating to early stage start ups. Additionally it encumbers what should be a completely open and free standard with licensing requirements, something that hasn’t been present in any web standard to date.

Whilst the decision doesn’ affect me directly, no matter which way it goes, I can’t support something that has the potential to stifle innovation like a licensing requirement does. Google throwing its weight behind its own and other open codecs has highlighted the issue succinctly and hopefully this will lead to more productive discussion around which (if any) codec will become the standard for HTML5. We’re still a long way from having a fully formalised version of HTMl5 that anyone can implement but it’s good to see some movement on this front, even if it’s just one web giant poking the trolls.