I’ve no idea how the web video format war will end. My preference is that a free, non-patent encumbered, high-quality video codec will become the standard, and WebM is the best fit for that description. Despite the recent announcement by the MPEG LA, the patent pool which controls licensing of H.264, that it will always be free for ‘video delivered to the internet without charge’, that still doesn’t make it free-as-in-speech, and still not free-as-in-beer for anyone wanting to build a business around video encoding/decoding (which includes, if I’m not mistaken, bundling it with a browser). All that said, my preference is meaningless in the face of so many vested business interests.

But this post isn’t really about that; it’s about clearing up a misconception. One common statement I keep seeing repeated (WebMonkey said this in May, but I’ve seen it even more recently) is that Safari will be the only browser to not support WebM, when even the Internet Explorer team have promised to. That’s not the case. What the IE team said was that they will support WebM (or rather, the VP8 codec) as long as the user has installed the codec on Windows. Safari’s position is identical, they just haven’t publicly stated so.

The current free alternative to H.264, OGG video, is also not supported in Safari — but you can play OGG videos in Safari by downloading and installing the Xiph Quicktime Components. Likewise, Windows Media files are supported through Flip4Mac. WebM can be supported in Safari in the same way, as soon as someone creates a QuickTime plugin (I believe experimental support is in Perian already). This is exactly the same situation as with IE.

Where this doesn’t apply is on mobile devices; many — principal amongst them, the iOS range — don’t allow extra codecs to be installed. However, this is slightly supplemental to my point, which is that both IE and Safari — on desktop — are capable of playing WebM via a plugin. I believe that if people will install the Flash plugin, they will install the WebM plugin — and when we have choice and competition, a true standard can be reached by consensus, rather than financial clout.

Now, there are loads of blog and forum posts which give differing advice on presets and parameters, and I’m no expert — so what I’ll do is just show you two quick ways that worked for me (I have a Samsung Galaxy S).

A couple of things to note: this post refers specifically to video embedded in web pages with the video element, so the other two requirements from my previous blog post still stand; also, the methods shown below should mean your videos play on iOS too, so you don’t have to encode for different platforms.

The first is cross-platform, using Handbrake. What I did with this was to use the iPhone & iPod Touch preset, check the Web Optimized option, and change the Average bitrate option (in the Quality section) to ~1000kbps (you should then save this as a new preset called Android).

You’ll also need to change the size of the output video in the Picture Settings options — I changed mine to 480 wide (keeping the aspect ratio) and they came out really crisp and sharp. You can see the result of that below (if your browser supports it).

The second method is also cross-platform, and uses VLC (I’m using version 1.1.1, not sure if older versions work the same). It involves more set-up the first time around, but will be easier with each subsequent conversion. Update: I was using VLC for Linux, but the OSX version seems to be quite different.

Go to Media > Convert/Save, add the file to be converted, and choose Convert from the selection at the bottom. Name your Destination File [filename].mp4, and from the Profile list choose Video — H.264 + AAC (TS).

Hit the Edit icon next to the list, and go through each tab in turn; in Encapsulation choose MP4/MOV; in Video Codec un-check the Keep original video track box, choose H-264 from the Codec list, empty the Scale field and enter a value in Width (I used 480); in Audio un-check the Keep original audio track box and select MPEG4 Audio (AAC) from the Codec list. Now click Save, and all of these settings will be remembered so you don’t have to enter them again.

With all that done, hit Start to encode your video. You can see the result of the VLC encoding below. Update: This video doesn’t seem to play on iOS.

The third method is the simplest, but works on Mac OSX 10.6 only. Open up your source video in Quicktime, then go to File > Save As. Choose iPhone from the Format selector. You get less control over your output with this — the width is always 480 and the bitrate is calculated automatically — but it works without fuss. The output of this method is shown below.

A slightly more convoluted method is to use DoubleTwist, which performs on-the-fly conversion. Connect your Android device, then transfer your video to it — the optimum parameters will be automatically selected. When complete, copy the file back from the device to your computer. (I haven’t actually tried this myself).

I’ve read that you can use WinFF, although I haven’t been able to make this work so far.

I’ll keep this post updated as I discover different methods, and do feel free to let me know in the comments what works for you.

From what I can tell, there are three requirements for video to work in Android browsers:

1. You must not use the type attribute when calling the video
2. You must manually call the play() method using JavaScript
3. The video must be encoded as .m4v, not .mp4 Update: This is not correct (see below)

Update: This may be a specific encoding issue rather than all .mp4s; some .mp4 videos seem to play with no problems, others do not. Further update: The video type was a red herring; see my follow-up post, Encoding Video for Android, for more about this.

You can see this working in the demo attached to an older post of mine: Demo: HTML5 Video Controls With JavaScript. This works, AFAIK, in Android, iPhone and all video-enabled desktop browsers. The markup I’ve used is:

<video id="video" autobuffer height="240" width="360">
<source src="BigBuck.m4v">
<source src="BigBuck.webm" type="video/webm">
<source src="BigBuck.theora.ogv" type="video/ogg">
</video>

The first source element calls the video in .m4v format, without specifying the MIME type in the type attribute; I’ve tried both video/mp4 and video/x-m4v, and neither works. Omitting the type attribute altogether lets the video play, and seems to have no ill-effect on other browsers which play the .m4v file.

In order to play the video in Android, I also have an event listener in the JavaScript which plays the video when the element is clicked on, somewhat like this:

var video = document.getElementById('video');
video.addEventListener('click',function(){
  video.play();
},false);

I tested this on my own phone and an HTC Desire, and it works just fine on both. Hope this is of help to someone.

* It’s a Samsung Galaxy S, and I’m delighted by it.

