Archive for May 27th, 2010

Why HTML5&Co are better for browsers, and what is still missing

It seems that WebM captured the interest of many that were looking for a potential escape from the HTML5 video deadlock (h264 or theora); Google managed to create a potentially suitable alternative, that seems to be relatively risk-free in terms of patents, while providing reasonable overall quality (especially for the HD video range; at lower bitrate and resolution still needs substantial work). This reignited the flash/html5 war, spurred by Apple and its ban of everything Flash or Flash-like. I have read lots of comments ranging from the “flash will be with us forever” to “flash is already dead”. The dichotomy presented is false, for several reasons; I will try to highlight a few of the comments I received, along with my thoughts:

Flash player is on 98% of the internet-connected devices. While this may be true (I doubt it, as most smartphones are actually internet-connected, and Flash does not work there, or is such a sad joke that it should be left for when the kids are asleep), it does not work on the majority of new internet devices, that are either pads, ARM-based devices or systems where Flash has not a good enough performance. Google recently mentioned that they activate 100000 Android devices per day, Apple is more or less in the same range, and there is still no Flash there (t will be – but I still suspect that the experience will not be that good to make it usable). The Flash player is still slow and complex, and unless the technology changes radically, I suspect that it will be still quite slow (unless for single-window, tailored small games as Kongregate demonstrated recently).

Video is the only important thing. Actually, video is important, but Flash is much more than video. While HTML5 allows for some simple games to be created entirely in the browser, going much farther than PacMan is still difficult.HTML%, Canvas, WebGL, Javascript and much more need to go beyond what they provide today; the road seem to go there, but is not there yet.

Video is important, and H264 is the best thing that we have. H264 is a very good standard, and properly implemented (as an example, within the x264 encoder) is really among the state of the art. But – a small and unscientific comparison I performed yesterday seem to indicate that actually WebM is fast and simple, as previous claim by On2 indicated. The simplicity of the transforms and the linear structure should lend well to an embedded implementation, that is actually just a specialized coding on a collection of onboard DSPs.

Flash works well enough right now. Actually, no. The player duplicates most of what is already present within a modern browser: it comes with its own language (quite similar to JavaScript, actually), its own Just-in-Time compiler, its own widgets and interaction tools, its own video and canvas implementation, and moving/activating objects between the Flash boundary and the browser is akin to pull concrete blocks through a straw. Not only the replication of functionality prevents any optimization, but the presence of what is essentially an alien object with its own activity loop creates an endless string of difficulties whenever you need to integrate non-trivial multimedia content with non-flash objects. In fact, one of the reason for pushing open video within HTML5 is to have a much better user experience with lower CPU and resource usage; and as soon as YouTube forces people to use a WebM enabled browser to experience it better, you will see a much quicker adoption.

Most of the missing things are already being worked on, both in the JavaScript engines, within subprojects like Websockets, packages (be it Google-style packages for the web store, or Jar-like packages), video, audio and much more. There is one thing that is missing, and that will be probably be introduced soon: DRM. I know – DRM is a useless gimmick, that up to now has not demonstrated any capability to hinder unlicensed copying, and on the contrary seem to be quite effective at pissing people off.

The reality is that most content providers are requiring a form of DRM – be it effective or not – because this way they have a legal way to ask damages, using the DMCA or similar legislation that were introduced around the world. Yes, most current DRM schemes are not designed to be effective, but to provide a legal instrument. That’s why some video vendors insist that HTML5 is not suited for video distribution: because it does not have a protection form, that (even if easily avoidable) provides a tool to ask for damages and external authority control. I am quite confident that sooner or later, someone will introduce a DRM option to provide optional content protection; at that point, Flash or Silverlight will provide no substantial technical or business advantage, and will be on the contrary disadvantages, especially in up-and-coming platforms.