[whatwg] several messages regarding Ogg in HTML5

[Ian Hickson]

I've tried to pick a representative sample of the e-mails sent since my 
last e-mail. The ones I didn't reply to have been saved to the outstanding 
video codec feedback folder, and I'll reply to them once we have a real 
solution to the problem of finding a common codec.

   http://www.whatwg.org/issues/#graphics-video-codec

(The list is updated daily, so it doesn't yet have all the new e-mail.)

I would encourage new participants to read this blog entry from Chris 
Double, the Mozilla engineer who implemented most of <video> in Firefox, 
as it summarises the issues nicely:

   http://www.bluishcoder.co.nz/2007/12/video-element-and-ogg-theora.html

That said:

On Tue, 11 Dec 2007, alex wrote:
>
> But because of the nature of submarine patents, I don't quite see how 
> you can actually find a codec that fits the requirements? You can't use 
> an encumbered codec obviously, and the rest is up for grabs by people 
> who misuse legislation for their own benefit? So what else is there 
> (excepting codecs that are outdated in every way that is)? That said, my 
> vote still lies with ogg.

There are several solutions we might find. For example:

 * We could convince the MPEG-LA group to provide a royalty free license 
   for one of their codecs, e.g. H.264 Baseline.

 * We could wait for Ogg to be used by a large fraction of the Web 
   population, as that would provide the business reason for companies 
   like Apple to support Ogg.

 * We could use an codec old enough that all patents claimed to 
   be essential to its implementation have expired.

The discussions to these ends are happening.


On Tue, 11 Dec 2007, Jeff McAdams wrote:
> 
> Then you need to stop work on a HTML5 spec right now because 
> *EVERYTHING* has a submarine patent risk to it.

It's a matter of risk management. Some things are worth the risk, others 
might not be. Video codecs tend to be _extremely_ risky.


> Apple and Nokia's stated reasons for objecting to Theora are crap...they 
> don't pass the smell test.  Ian, you're being taken for a ride, here.

To be honest at the end of the day it doesn't actually matter _why_ Apple 
and Nokia won't implement Ogg Theora. If they don't implement it, we don't 
have interoperability, and we've failed in our goal.


> Just revert the text and go back to Theora as the codec of choice and 
> end this charade of trying to look like you're taking everyone's 
> concerns into account because its clear that you aren't. Apple and Nokia 
> are, so far, getting their way, despite the huge public outcry that 
> you're seeing, and that should tell you something, and tell you 
> something loud and clear.

Actually, right now _nobody_ is getting their way. The spec doesn't say 
_what_ codec should be used. Requiring Ogg Theora support would be not 
taking everyone's needs into account. Right now, the spec just lists 
everyone's needs, without a solution.


> > In the absence of IP constraints, there are strong technical reasons 
> > to prefer H.264 over Ogg. For a company like Apple, where the MPEG-LA 
> > licensing fee cap for H.264 is easily reached, the technical reasons 
> > are very compelling.
> 
> Except that there are *KNOWN* IP (god how I hate that term) constraints 
> with H.264.

Indeed, H.264 is unacceptable as well.


> At least with Theora we can avoid any known ones.  All codecs have a 
> risk of submarine patents (though with extensive having been done for 
> Theora, at least that risk is lowered, if not eliminated completely), so 
> that argument is a wash, its on both sides of the equation, so it 
> cancels out.

Not for companies that have already taken the risk of one of the codecs 
already. For example, if Opera ships with Ogg Theora, then they'd probably 
be less interested in also supporting Dirac (another theoretically "free" 
video codec), since doing so would increase their potential patent "attack 
surface". (Also, the smaller the company, the less the risk. Companies 
like Microsoft, Apple, and Google take on huge risks. Just look at 
Microsoft's track record recently getting sued for patent infringements, 
or Apple's track record of being sued over patents that the iPhone 
aledgedly infringes.)


> > The problem is that if the big players don't follow the spec, even the 
> > SHOULD requirements, then the spec is basically pointless. What we 
> > want isn't that some people support Ogg, what we fundamentally want is 
> > that _everyone_ support the same codec, whatever that may be.
> 
> Then revert the text and make it a MUST.  As far as I know, there are no 
> other codecs out there that are not encumbered.  This is the whole 
> reason for existence of Theora, at least at the time, and I don't know 
> that this has changed in the few years since it was designed.

There's no point putting a MUST in the spec if we _know_ that it won't be 
followed. We're not writing specs to satisfy a theoretical need, we're 
trying to get actual interoperability across all browsers.


