Google Submits VP8 Draft To the IETF

An anonymous reader writes "Google has submitted an Internet Draft covering the bitstream format and decoding of VP8 video to the Internet Engineering Task Force. CNET's Stephen Shankland writes, 'Google representatives published the "VP8 Data Format and Decoding Guide" at the IETF earlier this month, but that doesn't signal standardization, the company said in a statement. The document details the VP8 bitstream — the actual sequence of bytes into which video is encoded. "We submitted the VP8 bitstream reference as an IETF Independent RFC [request for comments] to create a canonical public reference for the document," Google said. "This is independent from a standards track." The IETF document could help allay one concern VP8 critics have raised: that VP8 is defined not by documentation of the bitstream but rather by the source code of the software Google released to implement VP8. But the IETF document still plays a subordinate role to that source code.'"

Comments

Re:Reminds me of Sony

[theaveng]

Not the same thing.

But I understand your point about wanting to avoid another VHS versus Beta or HDdvd versus Bluray format confusion. It would have a negative impact on consumers, especially those who barely know how to use computers ("How do I make the window fill the whole screen?"). Or those wondering why they can't play the VP8-encoded video in their iGadget, since it only supports MPEG formats.

Venue choice?

[Compaqt]

Is there any significance to the fact that Google chose IETF instead of ISO (where MPEG-LA and M$ submitted H.264 and OOXML)?

Re:Venue choice?

[happymellon]

Ok I just posted below a similar question, and checking out wikipedia seems to imply that they work with ISO:

The Internet Engineering Task Force (IETF) develops and promotes Internet standards, cooperating closely with the W3C and ISO/IEC standards bodies and dealing in particular with standards of the TCP/IP and Internet protocol suite.

So is this ment to bypass the ISO standardisation, and get it put straight in an ISO standard? That's a pretty imaginative way to play the game, kudos to them.

In a way, they did submit it to ISO, just a small board but one that control everything that Google cares about.

Re:Venue choice?

[arivanov]

Yes there is. Read on the MSFT XML history of going through ISO. It says all that there is to be said about ISO certification.

IETF may have its own politics (same as any standards body). However, out of all standards bodies it is the one which is probably the least corrupt.

Re:Venue choice?

[msauve]

Well, let's see. The ISO has OSI-IP, IDRP, IS-IS, CMIP, X.400, X.500, etc. The IETF has TCP/IP, BGP, OSPF, SNMP, SMTP, LDAP, etc.

I think it's pretty clear why they created an IETF RFP.

Re:Venue choice?

[TheRaven64]

IETF RFCs are just that - requests for comments. Anyone can publish one. The IETF assigns them a number, and they are public, but that's all. The IETF does not necessarily endorse them, they just publish them so that they can get feedback.

Within the set of RFCs there are some that are designated 'standards track'. These are ones that will eventually become IETF-endorsed standards. Most Internet-related standards are defined by a set of standards-track RFCs. These have a number of requirements, such as being free to implement (no known lurking patents) and having two existing, interoperable, independent implementations.

In contrast, some are informational RFCs, which basically just document existing practice. A company often releases one of these to let everyone else know what they are doing. It's basically a central location for publishing documentation.

Unlike a submission to ISO, this is not a request for standardisation, it's just a slightly more formal way of publishing documentation than popping it up on your own web server.

It's worth noting that publishing an informational RFC is sometimes the first step towards getting something adopted on the standards track. If I were in charge at Google, I would invite the IETF to form a video encoding working group and take control of the evolution of WebM.

Re:Venue choice?

[msauve]

It takes some time before an RFC can become a proposed IETF standard.

A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable.

- RFC 2026

There aren't that many actual IETF standards. The standards process isn't even a standard. HTTP is only a draft standard. RFC 1918 (which defines the 10.0.0.0/8 - 172.16.0.0/12 - 192.168.0.0/16 private IP addresses) is only a proposed standard, yet was published in 1996, and is in universal use.

Re:Venue choice?

[jpmorgan]

The IETF is the correct body for something like this, not ISO.

ISO is a standards body, and the function of a standards body in every other industry is to take multiple incompatible implementations of a concept, figure out the best of each and combine them into a single common standard that everybody can support. Politics are an inherent part of it, since the entity whose current products is closest to the eventual standard stands to do well financially. Look at how OpenGL is developed, for an example of a proper standardization process. Companies implement the standard, then add extensions to provide new features and give themselves a competitive advantage. Then at the next standards meeting, OpenGL is enhanced to a common base by taking these extensions and making them part of the next version of the standard.

But for some bizarre reason, software types view standardization as just a giant design process (except design by committee, an extremely political committee). If HTML and CSS were to follow normal standardization procedures, for example, Firefox, Opera, Chrome, Safari and even IE would be free to extend HTML however they want, and then every couple of years the best extensions from all would be combined and rolled into the next version of HTML.

The IETF is the correct body for VP8, because VP8 doesn't need standardization. There are no multiple competing implementations that need to be brought into alignment. It exists, it works, fait accompli. This is the process by which most successful Internet protocols were created. Maybe in the future when people have new ideas about how VP8 can be enhanced, it'll need a standardization process. But for the time being, all we need are the details, published openly and clearly, so anybody can implement it.

Standardization is about evolution, not intelligent design.

Re:Venue choice?

[mlingojones]

If HTML and CSS were to follow normal standardization procedures, for example, Firefox, Opera, Chrome, Safari and even IE would be free to extend HTML however they want, and then every couple of years the best extensions from all would be combined and rolled into the next version of HTML.

That's pretty much what happens with HTML and CSS. The canvas element in HTML5 and the transform property in CSS3 were initially created and implemented by Apple in WebKit, and later adopted by the W3C.

Re:Venue choice?

[arose]

