By Mark Boas

As one half of the team that produces jPlayer – a JavaScript media library that uses both HTML5 and Flash, this affects me directly. There also seems to be a lot of interest in this subject at an organisation I’ve just started working with. I’m not sure if this heightened my senses to the subject, but over the last day or so I’ve noticed some interesting discussion on Twitter. So I thought it was worthwhile documenting for the next time it crops up.

The first discussion takes place between Mike Shaver (Facebook and ex-Mozilla) and Brendan Eich (CTO of Mozilla and inventor of JavaScript) – I include a portion of it below.

H.264 is a video compression format, which although fairly recently open-sourced – H.264 is ‘patent encumbered’ in other words royalties for its use could be claimed at any time. Currently latest versions of Chrome, Internet Explorer and Safari all
support H.264 but Firefox and Opera do not but support an alternative format known as WebM (as does Chrome). However around 13 months ago Google stated their intention to drop H.264 support from Chrome ‘in the coming months’.

A Flash fallback is used when we detect whether HTML5 or a particular format is supported and fall back to a Flash solution if not. At this point it’s worth mentioning that Mobile Safari does not support Flash. NBD in this case means no big deal (for Chrome). The special Flash deal probably alludes to Chrome and Adobe’s deal to bundle Flash with Chrome and Adobe’s intention to drop support for Flash on Linux for browsers other than Chrome. Note that Adobe plan to not support ‘new mobile device configurations’ going forward.

B2G refers to Boot-2-Gecko a new initiative by Mozilla to create a web-based open source mobile operating system.

Note. Whereas there is more room to maneuver with desktop browsers, with mobile devices, speed and battery life are of prime concern. Since currently most, if not all mobile devices that play video, support H.264 decoding directly via hardware, it would be difficult to enter the market with a mobile OS that didn’t support H.264.

Broadway.js is an open-source library that decodes H.264 in JavaScript by taking advantage of the newer faster JavaScript engines that are built into the latest browsers. This means that in theory a developer can add H.264 playback capability to any modern browser. See also JSMad for MP3 playback and ALAC.js for lossless playback.

I encourage you to expand their tweets to see who else has chimed in. You can see the full discussion here.

WebM vs H.264 Showdown

The second discussion involves David Storey (former Opera Web Evangelist now working for Motorola which has recently been acquired by Google) and Faruk Ateş (‘Entreprenerd’ and former web-standards specialist for Apple). Excerpts follow.

This is the interesting part for me. H.264 and VP8 (the video part of WebM) are both based on Inverse Discrete Cosine Transform for decoding so in theory at least this could happen.

It’s worth pointing out that services exist that will do this for you.
Upload once and have multiple formats available automatically. Vid.ly comes to mind but I’m sure there are others. Although I do think it would be nice to have a package that did something similar which you could install on a server of your choice.

So there you have it, two interesting conversations from around the Twitterverse on web video. I guess time will tell if Google removes support for H.264 from their browsers as they have promised to and whether the VP8 part of WebM can be decoded using the same hardware already in place for decoding H.264. Above all is the future really JavaScript decoders? Could we do this in hardware somehow? Also it seems that H.264 and VP8′s similarities cut both ways, if they really are so similar we could see royalty issues cropping up with VP8 too. The difference being that a large company like Google could intervene to prevent this becoming an issue.

You can view the full discussion here.

Follow me on Twitter at @maboa.