• An introduction to Opera Unite (Dev.Opera)
• With Unite, Opera 10 becomes both a browser and a content server (Download Squad)
• Host Your Own Facebook With Opera Unite (Webmonkey)
• Opera Unite Seeks to Decentralize the Web (SitePoint)

I think there are a number of potential problems of practicality with that approach, many of which have been raised in the comments. As a contribution to the debate, I would like to offer the following suggestion:

What if the font vendor were to supply an authorisation code when selling a font licensed for online use, which the user were then obliged to use inside the @font-face rule in any CSS file which called the font in question; perhaps like so:

@font-face {
font-family: MyFont;
src: url('myfont.otf');
/* License: XXX-123 */
}

This would make it easier for font vendors to crawl websites looking for instances of their fonts, and checking to see if there were a valid license issued for its use on that particular site. This could involve website makers hosting a file somewhere with details of all the sites they manage, to which the vendor could cross-reference.

Of course this wouldn’t stop font piracy, and it wouldn’t be effective against users stealing fonts for use in offline media. But it would allow vendors an easy method of checking that fonts used online were used legally, at least removing that burden from them.

Worth discussing?

Luckily there are a few tools out there which will help you show off the benefits of using Microformats, and involve little work from you.

King amongst tools, of course, is Operator, an add-on for Firefox which finds data in pages and presents you with options to transform them using a series of web-based tools. If the person you’re trying to convince doesn’t use Firefox and/or have Operator installed, however, there are a few good tools available online to show their potential.

hAtom is a microformat used for marking up blog posts or other serialised content. Using the Optimus tool you can turn any page marked up with hAtom into an RSS feed, by adding a link on your page in the following format:

http://microformatique.com/optimus/
?uri=http://www.example.com/&format=RSS

Optimus will return correctly formatted XML for users to subscribe to. It’s also a decent validator for other Microformats (although actually seems to struggle a little with hAtom in that department).

hCard is the standard for marking up contact details, and there is a tool from Brian Suda which will convert them into vCards for you; Technorati also have a test implementation of this tool available, which I’ll link to as they no doubt have better servers. To extract vCards from a page which has hCard markup, simply create a link in this format:

http://feeds.technorati.com/contacts/http://www.example.com/

You can then either save the generated vCard, or add it directly to your address book.

Also from Brian Suda / Technorati comes the hCalendar tool, which transforms your data into the iCalendar standard. Again, you just link to your marked-up page using a specially formatted URL, although this time you get two choices;

http://feeds.technorati.com/events/http://www.example.com/

… returns a single .ics file with each of your events to add to a calendar; while:

webcal://feeds.technorati.com/events/http://www.example.com/

… produces a webcal feed which is updated regularly, allowing subscription to your events.

Implement these tools on your web pages and you’ll have a suite of neat features you can impress your visitors and peers with. It’s a real advantage of using Microformats.

One thing that’s certain is that we’ll see a new layout engine, which is more compliant with CSS 2.1. Does this mean it will pass the Acid 2 test? Will any of the newer stable CSS features from the 2007 snapshot make it in? Who knows. We have been warned that we will have to opt-in to standards mode, however, although it’s not been made clear yet just how this opt-in will work (I thought that writing standards-compliant HTML meant I was opting in to standards mode, but apparently I’m wrong).

Microsoft (and their commercial competitors) have indicated the way they want the web to develop; based around proprietary technologies. For this reason, Silverlight integration will be a big push for them in the next release, and competing standards will probably not receive the same priority. At last year’s Mix 06 event SVG was mentioned in a presentation about standards support in IE, and IE’s Chris Wilson has said that he ‘expects they will add support for it in the future’. That’s about as non-committal as it comes.

Recently there has been debate about introducing ES4 (‘Javascript 2′) to browsers; Microsoft seem to be against it, Mozilla are for it. Whatever develops further from this, I don’t believe it will impact the next release of IE.

What version of JavaScript they do launch with (Firefox 3 will have version 1.7) remains to be seen, but the rise of AJAX and web apps will be well catered for. As with Firefox 3 (and Google Gears), offline storage for online apps will be provided.

Away from the layout and DOM engine, the browser itself will have a limited API for adding extensions, and it seems that the RSS capabilities are to be heavily beefed up.

Web developers are pushing for lots of changes but the Redmond mantra is ‘don’t break the web’, so it’ll be interesting to see the results of that conflict.

With no official word from the team yet, everything I’ve mentioned here is subject to change. If these features do get implemented, however, it would bring IE.Next up to date and able to compete with its peers on the basis of features, not just because it is a default install.

Which makes Mozilla’s latest invention, Prism, seem a bit of a weird step backwards;

Prism is an application that lets users split web applications out of their browser and run them directly on their desktop.

In other words, it puts web pages into a new window, but without the navigation buttons, menu options and address bar. Maybe I’m just a bit of an old traditionalist, but where’s the advantage in this? What reason would I have to run, say, my Gmail in a separate window rather than a tab? The main advantage seems to be that you can run applications from a shortcut in your desktop environment, but you can do that already by dragging and dropping a URL from Firefox.

I don’t know, perhaps it’s not aimed at me; perhaps there are some big enterprises that would find this useful, or people who only ever run a few websites (and really don’t like the address bar). Or, perhaps it’s unfair of me to judge this as it’s only a technology preview at the moment and there are a load of exciting features on their way.

But I’ve read the technical notes and the user experience puff piece, and I can’t get past the fact that it’s just a browser window with no buttons or menus. You know, I’m not saying it’s a bad project; I’m just struggling to see the point of it.

Perhaps there’s a killer app on the way which will make it all clearer.