OSNews

vp8 here mean the codec OR the encoder.

when we speak about it, we speak about the implementation owned now by Google.

The other unique implementation is discussed in the same article just after.

Using the same name for both a codec and an encoder/decoder will lead to unnecessary confusion and misinformation. Google's implementation of the codec is in libvpx. IMHO, it will be best if "vp8" name be used only for the codec and "libvpx" name be used for google's reference implementation of the codec.

http://en.wikipedia.org/wiki/VP8

yeah it sure is weird to use the same name for a codec and an encoder/decoder

What actually leads to confusion is the constant mixing of the words codec and format.

A codec, by definition, is "a device or program" that encodes and decodes data. The word "enCOder/DECoder" (or "COmpressor/DECompressor") directly implies its active role - a codec actually DOES something. Encodes and decodes. A codec is an implementation (software or hardware) of a specification.

A format, by contrast, is not a codec. A specification is not a codec. Formats and specifications do not do anything. Formats and specifications do not encode and decode data. Formats and specifications are not devices or computer programs. Formats and specifications describe how to make devices and programs (that encode and decode data).

libvpx is a codec. VP8 is a format. Xvid is a codec (a software library). MPEG-4 ASP is a format. H.264 is a format, a specification. Not a codec. And so on.

+1

I wish everybody would see this comment. It explains the difference perfectly and i wish everybody read this comment, understand it and start using appropriate names when discussing codecs and formats, too bad you didnt add containers in your comment because there is also a confusion btw formats and containers.

Speaking of which, there's also a difference between a container and a container format. :-) A container contains data, a container format is a way of storing data. For example, AVI, Matroska and Ogg are container formats, not containers.

What you're asking is theoretically true -- but not very practical. It doesn't much matter how intellectually beautiful or elegant a codec is until it has been implemented and put to use in an encoder.

Measuring encoder performance and quality shows the current state of the art, and demonstrates the practical realities of employing a codec rather than some theoretical ideal.

To switch back to your html example... a new html tag is of no practical use to anyone unless it is usably implemented by browsers.

No.. codec means COder (encoder) / DECocder which means an encoder is only part of a codec but in both cases it means the implementation.

x264 is an encoder which implements h.264 / Mpeg4 AVC specification. libvpx and the ffmpeg VP8 codec are codecs which implements (or conform to) VP8 specification (in this case the VP8 was written after libvpx was implemented). libtheora is a codec library which implements Theora specification which is backwards compatible with VP3 "specification". xvid and divx are both codecs that implements Mpeg-4 ASP specification...

Edited 2010-07-06 18:09 UTC

and FTA:



Just to be clear here - FFMpeg only implemented the *decoder* for VP8, not an encoder. They only guarantee that the raw video output of their decoder produces "binary compatible" video (as in, what the user sees on the screen is currently pixel-for-pixel identical to Google's decoder).

They have not yet implemented a VP8 encoder - and that's where the real beef is.

The exact part from the article :
"When comapring VP8 and x264 VP8 shows 5-20 lower encoding speed with almost the same quality, excluding x624 High-Quality preset. The results for HDTV"

Its actually compared to both in the article, once to xvid and once to x264. The _actual_ percentage of encoding speed (if you do the math) are:

VP8 Encoding Speed relative to xvid:
20% best case
4% worst case

VP8 Encoding Speed relative to x264:
20% best case
5% worst case

So it is a bit slow (to put it mildly)

Please fix the article, it's indeed 5 to 20 *times* slower. That's quite a difference from 5 to 20 percent! You can also easily confirm this by what you quote from the article and also from the graphs.

:-) I was thinking the exact same think. The TOC on the right covers the content and you can't even minimize or move the TOC layer out of the way. Luckily I have a widescreen display, so had to resize the browser window to actually be able to read the contexts. What idiots!

So the question is, why should we take their word on VP8 when they can't even get simple web design right?

Firefox 4.0 will have VP8/webM support build in.

Google encode all new videos in h.264 and vp8 and will re-encode all existing videos to vp8.

yes, it will be possible to watch youtube videos in vp8 in future versions of firefox(starting with version 4.0).

Not all videos are encoded in this format and it is a hit and a miss thing at a moment. YOu will have to enable html5 page in youtube if you want to be served with videos without flash, the sign up page is http://www.youtube.com/html5

YOu will get a flash based video if your browser doesnt not support html5 video tag or the video is not yet encodec in a format your browser supports.

Firefox 4.0 beta just came out and it supports vp8: http://www.pcworld.com/article/200603/mozilla_launches_firefox_4_be...

Edited 2010-07-07 04:22 UTC

On my system which runs Kubuntu x86_64, I have Mozilla Firefox version 3.7a6pre installed, and also Google Chrome version 6.0.453.1 dev installed.

Both of those browsers support HTML5/VP8/WebM.

To enable it for YouTube, navigate to this page using either Firefox or Chrome pre-release browsers:

http://www.youtube.com/html5

Click on the "Join the HTML5 Beta" link.

Browsing around some random Youtube videos currently shows perhaps 10% of them come up in HTML5/WebM format. This is not just for current videos, since I can see an Avatar trailer and even a few Firefly videos in HTML5.

http://www.youtube.com/watch?v=d1_JBMrrYw8
(August 22, 2009)

http://www.youtube.com/watch?v=xNhzjzH5XBE
(July 29, 2007)

http://www.youtube.com/watch?v=gRo0Sw4q6HI
(July 25, 2006)

http://www.youtube.com/watch?v=TkY9HtwXNU8
(August 24, 2008)

http://www.youtube.com/watch?v=_45W-Lq7ftw
(December 17, 2006)

http://www.youtube.com/watch?v=lQN9gr-Hb_Q
(May 11, 2007)

Edited 2010-07-08 13:24 UTC

When is Google going to re-encode all their videos in VP8/WebM? And when are they going to make HTML5 the default?

Some videos which were posted to YouTube as far back as 2006 have been converted already. On a very rough and ready sampling the indication is that perhaps 10% of YouTube videos have been converted already.

WebM is still very new, and the only browser implementations of it AFAIK are Opera 10.60 and pre-release versions of Firefox 4 and Google Chrome. Although the decoder is OK, the WebM encoder has not yet been optimised and hence is still very slow (many times slower than x264). All of this means that until the encoder is optimised, it will take a while for the majority of YouTube's video stock to be converted to WebM, and there are hardly any stable browsers that can render it yet anyway.

Having said that, Google already have an implementation of WebM for Directshow, and I am sure that they are working on a version that users can install which will work with IE9:

http://news.softpedia.com/news/IE9-HTML5-Video-VP8-Codec-Support-vi...

Versions of Google Chrome and Firefox 4 that will support WebM will be available to the public later this year, in the same timeframe as IE9.

I am sure that Google are also working on optimising VP8 encoder speed, and at the same time using the existing, slower encoder to convert existing YouTube videos.

Perhaps by the end of this year people will be able to choose HTML5/WebM as their preference for YouTube video. I doubt that it will become the site default until some time after that point, though.

Edited 2010-07-08 23:50 UTC

http://hacks.mozilla.org/2010/05/firefox-youtube-and-webm/



It doesn't say when this transcoding to WebM might be finished by, but it does at least back up the level of commitment to WebM by Google/Youtube.

As far as I can tell, just a few weeks after announcing WebM, Google/Youtube have already made a reasonable start on the process.