True, but neither of those (and video came from Opera, no?) generally had incompatible implementations that needed to be reconciled (not that reconciliation isn't possible, but just dropping one implementation in favor of another is not unheard of, like IndexedDB vs Web SQL), they just tend to get tweaked (or not) and adapted as is if they work well. I think that is what jpmorgan was trying to make: generally ISO relies on working groups that try to make their stuff work together and generally IETF tends to document existing stuff so that other people can adopt it as is.

Re:Venue choice?

[dirkx]

And there is also the expectation of "But the IETF document still plays a subordinate role to that source code.'' in the original article. However one interesting expectation or requirement of IETF standards is that one expects at least one, ideally two, independent implementations based on the written spec. This would alleviate the concerns that the VP8 case is too leading - as one has now an example of an independently derived code base - which has taken the written spec as its lead - and secondly it would also give the community a very fair idea as to any residual IPR issues, by Google or by others. Thanks, Dw.

Re:Venue choice?

[hedwards]

A submission to ISO definitely isn't a request for standardization. I think we settled that with that whole debacle over MS' entry into the open document niche. They said themselves that they prefer to allow the market to decide. Which is just a fancy way of saying that they aren't a standards organization.

A standards organization that allows competing standards to battle it out is completely worthless in that respect. They're supposed to pick winners and losers otherwise you don't get an interoperable standard.

Re:Venue choice?

[peppepz]

Yes, ISO and IETF have a different definition of what is an "open standard".

Re:Venue choice?

[node 3]

So is this ment to bypass the ISO standardisation, and get it put straight in an ISO standard? That's a pretty imaginative way to play the game, kudos to them.

No, they did this because it's much easier to put out an IETF RFC than it is to make an actual ISO standard. In terms of anything resembling an actual, official standard, Google is starting from a very weak position with regards to WebM. By going through the IETF, they can try to make WebM actually appear as though it's an open standard, whereas H.264 actually is an open standard.

Also, stating that the IETF cooperates closely with the ISO does not imply that creating an IETF standard somehow grants ISO standard status.

Re:Venue choice?

[node 3]

And how many incompatible extensions to H.264 where there in its development? By being a standard, participating groups were able to extend H.264, but they didn't have to go through the process jpmorgan laid out. The ISO process allowed the industry to extend MPEG-4 to what it is today. Such a thing is not currently feasible with WebM.

Re:Venue choice?

[node 3]

Apparently you've never seen how Open Source projects work. There are plenty of incompatible modifications that compete with each other, often replaced, sometimes permanently forked, etc.

On the other hand, I'm unaware of multitudes of competing and incompatible MPEG-4 implementations out in the wild during the standardization process. I am aware of different and not-entirely compatible profiles within the standard, but the standardization process was open, and not merely a competition amongst shipping technologies like you make it out to be.

On the other hand, WebM was developed in a closed manner, and never went through the competition and refinement process that H.264 went through. Now WebM is frozen in place, warts and all. And while refinements and optimizations to the implementation of WebM is possible, any refinements and advancement of the bitstream is going to be exceedingly difficult.

Re:Venue choice?

[SuricouRaven]

To head off the inevitable dispute over h264 being an open standard: It's open in the sense that it's entirely documented and you can easily look up a specification that details everything about h264, in sufficient detail to write your own encoder or decoder. It's not open in the sense that you can't acually write either of these, as much of the vital mathematics required are subject to patents. So it depends if you consider 'open' to mean access to the specification, or the legal right to use that access.

Re:Venue choice?

[Bill_the_Engineer]

A standards organization that allows competing standards to battle it out is completely worthless in that respect. They're supposed to pick winners and losers otherwise you don't get an interoperable standard.

Really? I thought the point was to be able to say that this program uses XYZ standard, then any program using XYZ standard should be compatible with that program. A standards body does not dictate what you can and can't use. Truth is nobody can.... It's called freedom.

Re:Venue choice?

[arose]

Generally, not always. The process also allowed the industry to stuff all of their collective patents in...

Such a thing is not currently feasible with WebM.

It is not desirable for WebM, it was specifically designed to be simple and easy to implement (in the sense that there aren't huge amounts of optional features). Having a million profiles and 3D video might be good for MPEG-4, but it is counterproductive to WebM's current goals (baseline for the video tag, at least I'm pretty sure that's where Google is aiming at).

Re:Venue choice?

[node 3]

Pretty spot on except for:

It's not open in the sense that you can't acually write either of these [encoder and decoder], as much of the vital mathematics required are subject to patents.

That is false. You can write both of these. You just have to license the patents, which is openly available to all parties.

and:

So it depends if you consider 'open' to mean access to the specification, or the legal right to use that access.

Anyone can buy the legal right to use that access. H.264 is the very definition of an open standard (while WebM is not). It's just an example of one that is patented.

You're right that patents limit the ability to completely freely use H.264, but no one is stopped from licensing those patents. They are openly available to one and all.

Re:Venue choice?

[node 3]

Which does absolutely nothing to defend your statements that somehow ISO standards (like H.264) are created by a bunch of companies going around making proprietary standards and all vying to have their standard adopted officially.

To your specific response here, that's exactly why WebM is technologically inferior to H.264.

Re:Venue choice?

[macshit]

Also, stating that the IETF cooperates closely with the ISO does not imply that creating an IETF standard somehow grants ISO standard status.

Indeed. But the notion that a standard must be from ISO to "count", is of course incorrect -- the canonical example being TCP/IP, which utterly trounced the competing ISO-standardized protocols.

Re:Venue choice?

[Your.Master]

You're looking at too narrow a scope. We need standard video codecs, because we have multiple competing implementations of "video codec" that need to be brought into alignment. We have a good one, H.264, but the patents on it displease industry members so they're trying to make another good one without patents -- which is okay, because we often have multiple standards when there are tradeoffs to be made.

Much as the industry doesn't need an independently published international standard for "Duracell form factors" but it is helpful to have standard "battery form factors" -- AAA, D, etc.

Re:Venue choice?

[arose]

You are putting words in my mouth, good day.

Re:Venue choice?

[tyrione]

Also, stating that the IETF cooperates closely with the ISO does not imply that creating an IETF standard somehow grants ISO standard status.

Indeed. But the notion that a standard must be from ISO to "count", is of course incorrect -- the canonical example being TCP/IP, which utterly trounced the competing ISO-standardized protocols.

It trounced on technical superiority. There goes your example. WebM is technically inferior to H.264.

Re:Venue choice?

[tyrione]

You are putting words in my mouth, good day.

You can't debate yourself out of a paper bag.

Re:Venue choice?

[cooldev]

IETF also has items like RFC1149: A Standard for the Transmission of IP Datagrams on Avian Carriers

In other words, there is no filter; it seems anyone can submit anything to the IETF. My main concern over the WebM "specification" is best summarized by by the great analysis at http://x264dev.multimedia.cx/archives/377:

But first, a comment on the spec itself.

AAAAAAAGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!

The spec consists largely of C code copy-pasted from the VP8 source code -- up to and including TODOs, "optimizations", and even C-specific hacks, such as workarounds for the undefined behavior of signed right shift on negative numbers. In many places it is simply outright opaque. Copy-pasted C code is not a spec. I may have complained about the H.264 spec being overly verbose, but at least it's precise. The VP8 spec, by comparison, is imprecise, unclear, and overly short, leaving many portions of the format very vaguely explained. Some parts even explicitly refuse to fully explain a particular feature, pointing to highly-optimized, nigh-impossible-to-understand reference code for an explanation. There's no way in hell anyone could write a decoder solely with this spec alone.

In other words, there is no real spec that could stand up to ISO-type scrutiny, ignoring all politics. They are attempting to make standard a specific implementation, with all its current quirks and flaws, and from what I've read it is now set in stone; even though they are posting an RFC (request for comments) they will not be changing the spec to address the known flaws.

How is this good for anybody but Google?

Re:Venue choice?

[arose]

FFMPEG have their own decoder at the very least.

Re:Venue choice?

[Kitsune Inari]

Just openness vs actual freedom. Which one is more important?

Re:Venue choice?

[zeroshade]

IETF also has items like RFC1149: A Standard for the Transmission of IP Datagrams on Avian Carriers

So the fact that the IETF RFC's have a history of April Fools jokes makes it bad? Perhaps they see the date and allow it because it's a good April Fool's joke. It's also amusing that you chose that one because someone actually did implement it :). Had a latency of 56 minutes if i remember.

Source code is fine!

[multipartmixed]

Well, you know, as long as it's not terrible code.

Once upon a time, the RFC for IP and the BSD code base (that *everyone*) used differed in some subtle way. W. Richards Stevens was the first guy to notice, years after both were written.

Guess what happened? They changed the standard.

Re:Source code is fine!

[Anonymous Coward]

Interestingly, yes.

But, first, English is less of a standard than a moving target. For example, the MLA standard for citing references changes every year. American English didn't always place periods inside the quotations either, it evolved. Today, the phrase "begs the question" is usually accepted as an acceptable replacement for "raises the question," instead of referring to a specific fallacy. If English is to actually be considered a standard, it's one that's constantly changing. But, let's move on to answering your question more directly.

Here's an example where I might disregard the rules of standard English. To wipe your hard drive clean, enter the command "dd if=/dev/zero of=/dev/sda". Technically, having the period outside the quotation marks is incorrect; however, it clarifies that the period should not be entered by the user. Here, a rule for English gets in the way of what I want to communicate, so I ignore it.

Let's do something more technical. Take the original TFTP specification. It introduces a condition where packet looping could occur between server and client (an issue addressed in a later revision). Should astute coders have disregard minor details in the standard to address that oversight if it suits them? Yes. Yes, they should.

Standards, including the written rules for English, are there for a reason. The reasons for standardization of English are the same as for TFTP, HTTP, or any other protocol. If everyone agrees on the rules, communication becomes easier. However, when those standards get in the way of effective communication, they should be ignored. Still other times, portions of standards are outdated and it no longer makes sense to follow them, since doing so does nothing to enhance communication. For example, it's becoming more common to avoid paragraph indents, which has been largely replaced by double-spacing between paragraphs. The indent to alert the reader that a new paragraph has begun is no longer necessary.

Sorry, let's get back to my point. The point of standardization in English is communication. The grammatical error by multipart/mixed did nothing to detract from the point he was making. Therefore, calling him out (unless m/m happens to be your English student) was unnecessary, since the meaning was clear. Just as unnecessary was my complaint about capitalization; correct grammar wouldn't have done anything to enhance the meaning of what was written.

By the way, the basis for your question is covered by several fallacies.

The first is the generalization fallacy, claiming that two situations are highly similar, when they aren't. Is it so easy to assume that breaking the rules of one standard automatically means that it's okay to break the rules of others? You could have written "Do you also disregard the societal standards surrounding murder when it suits you?" English standards and technical standards are very different things.

Similarly, and for much the same rationale, it's a slippery slope fallacy. There's an assumption that disregarding one standard leads to disregarding another, more important standard.

The last fallacy that jumped out at me is the "begging the question" fallacy. There is the subtle premise that disregarding minor details of technical standards is a bad thing.

Anyway, I've been working all morning, so I appreciate the break. :)

Re:Source code is fine!

[iluvcapra]

You need a standard to define what's a valid and invalid file. Having only the source code would allow people (including Google) to create WebM encoders which are nominally compatible with the open source decoder but "extend" the format by inserting new data in a nonstandard way, which might then be available to only to the (perhaps paying) users of their platform. Thus fragmentation of WebM, perhaps eventually leading to a situation where only one company's reader and writer are useable in most practical circumstance.

Re:Source code is fine!

[multipartmixed]

Source code is nothing more than a rigorous specification. In fact, it is so rigorous that you can write a translator which automatically translates the specification into a binary you can run on your platform.

No specification will stop a vendor from writing proprietary extensions. If they publish updated source code, then whoever can catch up.

Also, isn't the VP8 source code freely usable?

Re:Source code is fine!

[tyrione]

Well, you know, as long as it's not terrible code.

Once upon a time, the RFC for IP and the BSD code base (that *everyone*) used differed in some subtle way. W. Richards Stevens was the first guy to notice, years after both were written.

Guess what happened? They changed the standard.

The world is far worse off without Mr. Stevens.

Re:Source code is fine!

[multipartmixed]

> The world is far worse off without Mr. Stevens.

Truer words have never been spoken.

Re:Source code is fine!

[vadim_t]

Source code makes for a crappy specification.

Take a line that reads 4 bytes that determine the length of a section. Is the field proper big or little endian, or the application has to be compatible with both? Is it supposed to be signed or unsigned? If signed, what does a negative size mean? Can it be 0 and if so how is that handled? Are there any special values that aren't a literal length but indicate something else? Like 0xffff being used to indicate it's a section with a size >4GB and the real size is somewhere else.

Sure, you might think you know the answer, it's "int length" so it's signed, and so on. But that only tells you what the code thinks it is. There may be a file it fails to handle correctly, and without a spec you don't know if it's a badly made file, or badly written file reading code.

Re:Source code is fine!

[multipartmixed]

> Source code makes for a crappy specification. [....] But that only tells you what the code thinks it is. ...and if the code *is* the specification, then you know what the specification says.

If you re-implement the code so that it behaves differently, you are not following the specification.

Now, it's entirely possible that we're talking about crappy code here -- but like I said earlier, good code makes a fine spec, IMHO.

Code is almost always deterministic, i.e. it will only do one thing. I have read many, many, many ambiguous specifications in my day.

So what does this mean?

[happymellon]

Google could have just released documentation providing the specification, so how does the IETF help? So that they can call it IETF.4628 (Or however the IETF standards are named), or are they looking to make it an internet standard, rather than just a video standard like H.264?

Re:WebM will never catch on

[mrnobo1024]

1) WebM/VP8 probably infringe on several MPEG-LA patents (I don't agree with software patents, but U.S. courts do)
2) Google has not offered to indemnify anybody who uses WebM.

