Re: Codecs for <video> and <audio>

On Thu, 2 Jul 2009, Doug Schepers wrote:
> > 
> > In any case, they were not a relevant factor in my removing the 
> > requirement; apparently mentioning it merely confused matters, for 
> > which I apologise.
> 
> I find that a bit hard to swallow, since you've repeatedly stated that 
> the willingness of browsers to implement a features is one of your 
> primary factors in deciding whether or not to include something in the 
> spec.  Therefore, I have to conclude that it was a factor in removing 
> the requirement.

Ok.


> I won't ask you to reveal private information, but if you don't, you 
> also shouldn't make decisions based on it.

At least in this instance, I did not.


> > Wave PCM support is hardly a crucial issue, especially given that 
> > every browser vendor I'm aware of is intendeding to ship support for 
> > it.
> 
> Not crucial by itself, no.  As part of a larger decision to remove all 
> mandated codecs from the HTML5 spec, a link in a critical chain.

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).


> > I do think it would be useful to document the formats, codecs, and 
> > standards supported by all browsers, including things like PNG or Wave 
> > PCM, and including being specific about what versions or profiles of 
> > various specs are supported (e.g. the specific sampling frequencies of 
> > PCM). I don't think HTML5 is a particularly suitable place for such 
> > documentation, though.
> 
> I'd be fine with having that stuff documented in another spec (and would 
> even help shepard that along), so long as it is normatively referenced 
> by HTML (and SVG).

I'd be fine with that (though it would be unusual -- e.g. the CSS 
equivalents "snapshots" aren't referenced by other CSS modules [1]).

[1] http://www.w3.org/TR/css-beijing/


> However, in reality this presents a thorny problem, because RF licenses 
> only apply to the spec that the patent holder agrees to.  Therefore, to 
> actually gain RF commitment, we would have to get the relevant patent 
> holders to agree to a generic media spec that can be implemented by 
> anyone who normatively references it, which is unlikely to fly.

I don't understand the relevance of this. Surely all the specs such a 
profile would reference would themselves be RF?


> Thus, these formats and codecs *do* need to be in the HTML5 spec if it 
> is going to be a truly open standard, and not just a banner of 
> convenience.

Really? That's news to me. Could you elaborate on this? How would 
referencing another spec affect this? Or do you mean we'd have to include 
the entire Theora spec in HTML5? I don't follow.


On Fri, 3 Jul 2009, Robert O'Callahan wrote:
> 
> One problem with taking private feedback into account is that clearly 
> some of that feedback is completely bizarre and inexplicable.

Yup. In this instance the feedback had no effect on the spec and the 
relevant vendors were convinced to implement Wave PCM regardless of their 
opinion, so that's moot. I'm starting to really regret mentioning this at 
all...


> "The first to present his case seems right, till another comes forward 
> and questions him."

The first to present his case in this case was told he was wrong and was 
turned away, so...


> It's fine for people to send you private feedback, but taking it into 
> account when editing the spec is irresponsible.

So if you ever point out a typo to me over lunch, I can't fix it? :-)


> > I really don't see much value in mentioning Wave PCM when we don't 
> > require any other codecs, image formats, etc.
> 
> The spec should require other codecs and image formats.

This would be pretty unusual for W3C specs. Why the change?


> > I do think it would be useful to document the formats, codecs, and 
> > standards supported by all browsers, including things like PNG or Wave 
> > PCM, and including being specific about what versions or profiles of 
> > various specs are supported (e.g. the specific sampling frequencies of 
> > PCM). I don't think HTML5 is a particularly suitable place for such 
> > documentation, though.
> 
> HTML5 is a natural place for this, since authors using <img> or <video> 
> will be looking there already.

Surely PNG support applies to SVG and CSS just as much, and XMLHttpRequest 
would need HTTP support as much (or as little!) as HTML, and so on. I 
don't see why this is HTML5-specific.


> 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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 3 July 2009 00:07:45 UTC