> When they made their choice WebM wasn't an option because it didn't even exist yet.

IE9 is still in development. They can still choose to support WebM.

Apple could still choose to WebM support.

The point isn't that Apple and Microsoft can choose. Rather, you can't expect to ask Google to support H.264 and not ask Microsoft and Apple to support WebM. Apple and Microsoft don't want to support it. Fine. Google doesn't want to support it. Fine.

Neither H.264 and WebM are written into the standard. Fine.

Let the competition begin. The best technology that meets all the needs of the various groups will win.

> GIF is completely irrelevant to the issue at hand (or, if you want to reach for it, WebM is actually more at risk of a GIF-type scenario than h.264)

No, and no. I'd explain more, but I can't follow your logic. (Nor do I really want to try. Sorry, but you seem far too emotional about the topic. I'm probably wrong, but your comment comes off that way).

> Apple could still choose to WebM support.

In fact, Imagination Technologies, the people who make the GPUs for the iPhone(and the iPad as well, I think), have already announced full vp8 support in their next-gen hardware decoders, so it would be really easy for Apple to include webm support in the next iPhone or the one after that. And they're safe from any patent threats as well, since they're already MPEG-LA licensees. It will be interesting to see if they do.

> it would be really easy for Apple to include webm support

And Matroska support. Building container parsers that are resilient to fuzzing attacks is non-trivial. Can I assume you'd like trick play (ffw, rew, scrub), too?

Container parsing: it's not that hard. Besides which, they can use one of the freely licensed existing parsers to solve that problem.

Trick play is already implemented. If you have to do major rework of that area to support a new format, you're doing it wrong.

> Apple could still choose to WebM support.

Not in any meaningful way: as far as I know, there is no hardware decoding support for WebM in production. That leaves 150M iOS devices dead in the water, and a bunch of Macs having to decode HQ videos in software instead of relying on existing, well-supported and well-understood hardware.

> The point isn't that Apple and Microsoft can choose.

Apple and Microsoft also have been investing in h.264 for a long time. They're the least likely players to be able to change and (especially Microsoft) they're not very good at turning on a dime.

> you can't expect to ask Google to support H.264 and not ask Microsoft and Apple to support WebM

Why not? Google already had h.264 support, h.264 is the current leading video standard and enjoys wide support across the board, from hardware to software, from embedded to full-blown computers.

> No, and no. I'd explain more, but I can't follow your logic.

So you'd explain why I'm wrong even though you don't understand what I say? Original.

> No, and no. I'd explain more, but I can't follow your logic.

You'd explain why you disagree with what I say even though you don't even understand what I say?

Uh... right.

It's very simple:

>IE9 is still in development. They can still choose to support WebM.

I was talking with a friend yesterday and mentioned how hilarious it'd be if Microsoft decided to adopt WebM on WP7 and then attack Apple for being too closed. :)

I love the people shouting to the roof for standards support and how H.264 is a proper standard and how we should support it because it's being used everywhere.

I just can't help think of the OOXML debacle.

Yep, antimatter15 had to call it out.

> WebM wasn't an option because it didn't even exist yet.

And when WebMx is released, everybody will hound those who don't immediately change their product strategy to fit this. This is also a good reason for why Apple isn't using WebM: it's not a standard, it's as controlled by Google as Flash is controlled by Adobe.

They're essentially giving a bunch of control of their device to an outside company.

The webm spec is frozen, and all patents are irrevocably licensed. Webm is not 'controlled' by Google.

They're not irrevcably licensed. If you find that WebM does actually violate your patents you can't sue otherwise you lose your license to all of the other patents.

Realistically Google should not revoke your licenses unless you lose the lawsuit (not when filed), because if they have legitimately infringed your patent then it seems like blackmail to keep them from acting on it by such a method.

You're quite right, but I think its ridiculous to ask Google to give you a free license to their patents even as you are suing them for infringing yours.

They're the ones pushing that this be the defactor standard for web video. If that's the case then they shouldn't attempt to block a party from exercising their patent rights by effectively threatening that if they do so they won't have any access to video on the web.

Could you imagine MS saying in their Windows license agreement saying that they can revoke your licenses if you sue them over a patent?

Yes, I can imagine that quite clearly. It wouldn't be the most repressive clause in that license agreement.

AFACT there is no clause in the Windows license that MS could invoke that would prevent you from entering a complete industry.

Google's position is literally... screw with us, and if WebM catches on, you can't do video on the internet.

And that doesn't bother you? They're basically saying, "We may have stolen your technology... oh well, it's ours now. We run the internet."

I guess as long as Google is pushing the technology that "you" like they can do no evil.

That "We may have stolen your technology" is pushing it.

Google did due diligence before buying On2 with VP8. They did patent search. If anyone appears now with some patent claim against VP8, suing left and right users of VP8, it does not show good faith on their part.

The patent thing is just FUD by Apple proponents. But, I won't support WebM until it's an ISO standard, frozen is just a promise at this point.

Their own site says "dedicated to developing a high-quality..." which, taken literally, means that the project is still underway. Also listed on the front page: "Submit patches and improvements" Yet again, saying that it's a work in progress.

The encoder is being improved, and the decoder is being optimised for speed on various platforms but the spec defines what the decoder does and it was effectively frozen as soon as Google converted a bunch of Youtube videos and got hardware manufacturers on board. Any change to the format would break existing content (most of Youtube) and shipping hardware.

The fact that the standard is frozen is not incompatible with them improving their implementation.

ISO leads something to be desired: witness the glacial pace of C++0x (now C++1x). I'd prefer some standardization of VP8 - don't get me wrong - but going through ISO would likely be a mistake.

I think you are wrong to project the failings of the C++ committee on ISO as a whole.

For H.264/AVC, it was less than 4 years from the first draft to final ratification. It was a joint effort of ISO and ITU-T.

Still, if that's too slow, SMPTE seems to go faster when they start with an existing codec. VC-1 and VC-2 (a profile of Dirac) were both done there.

BTW, there is an effect at ISO to do a royalty-free ("Option 1") MPEG: http://www.robglidden.com/tag/mpeg/