H.264 infringes on a patent I own. When adoption is sufficient, I will sue everyone who uses it (MPEG-LA doesn't indemnify its users against outside patent claims either).

(sure, I'm probably lying, but can you prove it?)

Re:WebM will never catch on

[Hope Thelps]

WebM/VP8 probably infringe on several MPEG-LA patents

Which parts of WebM/VP8 do you think probably infringe on which patents, and why?

Re:WebM will never catch on

[commodore6502]

I thought users get to access the MPEG codecs for free. And GIF is now public domain?

Re:WebM will never catch on

[javacowboy]

H.264 infringes on a patent I own. When adoption is sufficient, I will sue everyone who uses it (MPEG-LA doesn't indemnify its users against outside patent claims either).

How many lawyers do you have, how much do you pay them, and how good are they?

Re:WebM will never catch on

[javacowboy]

I'm not privy to the technical details, but the U.S. patent office hands out patents to pretty much anybody who asks for them, and I'm willing to bet MPEG-LA has way more patents than Google has.

Re:WebM will never catch on

[Anonymous Coward]

3) Mobile hardware has H.264 compatibility built-in, not so for WebM,

Will this argument DIAF, please. There are basically NO H.264 decoder ASICs in general mobile use, they're all DSPs with an H.264 codec implemented in software. Since WebM/VP8 is so similar to H.264, it would take quite some effort to create an evil DSP that can decode H.264 but can't be made to decode VP8 with comparable features/resolution/bitrate, and I assure you the general-purpose DSP in your smartphone will handle it just fine.

Re:WebM will never catch on

[javacowboy]

1) SCO was about non-existent copyright rights and claims. MPEG-LA has real patents on video formats and compression.
2) Google hasn't offered to indemnify anybody, as MPEG-LA has. That shows Google has little to no confidence in WebM's patent standing.
3) What are you talking about? Why go through the trouble of encoding to WebM when H.264 is the path of least resistance?
4) YouTube doesn't serve full movies or tv shows. It only serves 10 minute video clips. What's your point exactly?

