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

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?

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

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

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

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

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

[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!