Saturday, October 24, 2009

On Protocol

At the core of the internet since the foundation of the world wide web has been the hypertext transfer protocol (http). This basically breaks data into small packets, transfers them and then puts them together again. Essentially this is a good way of getting data from one place to the next provided you have a bit of time (okay, perhaps measured in milliseconds, but still, some time..).

But, as more and more system on the internet are working in real time, different protocols are becoming important. One of these is XMPP, a real time XML based messaging protocol that is used by many IM systems and new developments such as Google Wave.

Video has, to date, been shoehorned into very non-video technologies in order to make it work on the internet, and http was one of these. Some specific technologies have helped such as mms and rtmp and various peer-to-peer technologies, but video has worked over the internet largely despite, not because of the technology.

This has resulted in some curious differences in the world of internet TV over broadcast television. In traditional TV video has a timebase made up of fields and frames (2 fields and 25 frames in the PAL standard, for example), but in video you work with ticks based on 1/1,000th of a second, which, in turn, is not necessarily based on real time (Windows Media uses the clock on the sound card of a PC, for example).

But now, more and more video is being delivered over http for a number of reasons:

  • · It gets around firewall issues
  • · It breaks down rather more elegantly than streaming, which is either on or off
  • · It is generally cheaper to serve (only because hosting companies charge more for streaming servers)

However, it does have its issues, including security, efficiency and scalability and more recently adaptive http is gaining ground as a way of mapping data rates according to the bandwidth available.

But more and more of the internet is operating in real time and messaging protocols such as XMPP are becoming more common. It’s not a protocol that will ever be used for delivering video, but as more and more social interacting takes place around video content we’re going to see the rise of this and other technologies.

Perhaps there is a need for a protocol that syncs the delivery of video with these real time systems: for example, to send a bookmark for a video programme from a specific spot in the show. It’s something my colleagues at Vidiactive are working on now.

The place of new standards such as HBBtv, Canvas and HTML5 are yet to be established, but the way http has prevailed despite its seeming unsuitability for the task of delivering video is salutary and shows how difficult it is to get over incumbency in the Web 2.0 world, but we are going to need something more efficient moving forward.