Re: Codecs for <video> and <audio>

Hi, Ian-

Ian Hickson wrote (on 7/3/09 2:34 AM):
> On Thu, 2 Jul 2009, Doug Schepers wrote:
>>  Ian Hickson wrote (on 7/2/09 8:07 PM):
>>  >
>>  >  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 anyway).
>>
>>  Not to be too facetious, but that's a bit like not including the<a>
>>  element because browsers will support it anyway.  One of the things I
>>  most admire about HTML5 is that, for all its flaws, it at least set out
>>  to document what browsers actually do.  Please don't make an exception
>>  in this critical instance.
>
> The difference is that<a>  is actually part of the language, whereas Wave
> PCM is another language that this language can refer to.

Sure, there's a difference... but not an effective one when it comes to 
authoring.  You've gone to great lengths to redefine things like URLs 
and HTTP in order to make sure you documented precise browser behavior. 
  If you go to that level of precision for the value of <a @href>, it 
seems pragmatic to go into similar detail for <img @src>.


>>  >  This would be pretty unusual for W3C specs. Why the change?
>>
>>  Hardly unprecedented. [...] SMIL 3.0 [...] suggests that "audio/AAC" and
>>  "video/H264" also be supported.
>
> (Really? Doesn't that violate the W3C's RF guidelines? That's what I
> thought one of the objections against H.264 in HTML5 was.)

I don't see how.  The spec doesn't require it, it merely suggests:
[[
While many SMIL user agents support speciality media types for streaming 
audio and video content, SMIL user agent developers are also encouraged 
to support the following non-royalty-free media formats to further 
interoperability of SMIL content:

     * audio/AAC (reference to follow)
     * video/H264 (reference to follow)

Since both of these technologies are not freely available to user agent 
developers, the actual availability will remain player dependent.
]]

That passage makes it clear that that those codecs are not RF, and 
explicitly doesn't make any conformance statement about them.  That 
would have been obvious had you followed the link I provided.

My point was that, contrary to your claim, it's fairly normal for W3C 
specs to discuss codecs and formats in the interest of interoperability, 
and I think it's entirely appropriate that HTML5 do so as well.


>>  So, I'd expect at least as much from HTML5.
>
> If people think that HTML5 should list a set of technologies that must be
> implemented by implementations of HTML5, I don't mind adding such a list.
> Coming up with the list seems like a can of worms. Would anyone like to
> take an action item to discuss with the relevant implementors of each
> relevant conformance class what the requirements should be, and report
> back to the group?

That seems less efficient than the implementers simply stating as much 
on this list themselves.  I'm happy to help in this, if I can, as W3C 
Team.  I expect that Philippe Le Hegaret might have more information, 
when he gets back from vacation in August.

But to be honest, I'd much rather this were developed in the open, as 
part of the normal operations of this working group.  That is what this 
group is for, right?  I don't think we need to create a bottleneck by 
putting a single person in the critical path, nor shilly–shally 
establishing a subcommittee to discuss it.  Let's simply hash it out 
here on this list.


>If there is are prepared lists for the various relevant
> conformance classes that the relevant implementors agree on, I'd be happy
> to add it to the spec.

Glad to hear it.


> (Given my experience trying to get browser vendors to agree on a video
> codec and a font format, I don't really want to try my luck with another
> set of formats myself.)

I appreciate your feeling the responsibility to have tried, but that's 
beyond the responsibilities of an editor.  This is something for the 
group to work on collectively and decide upon.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Friday, 3 July 2009 07:51:37 UTC