Re:WebM will never catch on

[Hope Thelps]

So it's just a subset of 'anything you do probably infringes on someone's patent, so don't even wait for them to sue, don't ask for details, just fold to every potential bully'? I guess that's one approach to life. Hope you have fun with it.

Re:If Microsoft was doing this

[drinkypoo]

If microsoft was doing what google is attempting to do we would all be screaming bloody murder

Google produces open source, makes Linux software, and gives away free web services and doesn't care if you block ads, which would be trivial to detect and act upon when you're talking about the architecture of google. Microsoft has been convicted of abuse of their monopoly position. It is utterly unreasonable to treat google the same as convicted criminal Microsoft.

Re:WebM will never catch on

[mlingojones]

H.264 infringes on a patent I own. When adoption is sufficient, I will sue everyone who uses it (MPEG-LA doesn't indemnify its users against outside patent claims either).

(sure, I'm probably lying, but can you prove it?)

That's ridiculous. You can use that to argue against the adoption of anything. "HTML infringes on a patent I own, don't use it or I'll sue you!" "Keyboards infringe on a patent I own, don't use them or I'll sue you!" "You can't prove me wrong, so I win!"

The burden of proof is on you.

Re:WebM will never catch on

[kevinmenzel]

To be fair, YouTube no longer has a length limitation...

Re:WebM will never catch on

[Hope Thelps]

Google hasn't offered to indemnify anybody, as MPEG-LA has.

Who exactly are you claiming that MPEG-LA have offered to indemnify, and what do you claim that they have offered to indemnify them against?

From their FAQ:

Q: Are all AVC essential patents included?
A: No assurance is or can be made that the License includes every essential patent. The purpose of the License is to offer a convenient licensing alternative to everyone on the same terms and to include as much essential intellectual property as possible for their convenience. Participation in the License is voluntary on the part of essential patent holders, however.

Re:WebM will never catch on

[TheRaven64]

VP8 probably infringe on several MPEG-LA patents

Does it? The MPEG-LA has not produced any patents that it infringes, On2 presumably checked the (easy-to-find) list of MPEG-LA patents before shipping VP8, and the MPEG-LA is currently asking people to come forward with patents that cover VP8 - not something it would need to do if it already had a large pool of them.

Google has not offered to indemnify anybody who uses WebM

The MPEG-LA does not offer indemnity either. This was demonstrated quite well a couple of months ago when MPEG-LA licensees were sued for patent infringement over H.264.

Mobile hardware has H.264 compatibility built-in, not so for WebM

Most 'H.264 hardware' is really a DSP with a few things like [I]DCT in hardware. This same hardware can used for VP8 (it's typically already used for MPEG-2 and MPEG-4 ASP).

The media companies have encoded their content in H.264, they can't be bothered to re-encode it to WebM

YouTube is owned by Google, and they're going to be making everything WebM soon. I wouldn't be surprised if they only made the low-quality versions H.264 in the future and required WebM for the higher-quality encodings. This would let them keep iPhone users happy (low quality encoding isn't such a problem on a tiny screen), while forcing desktop users to install a WebM plugin.

Re:WebM will never catch on

[cforciea]

Whoosh?

Re:WebM will never catch on

[mlingojones]

Here you go.

From the article:

"VP8's intra prediction is basically ripped off wholesale from H.264," he wrote. "This is a patent time-bomb waiting to happen. H.264's spatial intra prediction is covered in patents and I don't think that On2 will be able to just get away with changing the rounding in the prediction modes."

Re:If Microsoft was doing this

[Burpmaster]

If microsoft was doing what google is attempting to do we would all be screaming bloody murder

What, you mean producing a standard that actually matches the implementation and irrevocably granting free use of the necessary patents to everyone? How do you know how people would respond? Microsoft has never done that. They'e done the exact opposite, though...

Re:If Microsoft was doing this

[Rockoon]

Are saying is that if Microsoft was doing this, then it could not be tolerated?

I mean, it sounds like what you are saying. That Google can do this, and its awesome, but it cannot be tolerated if we do a 's/Google/Microsoft' ?

Re:WebM will never catch on

[TheRaven64]

So apply the same standard to the MPEG-LA. They only definitive statement that they've actually made is that they are putting together a pool of patents covering VP8 (not that they actually have any) and that they will later be charging for licenses for this pool. This somehow gets repeated as 'VP8 infringes a load of H.264 patents'.

Re:WebM will never catch on

[TheRaven64]

I'm not privy to the technical details

Why not? VP8 is public and has two independent implementations (libavcodec and libvpx) for you to look at. All patents are public. All H.264 patents are listed clearly on the MPEG-LA's website. It's easy to validate any claim of patent infringement. So, unless you are just spreading FUD, point to the patent and point to the part of VP8 that it infringes.

Hey Google? You want to win this war?

[Anonymous Coward]

Take some that immense R&D budget that you have and put a team of programmers on the task of getting VP8 encode/decode acceleration via OpenCL/CUDA.
The x264 team is sitting back and saying it can't be done, meanwhile a university has already posted the code for a modified x264 that uses the GPU to accelerate the pyramid search. The race is already started.

If x264 is further improved for GPU support and this makes it into FFMPEG, then the race is over...

Re:Hey Google? You want to win this war?

[oiron]

I doubt that's going to be particularly difficult for 3rd party devs to do - the libavcodec version is only 1400 lines. I'm sure that there's enough reusable code for decoder blocks floating around to assemble an OpenCL version of it...

Re:Hey Google? You want to win this war?

[thegarbz]

I'm wondering why "Generic highly parallelized task X" would not be able to be offhanded to the GPU via CUDA. I mean We have CUDA decoding for every other format along with plenty of random applications such as Folding@home, what would make WebM special? What makes WebM different than H.264 in the decoding arena?

Forgive me for being understandably skeptic when a competitor of a product says something can't be done.

Re:Hey Google? You want to win this war?

[Jonner]

Hardware acceleration is essential for wide adoption, but in mobile devices to a far greater extent than desktops. If Android devices can be targeted by OpenCL, then Google should definitely put a lot of effort into that. It would also be very interesting if there were a good OpenCL implementation of VP8 and iOS supported OpenCL, since that would hurt Apple's position that H.264 must be used for all the devices that have hardware support for it.

Cheers!

[pentadecagon]

And good luck for this endeavor. A success here would allow us to get rid of at least a bit of patent headache.

Re:WebM will never catch on

[mlingojones]

YouTube is owned by Google, and they're going to be making everything WebM soon. I wouldn't be surprised if they only made the low-quality versions H.264 in the future and required WebM for the higher-quality encodings. This would let them keep iPhone users happy (low quality encoding isn't such a problem on a tiny screen), while forcing desktop users to install a WebM plugin.

Three things wrong/silly that I can see with that statement.

• Few iPhone users use the YouTube website, as there is a native YouTube app preinstalled on each device.
• Plugins? Argh! That's what we're trying to get away from in the first place!
• That wouldn't do anything for desktop users anyway, unless they get rid of Flash as well. And as Flash can be used to wrap H.264 video, the path of least resistance to content providers is to just continue to serve H.264 wrapped in Flash, rather than re-encode everything in another, widely unsupported format.

Re:WebM will never catch on

[mlingojones]

I have. There have been independent analyses that call the patent status of VP8 into question.

http://arstechnica.com/open-source/news/2010/05/google-support-aside-webm-carries-patent-risks-from-mpeg-la.ars

boolean entropy coder

[hey]

"essentially the entire VP8 data stream is encoded using a boolean entropy coder."
Well, duh.

Re:boolean entropy coder

[Rockoon]

An entropy encoder encodes symbols taken from an alphabet of symbols.

A boolean coder is a special case that has an alphabet of exactly 2 symbols, which is not required.. or even common.

Most compressors use an alphabet of 256 symbols.

Why do people that don't know data compression make ignorant comments about data compression?

Re:boolean entropy coder

[Jonner]

The ignorant gp poster probably thought "boolean entropy coder" was just a synonym for "lossy encoder." I didn't know what it meant and didn't hastily jump to that conclusion.

Smart move, Google...

[Qubit]

Creating an RFC was a very smart move for Google.

First off, remember that when WebM burst onto the scene, Google made it pretty clear that they didn't want to monkey-around with improving the VP8 codec. Sure, maybe it could be improved, but they basically said that they just wanted to leave it as-is and have people start using the darn thing. The benefit of having it in use out in the wild outweighed any delays.

So, by submitting VP8 to the IETF as an RFC, they're not (necessarily) revisiting the question of making improvements or tweaks to VP8, but they are making progress on standardizing the codec.

Second, after the stunts with OOXML in ISO, if they actually want everyone to use VP8 in WebM for all of their web video needs, they might just want to avoid those jokers. I don't know too much about the w3c, OASIS, ECMA, or any of those other standards bodies, but I'm not sure if those would be appropriate places to go to standardize a codec, anyhow.

Third, IPR (Intellectual/Imaginary Property Rights). The IETF has an RFC (of course it's an RFC!) about IPR, including a description of who needs to disclose information about possible IPR and when.

Here's an excerpt:

6.1. Who Must Make an IPR Disclosure?

6.1.1. A Contributor's IPR in his or her Contribution

      Any Contributor who reasonably and personally knows of IPR meeting
      the conditions of Section 6.6 which the Contributor believes Covers
      or may ultimately Cover his or her Contribution, or which the
      Contributor reasonably and personally knows his or her employer or
      sponsor may assert against Implementing Technologies based on such
      Contribution, must make a disclosure in accordance with this Section
      6.

      This requirement specifically includes Contributions that are made by
      any means including electronic or spoken comments, unless the latter
      are rejected from consideration before a disclosure could reasonably
      be submitted. An IPR discloser is requested to withdraw a previous
      disclosure if a revised Contribution negates the previous IPR
      disclosure, or to amend a previous disclosure if a revised
      Contribution substantially alters the previous disclosure.

      Contributors must disclose IPR meeting the description in this
      section; there are no exceptions to this rule.

6.1.2. An IETF Participant's IPR in Contributions by Others

      Any individual participating in an IETF discussion who reasonably and
      personally knows of IPR meeting the conditions of Section 6.6 which
      the individual believes Covers or may ultimately Cover a Contribution
      made by another person, or which such IETF participant reasonably and
      personally knows his or her employer or sponsor may assert against
      Implementing Technologies based on such Contribution, must make a
      disclosure in accordance with this Section 6.

I don't think that Google necessarily expects to see the MPEG-LA boys show up en force to describe all of the patents they have that they think read on VP8. Yes, it's too bad. But I don't think it's too unreasonable to believe that anyone who gets involved in a discussion about this RFC will need to disclose any IPR they know about. If Google or someone else can get employees from some of the primary codec-patent-owning companies to be at all involved in the discussion, this could force them to tip their hand regarding patents (or risk legal problems later for failing to disclose them at this time).

Overall, not much work for Google with the possibility of some big payoffs later. Very slick.

Re:Smart move, Google...

[arose]

ECMA is known to rubber-stamp stuff coming from Microsoft (probably others as well), OOXML went to ECMA first.

Re:Smart move, Google...

[larry bagina]

1. MPEG-LA (or any other patent holder) only need to disclose if they participate or contribute.
2. A jury in Texas, not the IETF will decide if there is patent infringement.

Let us be honest about H.264

[westlake]

Is there any significance to the fact that Google chose IETF instead of ISO (where MPEG-LA and M$ submitted H.264 and OOXML)?

Let us be honest about H.264. Where it comes from and how it is used.

H.264/MPEG-4 AVC is a block-oriented motion-compensation-based codec standard developed by the ITU-T Video Coding Experts Group (VCEG) together with the ISO/IEC Moving Picture Experts Group (MPEG). It was the product of a partnership effort known as the Joint Video Team (JVT). The ITU-T H.264 standard and the ISO/IEC MPEG-4 AVC standard (formally, ISO/IEC 14496-10 - MPEG-4 Part 10, Advanced Video Coding) are jointly maintained so that they have identical technical content. H.264/MPEG-4 AVC

VCEG was preceded in the ITU-T (which was called the CCITT at the time) by the "Specialists Group on Coding for Visual Telephony" chaired by Sakae Okubo (NTT) which developed H.261. The first meeting of this group was held Dec. 11-14, 1984 in Tokyo, Japan. In 1994, Richard Shaphorst (Delta Information Systems) took over new video codec development in ITU-T with the launch of the project for developing H.324. Schaphorst appointed Karel Rijkse (KPN Research) to chair the development of the H.263 codec standard as part of that project. In 1996, Schaphorst then appointed Gary Sullivan (PictureTel, since 1999 Microsoft) to launch the subsequent "H.263+" enhancement project, which was completed in 1998. In 1998, Sullivan was made rapporteur (chairman) of the question (group) for video coding in the ITU-T that is now called VCEG. After the H.263+ project, the group then completed an "H.263++" effort, produced H.263 Appendix III and H.263 Annex X, and launched the "H.26L" project with a call for proposals issued in January 1998 and a first draft design adopted in August 1999. In 2000, Thomas Wiegand (Fraunhofer HHI) was appointed as an associated rapporteur (vice-chairman) of VCEG. Sullivan and Wiegand led the H.26L project as it progressed to eventually become the H.264 standard after formation of a Joint Video Team (JVT) with MPEG for the completion of the work in 2003. (In MPEG, the H.264 standard is known as MPEG-4 part 10.) Since 2003, VCEG and the JVT have developed several substantial extensions of H.264, produced H.271, and conducted exploration work toward the potential creation of a future new "H.265". In January 2010, the Joint Collaborative Team on Video Coding (JCT-VC) was created as a group of video coding experts from ITU-T Study Group 16 (VCEG) and ISO/IEC JTC 1/SC 29/WG 11 (MPEG) to develop a new generation video coding standard.

In July 2006, the video coding work of the ITU-T led by VCEG was voted as the most influential area of the standardization work of the CCITT and ITU-T in their 50-year history. The image coding work that is now in the domain of VCEG was also highly ranked in the voting, placing third overall.

The organization now known as VCEG has standardized (and is responsible for the maintenance of) the following video compression formats and ancillary standards:

H.120: the first digital video coding standard. v1 (1984) featured conditional replenishment, differential PCM, scalar quantization, variable-length coding and a switch for quincunx sampling. v2 (1988) added motion compensation and background prediction. This standard was little-used and no codecs exist.
H.261: was the first practical digital video coding standard (late 1990). This design was a pioneering effort, and all subsequent international video coding standards have been based closely on its design.
H.262: it is identical in content to the video part of the ISO/IEC MPEG-2 standard (ISO/IEC 13818-2). This standard was developed in a joint partnership between VCEG and MPEG, and thus it became published as a standard of both organizations. ITU-T Recommendation H.262 and ISO/IEC 13818-2 were developed and published as "common text" international standards. As a result, the two documents are completely identical in all aspects.
H.263: was

Re:If Microsoft was doing this

[gdshaw]

If microsoft was doing what google is attempting to do we would all be screaming bloody murder

What Google is doing is far from ideal technically, but they have given us reasonable grounds to believe that their intentions are honourable: code that we can use freely, and a patent grant with no strings attached.

The technical shortcomings can be forgiven in view of the need to challenge H.264 quickly, and the need to work around patents held by others. I wish we had a codec with the technical qualities of H.264 and the legal qualities of VP8, but we don't. H.264 is irrelevant to me if I can't use it for legal or economic reasons.

When Microsoft has done something similar (like .NET, OOXML or ActiveX) there have usually been details in the fine print that either tie the technology to other Microsoft products or make it legally dangerous to use. What they have done in the past is not comparable to what Google is doing now.

Even Microsoft were to reform their behaviour completely, they would quite rightly be scrutinised very closely because of their past misdeeds.

Re:If Microsoft was doing this

[Rockoon]

The GP pointed out that if Microsoft was doing this, that people would be "screaming bloody murder"

So far, the comments (such as yours) seem to be about why Microsoft is evil, and not about why this move from Google should not be considered bad.

If Microsoft did this very thing, would you be rejoicing the move or would you be screaming bloody murder?

He's been asked and hasn't answered. Now you have been asked.

Re:If Microsoft was doing this

[Anonymous Coward]

No. He's saying that Microsoft has never done this. I wish Microsoft were doing this, because they would have a lot more weight than Google does (though Google would undoubtedly support Microsoft in that occasion).

Re:WebM will never catch on

[DJRumpy]

Interesting read, and it brings up two points which needs repeating. Specifically as to how VP8 does it's intra frame prediction.

From the linked article, Jason Garrett-Glaser (one of the developers of X.264) had this to say:

One specific characteristic of the codec that Garrett-Glaser considers particularly prone to patent risks is its handling of a feature called intra prediction. He accuses On2 of cribbing the technology from H.264.

"VP8's intra prediction is basically ripped off wholesale from H.264," he wrote. "This is a patent time-bomb waiting to happen. H.264's spatial intra prediction is covered in patents and I don't think that On2 will be able to just get away with changing the rounding in the prediction modes."

The other interesting point is the fact that the more a company discusses specific patents, the more they legally expose themselves to potential 'willful' violation in patent claims.

Unfortunately, it could be difficult for Google to provide any unambiguous assurances about VP8's patent status. Under US patent law, companies can be forced to pay triple damages for "willful" infringement—cases in which it can be demonstrated that the company was previously aware of a patent that it infringed. As such, publicly discussing specific patents can dramatically increase a company's exposure to liability.

This is probably why no one is saying much of anything until everyone is ready to lay their cards on the table.

Re:WebM will never catch on

[bill_mcgonigle]

Few iPhone users use the YouTube website, as there is a native YouTube app preinstalled on each device.

What does that have to do with how Google striates their encodings?

Graphics Card Manufacturers

[bill_mcgonigle]

Most 'H.264 hardware' is really a DSP with a few things like [I]DCT in hardware. This same hardware can used for VP8 (it's typically already used for MPEG-2 and MPEG-4 ASP).

At what level is the h.264 decoding provided by the graphics card manufacturers? Do you get a show_h264(x1,y1,x2,y2,&stream_buffer) function or are only those hardware transforms exposed and you have to ship your own decoder?

I get that the DSP can handle WebM's essential bits, but how much buy-in is required from the graphics card manufacturers to make existing products thus capable?

Re:Graphics Card Manufacturers

[Tacvek]

To the best of my knowledge, full blown PCs generally don't have DSPs for that sort of thing, but simply use GPGPU techniques for this, which could be done even without GPU manufacturer support, but I believe for some common codecs they due provide special support.

However for mobile products, the DSP is often completely separate from the 3D graphics chip, and is often built into the CPU. (Well, not built into the the ARM core, but still on the same piece of silicon.)

Sample code for accelerating common codecs is often supplied, which could be modified to support WebM too by somebody familiar with Codecs and DSPs.

Re:Graphics Card Manufacturers

[arose]

I get that the DSP can handle WebM's essential bits, but how much buy-in is required from the graphics card manufacturers to make existing products thus capable?

GPUs these days are quite programmable, I'm pretty sure there are independent (from card manufacturers) codec implementations using video cards. That said, both AMD and Nvidia are listed as supporters, so they probably have bought-in.

Re:If Microsoft was doing this

[squiggleslash]

If Microsoft announced a non-patent encumbered (to the best of their knowledge) codec and released the specification of the format to the IETF, we would not be screaming bloody murder.

15-minute YouTube limit

[tepples]

Since when? Last I heard, YouTube had increased the limit to 15 minutes for non-Partner videos.

Re:15-minute YouTube limit

[kevinmenzel]

http://mashable.com/2010/12/09/youtube-upload-time-limit/ Since december. There is a limit at some point I'm sure, but I've already watched 45 minute TV shows that were uploaded in single parts, and they most certainly weren't Partner videos.

Re:Reminds me of Sony

[Cinder6]

Of course, Blu-Ray was announced before HD-DVD...

Re:If Microsoft was doing this

[Xtifr]

If microsoft was doing what google is attempting to do we would all be screaming bloody murder

When Microsoft releases their software for Linux under terms that allow it to be included in Debian, we'll be able to judge the truth of this claim. I'm not sure whether you're right or wrong, but I think hell is likely to freeze over before we'll ever find out! :)

Microsoft's history of backstabbing their partners and doing everything they can to lock in their users makes them a very different proposition from Google. I suspect that at least, some people would be shouting "it's a trap" if Microsoft did something similar. But there's a solid foundation for that fear with MS, and I'm not seeing any similar foundations for similar fears with Google. I may not trust them (Google) much, but I don't see any benefit to them to attempting to manipulate this format the way MS likely would (embrace, extend, extinguish). Nor has Google been running around shouting about various vague unspecified patents that the FLOSS community has supposedly been violating. Just about the opposite, in the case of VP8. Frankly, there are lots and lots of reasons for treating/viewing Google (or almost anyone else) differently from Microsoft. So, I have to conclude that you're either much more paranoid than I, or a troll.

What might be more interesting to contemplate is: what would happen if Novell or Oracle tried something similar. I suspect that would lead to a fair amount of justified paranoia, and shouts of "it's a trap"--but nowhere near as many as if it were Microsoft--and a fair amount of heated debate on the topic. However, Novell is mostly mistrusted because of their ties to MS, so really, the interesting case, IMO, would be Oracle.

For now, though, I'm just happy that there's finally at least one video format I can legally run on my machine without using the bloody flash player, which has been my only way to play videos at all up till now. I'm not too worried about Google's current control, because it depends on the good will of the community, which is perfectly able to take over and fork in extremis--see Xorg/Xfree86, EGCS/GCC, and arguably, MariaDB/MySQL and OOo/LIbreOffice.

Re:WebM will never catch on

[rtfa-troll]

How many lawyers do you have, how much do you pay them, and how good are they?

Hi; I'm mrnobo1024's partner in this. Our IP budget for 2011 is about 10MUSD, but for 2012 we have dedicated 85 billion dollars. That may seem quite a bit, but you should know a) that the dollar is expected to fall to about 10% of it's current value and b) we also have a bunch of suits lined up against companies using MS Windows. This still means that we have 80% of the top lawyers in IP working directly for us and will have well over a billion 2010 dollars to go after the MPEG-LA licensee list.

We even have a deal with Google to take over their VP2 patents (which cover H.264 and the MPEG-LA doesn't have access to; look it up).

(for a truth value which demonstrates complete partnering synergies with the truth value of mrnobo1024's post)

Re:WebM will never catch on

[Draek]

That's ridiculous. You can use that to argue against the adoption of anything.

Exactly! now you see the value of the patent system for companies such as Microsoft and Apple.

Linux gaining too much ground on the corporate arena? "the Linux kernel may or may not infringe on over 200 of our patents, and we may or may not decide to sue everyone that uses it". VP8 threatening their plan for dominance of the online video market? "VP8 may or may not infringe on our patents, and we may or may not decide to sue people over it, eventually".

And the best part? given how corrupt the system is, approving patents left and right regardless of how vague they are or how much prior art there may be, chances are they're actually right and you are infringing on *something* of theirs.

God were those bribes well spent.

Re:WebM will never catch on

[Draek]

Well, a plugin would only be required for IE users, and only until the sheer momentum of Chrome, Mozilla and Opera force them to implement it anyways. They don't have much to gain from h.264, so it's unlikely they'd continue the holy war to the end, unlike Apple.

Re:WebM will never catch on

[javacowboy]

Does it? The MPEG-LA has not produced any patents that it infringes, On2 presumably checked the (easy-to-find) list of MPEG-LA patents before shipping VP8, and the MPEG-LA is currently asking people to come forward with patents that cover VP8 - not something it would need to do if it already had a large pool of them.

Why give Google the opportunity to work around those patents? Also, Sun took years to open source Java, yet Google open sourced VP8 in months, indicating to me that Google was sloppy and didn't do their due diligence.

The MPEG-LA does not offer indemnity either. This was demonstrated quite well a couple of months ago when MPEG-LA licensees were sued for patent infringement over H.264.

MPEG-LA indemnifies users for the patents they own, not for patents outside their patent pool, which is way more than Google is offering to do.

Most 'H.264 hardware' is really a DSP with a few things like [I]DCT in hardware. This same hardware can used for VP8 (it's typically already used for MPEG-2 and MPEG-4 ASP).

More hoops to jump through.

YouTube is owned by Google, and they're going to be making everything WebM soon. I wouldn't be surprised if they only made the low-quality versions H.264 in the future and required WebM for the higher-quality encodings. This would let them keep iPhone users happy (low quality encoding isn't such a problem on a tiny screen), while forcing desktop users to install a WebM plugin.

I'm going to get modded down as a troll again for saying this (even though every one of my posts on this topic has been sincere, and labelled "troll" by reactionary Slashdotters), but Google doesn't own any of the content outside of users' home videos. The RIAA, MPAA, and gave studios produce most of the content that people are interested in, and that comprises more than 10 minute clips, and they're not going to re-encode in WebM. Even Apple couldn't bring those companies to their knees so what makes you think Google will?

Re:WebM will never catch on

[TheRaven64]

Also, Sun took years to open source Java, yet Google open sourced VP8 in months, indicating to me that Google was sloppy and didn't do their due diligence.

Do you have any idea how meaningless that comparison is? The problem with open sourcing Java was that some parts were owned by Sun, some were licensed from third parties, and the licensed parts had to be either relicensed or replaced. In contrast, On2 was already shipping VP8 and had been working on it - specifically working around patents to produce it - since before Google bought them.

It's also worth pointing out that, not only are you comparing completely unrelated things, you are comparing completely unrelated sizes of things. The Java code is a couple of orders of magnitude bigger than the VP8 code.

MPEG-LA indemnifies users for the patents they own, not for patents outside their patent pool, which is way more than Google is offering to do.

Uh, what? You don't actually know the difference between indemnifying and licensing, do you? MPEG-LA and Google both offer licenses to their patents. MPEG-LA has a complex fee scale, Google provides you with 'a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable' (quoted from the patent license itself) to all of the patents that they own, or will acquire in the future, related to VP8.

Neither indemnifies you against damages from infringing on third-party patents.

More hoops to jump through.

Yes, shockingly, you actually do need to write some code to support new features. Not much (the libavcodec implementation is about 1,400 lines of code, reusing existing decoder building blocks), but slightly more than none.

I'm going to get modded down as a troll again for saying this (even though every one of my posts on this topic has been sincere, and labelled "troll" by reactionary Slashdotters), but Google doesn't own any of the content outside of users' home videos. The RIAA, MPAA, and gave studios produce most of the content that people are interested in, and that comprises more than 10 minute clips, and they're not going to re-encode in WebM. Even Apple couldn't bring those companies to their knees so what makes you think Google will?

You've not visited YouTube recently, have you? They stream TV shows and movies (most of them only in the USA, currently), with the consent and cooperation of the studios that own them. Google provides all of the infrastructure for this, including the choice of format.

Re:WebM will never catch on

[Tacvek]

IE would not need a browser plugin. All they would need is the proper DirectShow/Media Foundation filters and codecs, and it would simply support WebM (it would also cause Windows Media Player, and many other windows apps to support WebM). Just like Safari would need merely need the proper Quicktime codecs, for WebM to just work.

Re:WebM will never catch on

[chowdahhead]

DSP assisted decoding was accomplished pretty quickly for Theora, so it's not a far stretch at all that the same could be done for vp8. http://blog.mjg.im/2010/04/16/theora-on-n900.html

Re:WebM will never catch on

[peppepz]

Does IE really allow untrusted bytes coming from the internet to be interpreted by an open-ended infrastructure such as the DirectShow filter system? Isn't that a security nightmare?

Re:WebM will never catch on

[arose]

A company that has successfully created video codecs for years without being sued for patent infringement (On2 that is) vs. a developer who vocally ignores patent problems and uses terms like "unlikely" to describe what in actual patents comes down to precise details?

Re:WebM will never catch on

[arose]

From the actual article...

Update: spatial intra prediction apparently dates back to Nokia’s MVC H.26L proposal, from around ~2000. It’s possible that Google believes that this is sufficient prior art to invalidate existing patents — which is not at all unreasonable!

Re:WebM will never catch on

[godrik]

(This message is offtopic and a question for TheRaven64)

I have been reading your comments on /. for sometime and I always found your post detailed and interesting. Do you happen to maintain a blog or something similar ?

Re:IS-IS

[msauve]

IS-IS is really from DECnet 5, so it didn't truly originate with the ISO, and it's also RFC 1195, so maybe it wasn't a good example. SPB (IEEE 802.1aq) is more interesting than TRILL, but also uses IS-IS.

Re:If Microsoft was doing this

[Draek]

First off Microsoft submitted the specifications for the Word format for standardization, in full and with none of that "implement this like Word 97" crap they pulled with OOXML or any patent over it whatsoever, I guarantee you half the posts would be "crap, Microsoft is actually doing something nice for a change?" with the other half being "how long until it's included in OOo?".

And secondly, there's no viable standard for online video yet so the comparison isn't apropos, the MPEG lovefest on Slashdot notwithstanding.

Re:Reminds me of Sony

[hkmwbz]

Hopefully this one will be too, so we can have a clear standard, rather than a divided MPEG v. VP8 internet.

H264 is closed, and not compatible with an open web. The winner needs to be VP8, or the web will be less open.

Remember the details of OOXML certification?

[walter_f]

That's current "ISO style", regrettably.

ISO has severely compromised itself by following no standards at all, when certifying certain proposals as a "standard".

I understand Google wanted to stay clear of such an extra-corrupt "standards body" that works under close control by one of Google's main competitors.

Re:If Microsoft was doing this

[Burpmaster]

The Google lovefest on Slashdot is clouding your judgement.

Go ahead and tell yourself that, but in reality, preconceived stereotypes are clouding your judgment.

Haven't you noticed by now that a lot of people on Slashdot are against software patents? That they don't like money being forcibly removed from their wallets just because they tried to give something freely to the world? And that many like to be able to use a Free Software desktop without being treated like second-class citizens due to frivolous IP nonsense?

Put two and two together, man. It's pretty clear why H.264 is bad and WebM is good. It's the license fees, stupid! You're either so biased you create strawman motivations for people before you can realize even the most obvious facts about their real motivation, or you're so stupid that such simple inferences are difficult for you. So which are you, biased or stupid?

Re:If Microsoft was doing this

[nathanh]

Haven't you noticed by now that a lot of people on Slashdot are against software patents?

Most people on Slashdot these days are obnoxious. That's why Slashdot has lost most of its good commenters.

... stupid! You're either so biased ... you're so stupid... So which are you, biased or stupid?

Case in point.

You go ahead and keep destroying Slashdot, one comment at a time. Just keep insulting people who disagree with you by calling them "stupid". Then you can turn Slashdot into your own little echo chamber where the only valid opinions are ones like yours. One more dissenting opinion leaves today, this time for good.

Re:WebM will never catch on

[TheRaven64]

Not at the moment. I post quite often on the Étoilé blog, although I haven't posted there since October, apparently. I also write quite regularly for InformIT (their stupid new UI means I can't link directly to the articles list, you have to click on the articles tab from that link). I used to blog on theravensnest.org, but I never got around to reinstating the blog after I moved servers ages ago. I'll probably get around to it eventually...

Re:WebM will never catch on

[hkmwbz]

independent

LOL.

Re:If Microsoft was doing this

[drinkypoo]

If Microsoft did this very thing, would you be rejoicing the move or would you be screaming bloody murder?

He's been asked and hasn't answered. Now you have been asked.

No, I answered the actual question. When Google takes an action that looks suspicious but could benefit everyone, they are probably doing something that will benefit everyone, as suggested by prior performance. When Microsoft does something that looks suspicious but could benefit everyone, they are without exception doing something that will benefit them and fuck everyone else over. We don't know for sure what their goals are yet, and this action could turn out to be positive or negative. As I stated previously it would be rational to assume that it was evil if it were Microsoft, because of their track record, which is overwhelmingly negative. Google's track record is overwhelmingly positive. I'll give them the benefit of the doubt where I won't give it to Microsoft. If you can provide some sort of evidence that the opposite makes more sense, then I'll eat my hat.

Re:If Microsoft was doing this

[gmhowell]

If Microsoft announced a non-patent encumbered (to the best of their knowledge) codec and released the specification of the format to the IETF, we would not be screaming bloody murder.

I'd be out in the streets, speaking in tongues, for surely if this happened, the rapture would be upon us.

Re:If Microsoft was doing this

[hkmwbz]

If microsoft was doing what google is attempting to do we would all be screaming bloody murder

Why? Releasing something with an irrevocable royalty-free license is not a bad thing to do at all.

Re:WebM will never catch on

[hkmwbz]

SCO was about non-existent copyright rights and claims. MPEG-LA has real patents on video formats and compression.

So you are saying that SCO had no patents or copyrights whatsoever? What utter nonsense. Of course they did. And so your logic dictates that "since SCO had real patents, any claim they make about patents must be true."

2) Google hasn't offered to indemnify anybody, as MPEG-LA has. That shows Google has little to no confidence in WebM's patent standing.

The MPEG-LA doesn't indemnify jack shit. So your logic dictatesd that the MPEG-LA has little to no confidence in H264's patent standing.

Re:WebM will never catch on

[zeroshade]

You do realize that H.264 has the same problem? If someone was waiting for the hardware encoding to reach full saturation of H.264 in everything before coming forward with a patent that covers it, then the MPEG-LA can't do anything to help anyone. Everyone would get sued for tons of money and no one could argue against it. All that is needed is a single patent that covers H.264. Thus, H.264 is also a ticking time bomb, why shouldn't people stay away from it?