Guest post by After Google announced the open sourcing of the VP8 codec and provided it free-of-charge, there was a lot of discussion around the quality of the codec. However, the few studies that tried to back up the discussion with hard data didn’t base their investigations on large amounts of data. None tried the comparison with multiple input files and provided results according to the numerous standard quality metrics. Every year, the MP4-Tech experts group compare every h.264 implementation in order to track performance and quality improvements. Yesterday, The Graphics and Media Lab of Moscow State University published a new, deep study of the performance of VP8, x264 and XviD implementations.Their message on the group can be found here It’s unusual that they would test a codec other than h.264 but they did with vp8 and they prove that results are respectable in many areas.
In HDTV for example, VP8 performed similar to x264 (considered the best implementation of h.264 by previous comparisons) but with 5-20% lower encoding speed. Comments from VP8 developers say that “old comparisons results have an inherent bias against VP8 because input sequences were previously encoded using another codec before being applied to VP8”.
These results can improve very quickly with optimizations, and the Russian lab hasn’t yet tested implementations of VP8 other than the one provided by Google developers. Ronald Bultje, David Conrad, and Jason Garret-Glaser, x264 developers, are now creating a native VP8 video codec implementation for the open source FFmpeg project. Ronald says in his blog that they already did that with only 1400 lines of code (including whitespace, comments and headers) because they have many bricks already coded.
The way seems widely open for the WebM Project to provide a truly free, high quality codec for the world and the FFmpeg team don’t seem likely to lose their position as best implementors of codecs.
It seems like VP8 performs better than the old MPEG-4 ASP codecs like XviD but not as well as newer AVC-based codecs like x264. This test just confirms what most of us were expecting all along.
VP8 is a codec, x264 is an encoder, not a codec ( http://en.wikipedia.org/wiki/X264 )
People seem to mix a lot codecs and encoders and i just dont understand how different encoders can be used to measure how good/bad a codec is, i mean, do people measure how good/bad html is based on how good/bad browsers implement it?
a terrible encoder can produce terrible files from an excellent codec. Isnt it unfair to judge a codec based on what encoders do?
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 article says 5-20 *times* slower with 10-20% better quality compared to Xvid…
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.
That has to be the most horribly broken poorly designed website I’ve seen in quite a while…
Can anyone post the results on a website that actually works?
🙂 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?
Is Google using VP8/WebM in YouTube already?
Will future versions of Firefox support VP8/WebM?
Are we going to be able to see YouTube videos in HTML5/VP8/WebM with Firefox?
Edited 2010-07-07 03:43 UTC
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.