W3C home > Mailing lists > Public > public-html@w3.org > July 2009

Re: Codecs for <video> and <audio>

From: David Singer <singer@apple.com>
Date: Fri, 3 Jul 2009 15:14:19 +0100
Message-Id: <p06240810c673bd96a891@[]>
To: Jonas Sicking <jonas@sicking.cc>, Maciej Stachowiak <mjs@apple.com>
Cc: Doug Schepers <schepers@w3.org>, Joe D Williams <joedwil@earthlink.net>, robert@ocallahan.org, Ian Hickson <ian@hixie.ch>, public-html@w3.org
Trying to catch up on a flurry of messages.

At 15:36  -0700 2/07/09, Jonas Sicking wrote:
>On Thu, Jul 2, 2009 at 3:14 PM, Maciej Stachowiak<mjs@apple.com> wrote:
>>  Note also that besides patent risk, there are issues of coding efficiency,
>>  availability of hardware implementations, and hardware in already shipping
>>  devices.
>I still don't understand the hardware implementations argument. Are
>you arguing that we should use h.264 as base codec despite its patent
>situation? Or are you arguing that we should wait until there is some
>un-encumbered codec with hardware implementations before we have a
>base codec for the web?
>Yes, having hardware implementations would be great, but so would a
>lot of other things that we're dealing without.

We're not the only company shipping portable devices with browsers. 
One of the big advantages of H.264 is that it is broadly implemented 
in a highly competitive market, by chip makers. That's good.

At 0:07  +0000 3/07/09, Ian Hickson wrote:
>Audio codecs really weren't part of my consideration; I removed audio
>codecs section just for consistency and because in the big picture it
>doesn't make any sense to have just that section if we don't have the
>others (since as far as I'm aware, all the codecs that we could put in
>this section -- namely just Wave PCM -- are being implemented by everyone

I think the audio codec has similar encumbrance questions, but indeed 
the hardware requirement is less stringent.

At 20:03  -0700 2/07/09, Jonas Sicking wrote:
>For Apple (and I imagine other vendors), ability to deliver a
>  > high-quality experience on mobile devices at reasonable cost is a high
>>  priority. Even considering the goals of the W3C as a whole, I don't see a
>>  principled reason to override either of these requirements.
>It can only be satisfied if you seriously consider H.264 as a
>candidate for a baseline codec. Is Apple really proposing that? I had
>assumed not given that Apple was a very strong proponent of the
>current RF license policy that W3C uses.

No, not unless we can see how to get a reasonable licensing position, 
and therefore we would not propose over-riding the w3c patent policy 
at this time.

>I can understand Apple wanting to support H.264 in addition to Theora,
>but that doesn't preclude making Theora a baseline codec.

Not with you.  Are you saying that we could write "UAs must support 
one of {H.264, Theora} in addition to AVI/PCM/Motion-JPEG, and 
authors should either use the latter, or offer content in both of the 
former, for interoperability"?  It gets UAs off the hook at the 
expense of requiring authors to encode H.264, which some have 
complained about.

At 20:56  -0700 2/07/09, Jonas Sicking wrote:
>How is Apple working to change the landscape?

I have spent many, many hours on this issue, internally at Apple, and 
with others both formally and informally.  Obviously, we don't yet 
have a solution, or I would have told everyone about it.  I'm sorry 
my struggles aren't public, but I don't think it's reasonable to 
insist that they are (indeed, if you insist all my work on this be in 
the open, the amount I would do would sharply reduce).  I know, this 
sounds like "trust me", and you don't.  I'm sorry, I am doing the 
best I can, and I can only say I share your frustration.

>First of all putting theora as a baseline in the spec isn't forcing
>anyone to do anything.

How does a mandatory requirement to implement avoid force?  You baffle me.

David Singer
Multimedia Standards, Apple Inc.
Received on Friday, 3 July 2009 14:15:35 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:50 UTC