Re: Codecs for <video> and <audio>

On Jul 2, 2009, at 7:10 PM, Doug Schepers wrote:

> Hi, Maciej-
>
> Maciej Stachowiak wrote (on 7/2/09 9:47 PM):
>>
>> On Jul 2, 2009, at 6:27 PM, Jonas Sicking wrote:
>>
>>> On Thu, Jul 2, 2009 at 4:52 PM, Maciej Stachowiak<mjs@apple.com
>>> <mailto:mjs@apple.com>> wrote:
>>>> - has off-the-shelf decoder hardware chips available
>>>
>>> Given that this is a requirement that simply isn't satisfiable, I
>>> don't think it's a reasonable requirement.
>>
>> There are audio and video codecs that have off-the-shelf decoder
>> hardware available, so the requirement is definitely possible to
>> satisfy.
>
> It's definitely possible.  Is it desirable?  Only if there is a RF  
> video codec that also happens to have hardware support.
>
> There are two orthogonal goals here: interoperability and  
> performance. The spec must meet the first, and should meet the second.

Basically you're saying that "no known royalty-bearing patents" is  
more important to you than the other requirements, but I don't think  
it follows that it should be the only requirement taken seriously.


> FWIW, whatever the codec HTML5 ends up mandating, I would be very  
> surprised if hardware vendors failed to step up in quick order to  
> provide hardware support for that codec.

One point to note is that the hardware support and patent risk issues  
interact. There's a lot more patent exposure to shipping something in  
hardware than in software, because you can't just patch around it to  
avoid further infringement, you have to recall the hardware in  
question. Another thing to note is that there is quite a long pipeline  
from someone asking for an Ogg Theora ASIC to that ASIC being produced  
in volume, incorporated in a design, and shipped to users in actual  
devices - a considerably longer and more expensive timeline than for  
software.


>> As it happens, I don't think any video codec satisfying this
>> requirement also satisfies all the other requirements. I don't see  
>> why
>> this is the requirement that should be dropped.
>
> Was there a typo in here?  If this is the lone requirement that  
> cannot be met, then it does follow that it's more expendable.

I don't know of any codec that meets the other three requirements but  
not this one. As far as I can tell, of the four stated requirements,  
Ogg Thora only satisfies "is implementable without cost and  
distributable by anyone". I think H.264 satisfies all the requirements  
except that one. So if we were to take your principle that the one  
requirement that can't be met should be dropped, that would argue in  
favor of dropping the royalty-free requirement. But I don't think that  
argument is reasonable.

>
>
>> I understand that it's
>> less important to Mozilla than some of the other requirements, so  
>> that
>> Mozilla is willing to go with a codec that doesn't satisfy it. But  
>> for
>> other parties this requirement represents large amounts of money at
>> stake. For Mozilla, enabling royalty-free downstream distribution of
>> Firefox and guaranteeing royalty-free authorability of Web content  
>> are
>> important priorities. I believe these are the primary reasons H.264  
>> is a
>> nonstarter for Mozilla currently. 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.
>
> I might be misunderstanding you.  Obviously, mandating inclusion of  
> Ogg Theora/OMS Video/Dirac/whatever does not preclude you also  
> including an additional codec, say, H.264 that you find gives a  
> better mobile experience.  It doesn't follow that mandating support  
> for one codec that might not have hardware support means not  
> supporting a codec that does.  The iPhone, at least, has a fair bit  
> of storage that could accommodate both codecs.
>
> So, I'm left wondering what your argument here is.

If all or a significant proportion of Web video goes Ogg-only, it will  
deliver a second-rate experience on mobile devices for the foreseeable  
future. Lack of hardware support means that this is not an easily  
solvable problem.

Regards,
Maciej

Received on Friday, 3 July 2009 02:24:45 UTC