> If you want a baseline that everyone can implement without being 
> encumbered, then the answer is Theora.

We have been told that Theora is not something everyone can implement. 
Whether you agree with the reasoning or not doesn't actually matter at the 
end of the day, it's still something that can't (or won't) be implemented 
by everyone.


> > Small companies aren't targetted by patent trolls. Only big (really 
> > big) companies are. It's a big-company concern, just like "no per-user 
> > licensing" is a small-company concern. That's just the reality of the 
> > situation, it's not intended to be a bias.
> 
> Except that it very clearly is biasing the decision making process so 
> far.  The language was changed because the big companies weren't 
> comfortable with it, moving in the direction of screwing the little guy. 
> That is bias.

I'm sorry you believe that. It really isn't supposed to be. We're trying 
to find a solution that works for everyone.


> If you really want this to be a baseline codec that everyone can 
> implement, revert the text and then change it to MUST.

Making it a MUST doesn't make it possible for everyone to implement. If 
only standards development worked that way! It would be far easier.


> > and that is not an additional submarine patent risk for large 
> > companies.
> 
> You've created the bias in the premise.  By including the word 
> "additional", there, you have artificially limited the field to codecs 
> which are already implemented by the large companies.  That is not 
> progress, that is one great big, huge, gigantic step backward.

We have to take into accounts the needs of everyone. This includes large 
companies. If large companies will only accept codecs that they've already 
implemented, then that may have to be one of the criteria.


> But since we're in a standards setting venue, non-standards-compliant 
> browsers (now or future) and, by definition out of scope.

Actually, all browsers are in scope to the WHATWG work. It would be short 
sighted in the extreme, for instance, to ignore IE, since they have a 
controlling position in the market.


> > Ogg is _a_ choice, which provides freedom for some but not everyone. 
> > We need a codec that works for everyone.
> 
> Then you might as well give up on HTML5 right now.

I hope we can find a solution that doesn't involve giving up. :-)


> > I think that's what everyone wants. The problem is that Ogg is not 
> > such a codec -- Apple, for instance, can't implement Ogg without fear 
> > of being sued.
> 
> Pardon me, but the sanitized version just isn't strong enough, here.
> 
> Bullshit, bullshit, bullshit.
> 
> Like I said, let's hear what the real reason Apple doesn't want to 
> support this, because this reason doesn't pass the smell test.

If you don't believe the reason they have given, that's your right. But it 
doesn't actually matter what the reason is (except for finding a solution 
that does address their needs), as noted above.

(For what it's worth, I have very good reasons to believe that their 
stated reasons are in fact true. But I can't convince you of that and I 
won't embarass us by trying.)



On Tue, 11 Dec 2007, Jeff McAdams wrote:
> 
> A decision was made to move away from using the ogg family of 
> technologies.  While not a final decision, it is a threatening decision 
> to those of us that value freedom and openness and don't appreciate 
> being screwed by big companies.

Whatever solution we find will be one that is royalty free and open. That 
is not in any doubt.



On Tue, 11 Dec 2007, Jeff McAdams wrote:
> >>
> >> A decision was made to move away from using the ogg family of 
> >> technologies.
> > 
> > No.
> 
> Yes.

As the person who would make that decision, I assure you that no decision 
has in fact been made. That is, in fact, the entire crux of the issue.


> If things are up in the air, then why change it?

Because the SHOULD-level requirement on Ogg did not represent the actual 
status of the spec and of the current consensus. The spec should reflect 
reality -- that, if anything, is an underpinning principle of the WHATWG.


> I'm sick and tired of getting screwed by big companies (including 
> Apple), and I will *not* quietly accept it.

If the text moves to requiring a non-free codec, then you will have been 
screwed, and then you should raise almightly hell. However, no such 
decision has been made (and no such decision will ever be made, at least 
not while I'm involved).


> If the text is changed to move away from a free and open solution to 
> something that is going to be encumbered, you better believe I'm going 
> to be up in arms about it, and I will not apologize for it.  This change 
> is exactly that sort of change.

No, the change here is from a free codec that not everyone will implement 
to an open issue that describes what we need, which is, amongst other 
things, a free codec.


> I would much rather Apple not implement HTML5 at all, so I can call
> Apple out on it in the marketplace, than to let an encumbered technology
> be ensconced in a standard like HTML5.

I entirely agree that it would be unacceptable for HTML5 to require 
encumbered technology.

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