Talk:VP8

References needed

This page needs references for the claims it makes. --Tegbains (talk) 07:42, 27 October 2008 (UTC)

Introductory wording

"VP8 is an open source, a proprietary video codec..." - wait, what? How can it be open source and proprietary at the same time? That makes no sense. -- Wjbuys (talk) 08:34, 24 May 2010 (UTC)

The wording is supposed to say formerly proprietary. 86.83.239.142 (talk · contribs) changed it on the assumption that it couldn't be open source unless it was turned over to a standards body. This is incorrect, and someone else has since changed it back.
--Gyrobo (talk) 17:00, 24 May 2010 (UTC)

I can see VP8's source code. Therefore, it is open-source. The "owned by Google" part further on the sentence describes what you want to say. —Preceding unsigned comment added by DanimothWiki (talk • contribs) 18:11, 25 May 2010 (UTC)

VP8 is a video compression format.

• It is proprietary which means that Google alone holds exclusive rights to VP8. VP8 is not placed in the public domain or handed to a standardization organization like h.264 or VC-1 which are public standards for which the copyrights belong to those standardization organizations. Google alone controls improvements or new versions of VP8.
• It is an open format because the specification is available free for anybody and Google has promised irrevocably to not assert its patents against users and implementers in its VP8 bitstream format specifcation license. http://www.webmproject.org/license/bitstream/
• The codec software which Google released under different license (a BSD like license is just an implementation of VP8. That is implementation is the only part that is released as an open source codec. It does not make VP8 open source but makes for at least one open source VP8 implementation.

So concluding VP8 is a proprietary video compression format, it is an open video compression format and it has at least one open source implementation. 86.83.239.142 (talk) 06:01, 26 May 2010 (UTC)

I think it would be useful to have the VP8 license (from the specification) right here for reference:

“ Google hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise implementations of this specification where such license applies only to those patent claims, both currently owned by Google and acquired in the future, licensable by Google that are necessarily infringed by implementation of this specification. If You or your agent or exclusive licensee institute or order or agree to the institution of patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that any implementation of this specification constitutes direct or contributory patent infringement, or inducement of patent infringement, then any rights granted to You under the License for this specification shall terminate as of the date such litigation is filed. ” — Google, Inc., VP8 Data Format and Decoding Specification

This license section does state that implementations are irrevocably royalty-free (unless you sue someone over VP8 patents). However, the copyright section makes it clear that the specification itself is available under a Creative Commons — Attribution 3.0 Unported license. It's open.
--Gyrobo (talk) 14:47, 26 May 2010 (UTC)

So Microsoft could adapt VP8 if they wanted to and it still be VP8? Or can only Google do that. The simple answer is that only Google can do that. If anyone else would alter VP8 specification it would not be VP8 anymore. If Google/On2 adapts the VP8 spec everybody has to follow to stay in line with VP8. that is what makes it proprietary. The control Google has over the format of VP8. Google could change the spec tommorrow and nobody would be able to do anything about it. 86.83.239.142 (talk) 18:03, 26 May 2010 (UTC)

That's true of any format that isn't in the public domain. There's a difference between open source and public domain.
--Gyrobo (talk) 19:55, 26 May 2010 (UTC)

No, that is the definition of proprietary. Controlled by a single company. So this format is both proprietary controlled and open at the same time. 86.83.239.142 (talk) 21:54, 26 May 2010 (UTC)

If you took any format (including one in the public domain) and altered it, it would, by definition, be a something else. Open source describes practices in production and development that promote access to the end product's source materials. Proprietary software is the oppose of that. The VP8 specification is publicly available under an open license. Implementations of VP8 are available under an open license. The format is open. Formats can be open without the backing of a standards body, and there is nothing in Google's licensing of VP8 to prevent someone from extending VP8 in a way that is backwards-compatible with VP8 decoders.
--Gyrobo (talk) 22:26, 26 May 2010 (UTC)

You are putting VP8 on the level of open source software. That however is a mistake. It is a video compression format. Only the VP8 codec implementation that gogole has released is open source. That no longer is controlled by Google. The V8 video compression format however is still controlled by a single company. Therefore the format is proprietary. Describing VP8 as open source is just not correct. Open source only applies to source code and not to a format. A format is either propietary, or a standard or public domain. In addition to that it can be either closed or open (or something in between). However a format can not be open source. Describing the VP format therefore it is both "open" and "proprietary". It is not "open source". The VP8 codec implementation google has released should of course be described as open source. 86.83.239.142 (talk) 05:45, 27 May 2010 (UTC)

It is open source. The specification for the format is publicly available, under a fairly permissive CC license that allows dissemination and alteration. This meets the definition of open source. The level of control a company exerts on a format has no bearing over whether it is proprietary or open source, only the availability and licensing terms of the source code.
--Gyrobo (talk) 14:27, 27 May 2010 (UTC)

No it is not open source. Open source is source code with an Open source licence which is maintained trough a collaborative process. The VP8 format is not software source code nor does it have an open source license. The format is maintained by a single company. It is a format specification with a irrevocable patent license from google. It is already very generous to name it an open format as the wikipedia article on open format considers such an open format to typically be under the control of a standards organization which VP8 is clearly not. 62.58.36.58 (talk) 14:55, 28 May 2010 (UTC)

The definition you have provided for an open source license is, in its entirety, wrong. A license doesn't need a stamp of approval from OSI or any other such organization to be considered open source, and the level of control a company exerts over the development of a publicly-available specification has no bearing on its status. The source for a VP8 implementation and its specification is publicly available under a permissive license. That makes it open.
--Gyrobo (talk) 21:35, 28 May 2010 (UTC)

For the above discussion here a citation that suggest the format should indeed be called proprietary. http://www.robglidden.com/2010/05/how-googles-open-sourcing-of-vp8-harms-the-open-web/ 86.83.239.142 (talk) 12:55, 29 May 2010 (UTC)

Misleading phrasing

The article states: This made VP8 the second product from On2 Technologies to be open-sourced to the free software community following the 2001 release of the older VP3 codec, which was later donated (under the BSD license) to the Xiph.Org Foundation as the Theora codec

This phrasing is very misleading as the control over the VP3 format was actually handed by On2 to an independant organization of OSS developers (xiph). The VP8 format is still owned by Google/On2 and is not handed over to an independant open source organization. 62.58.36.58 (talk) 15:02, 28 May 2010 (UTC)

I found some refs that I think resolve this. Is this acceptable?
--Gyrobo (talk) 18:18, 28 May 2010 (UTC)

Features

From http://webmproject.blogspot.com/search/label/vp8 and http://x264dev.multimedia.cx/?p=377 .

As with other codecs an initial Macroblock pass is initially run. Each block is then compared to blocks in the same frame (intra-prediction) and previous reference frames (inter-prediction) to produce a Motion_vector for it. A reference frame can be one of three types: The previous frame, the alternate reference frame (which itself is not shown and may consist of blocks from many different frames at the encoder's whim) and the golden frame (one frame worth of decompressed data from the arbitrarily distant past).

144.32.81.88 (talk) 11:38, 27 August 2010 (UTC)

Format != Implementation

The article should be only about VP8 as a format. It should not include detailed information about libvpx, because that's one implementation of VP8, and other implementations will be coming (like xvp8, VP8 encoding in x264). libvpx should have its separate article. For example, Wikipedia has an article talking purely about H.264 as a format, and it also has separate articles on implementations like x264. —Preceding unsigned comment added by 2.90.131.86 (talk) 07:51, 14 February 2011 (UTC)

This article is short enough as it stands, there's no point in splitting out implementations, they are covered in just a few sentences. It can be split out in the future. -- intgr [talk] 01:14, 15 February 2011 (UTC)

That's true, but problem is that points of criticism of the implementation might be understood as drawbacks of the format itself.2.90.131.86 (talk) 03:19, 15 February 2011 (UTC)

As I said at the bottom of the talk page: at the moment there is no other implementation, so WP:CRYSTAL. And a codec without a decoder is nothing, so why not including a comparison? The reader, who read such (whole) technical articles, won't misunderstand the differences. And the time will come and show if the speed problem is from the codec or the implementation! mabdul 22:02, 17 February 2011 (UTC)

VP8 now has a new, independent decoder (ffvp8) other than the one released by Google (libvpx), and according to its developers, ffvp8 is faster than ffh264 (the only serious free H.264 decoder available that is used in VLC, mplayer, and codec packs like K-lite and CCCP). It is also faster than Google's decoder (libvpx). VP8 encoding in x264 is now under development, and it will have similar encoding speed to x264, if not faster. The article that is being referenced is done by Jason when there was only 1 implementation of VP8, therefore instead of referring to it as "libvpx" he referred to it as "VP8" because, at that time, libvpx was the only implementation of VP8. So, what he was criticizing by having bad encoding speed, bad quality.. etc was libvpx. If you don't believe this, you can ask him personally. You can find him on IRC at #x264 @ irc.freenode.net. He goes by the nickname Dark_Shikari.

DO you have any reference for the speed(s)? mabdul 23:38, 17 February 2011 (UTC)

sigh... Why do I have to swim against these massive waves of ignorance? If you know nothing about a subject, then don't frigging interfere with edits. Reference is the guy who wrote half of the decoder, he told me himself. Go ask him for yourself.

That is WP:OR. If he puts a blog with his statements online, then we can include this in th article. Nevertheless then there should be a new speed comparison and this fact should be noticed to the article. So that there are only two decoders, why not integrating that the main original decoder was(is?) slow with bad quality? On the other hand: removing my comments from the talk page is not the fine way... mabdul 00:55, 18 February 2011 (UTC)

It would be very easy to specify in the article that the reference is talking about implementations of the specification. And since there is only the one implementation, it makes sense to include all information about both the specification and implementation in the same article.
--Gyrobo (talk) 00:58, 18 February 2011 (UTC)

There are 2 implementations of decoders, and currently 1 encoder implementation (another one is being worked on, not yet released)

And none of those implementations have enough content to merit splitting them into separate articles. All VP8-related information should be kept in this article until the article's size becomes unwieldy. We don't need to fracture this topic.
--Gyrobo (talk) 01:18, 18 February 2011 (UTC)

I agree, but until the article has enough literature to warrant a split, it should be made clear what is being compared with what; inaccuracies and falsehood aren't appreciated by anyone. If a new article about libvpx cannot be created yet, then a section about libvpx is good temporary solution. If Jason's criticism is included in that section, it will be clearer that the criticism is not for the format, but libvpx.

Yes, that's what I'm saying, that the article should differentiate between implementation and specification, and that it should include information about both.
--Gyrobo (talk) 01:38, 18 February 2011 (UTC)

Future

This article needs a "Future" paragraph discussing what is being worked on inside the scope of this format. If on2 is still working on a successor , if google is or if independent parties are.