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.

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?

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

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

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

[Kitsune Inari]

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

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

[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

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

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

[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

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