Ajax Girl

We just talked about codecs, and in particular the world of Ogg.

Mozilla came out supporting the format, and saying that we should see it in Firefox 3.1. Niall Kennedy then reminded me of a post, way back in time, by David Singer of Apple discussing the research that Apple did into Ogg:

Preamble

The HTML5 specification contains new elements to allow the embedding
of audio and video, similar to the way that images have historically
been embedded in HTML. In contrast to today’s behavior, using
object, where the behavior can vary based on both the type of the
object and the browser, this allows for consistent attributes, DOM
behavior, accessibility management, and so on. It also can handle
the time-based nature of audio and video in a consistent way.

However, interoperability at the markup level does not ensure
interoperability for the user, unless there are commonly supported
formats for the video and audio encodings, and the file format
wrapper. For images there is no mandated format, but the widely
deployed solutions (PNG, JPEG/JFIF, GIF) mean that interoperability
is, in fact, achieved.

Licensing

The problem is complicated by the IPR situation around audio and
video coding, combined with the W3C patent policy
. “W3C seeks to
issue Recommendations that can be implemented on a Royalty-Free (RF)
basis.” Note that much of the rest of the policy may not apply (as
it concerns the specifications developed at the W3C, not those that
are normatively referenced). However, it’s clear that at least
RF-decode is needed.

The major concerns were:

• a number of large companies are concerned about the possible
  unintended entanglements of the open-source codecs; a ‘deep pockets’
  company deploying them may be subject to risk here;
• the current MPEG codecs are currently licensed on a royalty-bearing basis;
• this is also true of the older MPEG codecs; though their age suggests examining the lifetime of the patents;
• and also SMPTE VC-1
• H.263 and H.261 both have patent declarations at the ITU.
  However, it is probably worth examining the non-assert status of
  these, which parts of the specifications they apply to (e.g. H.263
  baseline or its enhancement annexes), and the age of the patents and
  their potential expiry.
• This probably doesn’t have significant IPR risk, as its wide
  deployment in systems should have exposed any risk by now; but it
  hardly represents competitive compression.
• Most proprietary codecs are licensed for payment, as that is the
  business of the companies who develop them.

So, there was worry. The BBC decided to try to solve this by creating Dirac, but they also just posted on Open Industry Standards For Audio & Video On The Web where they put their money behind H.264 and AAC:

I believe that the time has come for the BBC to start adopting open standards such as H.264 and AAC for our audio and video services on the web. These technologies have matured enough to make them viable alternatives to other solutions.

And then answer the obvious question on Dirac:

Some people may ask: why are you not using your own Dirac codec? I am fully committed to the development and success of Dirac, but for now those efforts are focused on high-end broadcast applications. This autumn, we intend to show the world what can be achieved with these technologies.

Something tells me that 2008 is going to be a fun one wrt the opening of codecs.

Source: Ajaxian » Front Page
Original Article: http://feeds.feedburner.com/~r/ajaxian/~3/363842972/more-codecs-from-apple-bbc