Slashdot Mirror
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.'"
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.
FOX NEWS.com should be BANNED from television and internet. Have the Congress take it over and give us Truespeak.
Is there any significance to the fact that Google chose IETF instead of ISO (where MPEG-LA and M$ submitted H.264 and OOXML)?
I'm not a lawyer, but I play one on the Internet. Blog
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.
Do daemons dream of electric sleep()?
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?
Why?
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.
3) Mobile hardware has H.264 compatibility built-in, not so for WebM,
4) The media companies have encoded their content in H.264, they can't be bothered to re-encode it to WebM.
This is the same reason that Linux won't catch on on the desktop (arguably, the only reason). Media companies (RIAA, MPAA, and game publishers) will never support these open formats (OGG Vorbis, OGG Theora, WebM). The developers of the closed formats (MP3, H.264, GIF) will insist on getting paid one way or the other, which means their formats can't be natively supported by an open source OS.
This space left intentionally blank.
If microsoft was doing what google is attempting to do we would all be screaming bloody murder
did you forget to take your meds?
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.
It should be noted that IS-IS is the protocol used for TRILL/routing bridges. TRILL is being done under the auspices of IETF (see RFC 5556.)
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...
And good luck for this endeavor. A success here would allow us to get rid of at least a bit of patent headache.
"essentially the entire VP8 data stream is encoded using a boolean entropy coder."
Well, duh.
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.
coding is life
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
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?
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Since when? Last I heard, YouTube had increased the limit to 15 minutes for non-Partner videos.
Of course, Blu-Ray was announced before HD-DVD...
If you can't convince them, convict them.
It's easy to say unfalsiable stuff like that, since Microsoft never has and never will do anything like this.
While you people make your purely-based-on-faith claims that people would scream bloody murder if Microsoft got friendlier toward software interoperability, meanwhile here in the land of science, progress marches on.
You're making a strawman argument that if Microsoft had done the same thing as Google we would still not trust them.
It's a strawman argument because Microsoft DOES NOT do the same things as Google. Have you not kept track of the whole story behind OOXML and ECMA (which is an *INDUSTRY* standard, most certainly PATENT ENCUMBERED) and ISO? Have you not kept track on the licensing restrictions of implementing .NET by anyone other than MICROSOFT? What about silverlight? Microsoft has a TRACK RECORD of screwing everyone else. They are always looking out for #1, and that's them. After watching their game play for 20 years they've me convinced of one thing: They believe life is a zero sum game and they're going to do everything they can to win.
If you're not a shill, or a troll, and are honestly ignorant of the whole situation, then do yourself and everyone else a favor and do some research on Microsoft. Start with wikipedia. Look up the history on Internet Explorer/Spyglass, cpu licensing, banning of multiboot, DrDos, "Lotus won't run", Windows vs. OS Warp, the original author of QDOS and how he was screwed, Paul Allen and how he was screwed, Corel and how they were screwed, AOL and frickin' stupid desktop icons and how they were screwed, the antitrust lawsuit and Mr. Gates wonderful performance on video, the whole tie in with Internet explorer into the operating system, the doctored videos claiming internet explorer couldn't be removed, the attempt to pervert Java and screw Sun first and then the whole world as result, the whole screw Netscape thing, the games they played with funding SCO, the Halloween documents, screw the Tawainese vendors so they wouldn't put Linux on the netbooks, it's a long litany of screw, screw, screw everyone else.
And after you've done your proper research, please don't ever attempt to compare Google with Microsoft in terms of Evil. It's insulting and offensive.
Apparently, dropping H.264 support in Chrome was a decision taken by the Chrome Engineering team and not a decision from the top level. Youtube and Android are never going to drop support for H.264. http://www.guardian.co.uk/technology/blog/2011/jan/19/google-h264-webm-video-answers
H264 is closed, and not compatible with an open web. The winner needs to be VP8, or the web will be less open.
Clever signature text goes here.
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.