Re: Codecs for <video> and <audio>

Ian Hickson wrote:
> On Fri, 3 Jul 2009, Sam Ruby wrote:
>> Ian Hickson wrote:
>>> On Thu, 2 Jul 2009, Sam Ruby wrote:
>>>> Ian Hickson wrote:
>>>>>> Even if a better place can be found, why not follow your 
>>>>>> previous policy of adding a section to HTML5 and moving it out 
>>>>>> if/when a better venue is found?
>>>>> Because this isn't required for interop, and so it's not critical.
>>>> Required for interop?  I'm confused.
>>> I mean that we don't have to have a spec to get browsers to all 
>>> implement PNG or DOM2 Core. The whole point of the proposed spec would 
>>> have been to document what interop exists, and what interop browser 
>>> vendors predict the next generation will have, so such a spec by 
>>> definition wouldn't be needed for interop. Thus, since we agree that 
>>> on the long term it doesn't belong in HTML5, it doesn't make sense to 
>>> add it to HTML5 just to remove it later. This is unlike other features 
>>> that we added then removed later, which were added because there was 
>>> an immediate need for a spec to obtain interop amongst interested 
>>> implementors.
>> You lost me again, and furthermore you are asserting an agreement on a 
>> topic that I don't recall expressing an opinion on.
>>
>> The original topic was "required for interop".
>>
>> If the goal of HTML 5 is to document what interop exists at this point 
>> in time in 2009, then HTML 5 would have no video tag at all; instead 
>> HTML 5 would document how YouTube currently works.
>>
>> Until other things that are intended to be split out later are, in fact, 
>> split out I don't see any point in discussing further what the final 
>> form of the document will be.
> 
> I don't understand what you are asking. I think we may be speaking at 
> cross-purposes here.

I guess that would depend on what you presume my purpose in asking this 
question is.

Your claim that common codecs aren't required for interop baffles me.  I 
believe that "Because this isn't required for interop" to be a false 
statement.  I very much believe that video is a valuable feature of 
HTML5, but *only* if there is a common, royalty free codec that is 
implemented across compliant implementations.  If that isn't the case, 
then the video element should be deferred (either to HTML6 or by naming 
the next release HTML4.2 or somesuch, I care not).

I further believe that there are multiple axises along which one can 
evaluate a coded for suitability.  I don't believe that the common codec 
needs to be the best along each axis.  In fact, I believe that there is 
plenty of room for non-royalty free codecs which will target specific 
needs.

Furthermore, I recognize that there may be valid business reasons for a 
given vendor to elect to defer, possibly indefinitely, becoming 
compliant with HTML5.

You recently said:

> Assuming that decisions are made based on technical grounds and not based 
> on popularity votes, it shouldn't matter whether a position has one person 
> supporting it or fifteen -- the stronger position should win, regardless 
> of the number of supporters.

You and I see the same data (lack of hardware support, quality-per-bit 
concerns) and yet come to different conclusions.  The current draft 
contains a non-interoperable Video element, whereas I would consider 
either of the following to be significantly stronger positions than the 
one you have elected to take: deferring the inclusion of the element 
entirely or continuing to require a specific royalty free codec.

- Sam Ruby

Received on Saturday, 4 July 2009 11:10:40 UTC