Dave Singer wrote:
At 9:48 +0100 28/03/07, Gervase Markham wrote:
Dave Singer wrote:
Yes. I re-iterate; we have nothing aganist the Ogg or Theora
codecs; we just don't have a commercial reason to implement them,
and we'd rather not have the HTML spec. try to force the issue. It
just gets ugly (like the 3G exception).
But that's circular reasoning. "We don't have a commercial reason to
implement Ogg or Theora, and so we'd rather not have the HTML spec
give us a commercial reason."
No, writing it into the HTML specification is not a commercial reason.
Assuming you have commercial reasons for supporting HTML 5 (which I
suspect you do, otherwise you wouldn't be here) then having Ogg
specified gives you a commercial reason to support it.
If that's not a commercial reason, then what would be a commercial
reason? If everyone else implemented it?
That's an attempt to force the issue by fiat.
But any specification for anything could be described as "an attempt to
force the issue by fiat". That' just loaded language.
Why don't we all just go away and implement what we think is best for
HTML 5, and then put a spec together after the fact? Then we wouldn't be
forcing any issues, and there would be no "fiat". But we all know how
well this approach to standards works.
No matter what the spec. says, if broad support became a reality, then
yes, it may be in our commercial interests.
So Apple's strategy is to wait and see what codec everyone else
implements, and then implement that one?
And at that point there
would be many companies using the codec in a money-making way, with
'pockets', and we'd be clearer about the likelihood of IPR challenges.
There are plenty of such companies already, as another poster has
pointed out.
If you have nothing against Ogg or Theora, and your "interest in
multi-vendor multimedia standards is deep and long-lasting,
interoperable, and very open", and other parties have said that a
baseline codec for video needs to be open and (as far as can be
discerned) patent and royalty-free, then surely your position must one
one of the following:
- You don't actually want a baseline codec in the spec - i.e. you
don't actually have a commitment to interoperability
we have a strong commitment to interoperability in each spec. on its own
right
So what is your plan for promoting interoperability among
implementations of <video>?
- You do want a baseline codec in the spec, but you are happy for it
to be someone other people can't implement - i.e. you don't actually
have a commitment to multi-vendor multimedia standards
anyone *can* implement the codecs we implement; they may choose not to,
for commercial reasons (e.g. they don't like the license)
Oh c'mon, that's a ridiculous definition of the word "can". How exactly
"can" the KDE project implement a codec in Konqueror which requires
royalties? How "can" the Mozilla project implement such a codec without
removing the redistributability of Firefox?
Yes, browsers "can" implement such codecs if they stop being open source
and freely redistributable. Just as the W3C "can" have lots of cool
ideas in their specs if they changed the patent policy to not require
royalty-free licences. But most people wouldn't accept that as a
reasonable definition of "can".
Until someone starts using the Ogg family to make money, and in such a
way that any possible IPR owners consider it in their business interests
to start enforcing their IPR, the situation remains in question. We
have nothing against these codecs, but we are not currently feeling like
being the guinea-pig...
Other posters have commented on this better than I.
- we'd an HTML specification which is clear and interoperable on the
HTML level, and is in a similar position to the img tag on what may be
embedded (it mentions only examples)
As another example of specifications requiring support for other
specifications, SVG viewers are required to support both JPEG and PNG:
http://www.w3.org/TR/SVG11/conform.html#ConformingSVGViewers
And I haven't seen anyone writing standards like "Yes, we support SVG,
but not the bit which says we need to support JPEG and PNG".
Gerv
