[whatwg] Vorbis in <audio>

[timeless]

On Thu, Jul 16, 2009 at 2:26 PM, David Gerard<dgerard at gmail.com> wrote:
> Let's put it another way. Of the browser vendors here:
>
> * who supports Vorbis as a baseline codec for <audio>?
> * who objects to Vorbis as a baseline codec for <audio>, and why? If
> such language went into the spec, who would just not implement it?

This isn't the way things are done.

I believe, but can not speak for Nokia, that Nokia would not implement
it. As to the why, it's something beyond my abilities to understand,
and it's certainly beyond my paygrade to explain.

Actually forget implement. That's the wrong word.

Let's look at Safari for a moment. Safari for OS X "implemented"
support for pluggable codecs via QT, as such if you have XiphQT on
your system then Safari has "implemented" support for it on that
system.

However, Safari on an iPhone/iPod will not include that support.

If hypothetically speaking Nokia were to ship a browser based on a
browser which had certain things which we didn't believe we could
support, we'd hypothetically disable it. Possibly in favor of
something else, and possibly in favor of nothing.

If hypothetically Nokia were to choose to use Chrome's browser, this
would be equivalent to us not including the H264 implementation they
have if we decided we don't get a license we can use from them. (As it
happens, it's quite likely that Nokia has an H264 license, but I'm
trying to use a hypothetical to describe the landscape.)

Currently, I work for Nokia on Mozilla, so it's more likely that we'd
be using Gecko instead of Chromium as a base. I'm also glad to say
that I've been speaking with someone from Mozilla who is progressing
on a GStreamer backend for Gecko.

Most likely a Gecko we would ship would include that backend, and our
platform would probably include H264. But like Safari on OS X which
uses QT, you can add stuff to GStreamer on our platform.