Linked by boulabiar on Tue 6th Jul 2010 16:32 UTC
Multimedia, AV 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.
Order by: Score:
Just as expected...
by madcrow on Tue 6th Jul 2010 16:57 UTC
madcrow
Member since:
2006-03-13

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.

Reply Score: 5

Comment by mtzmtulivu
by mtzmtulivu on Tue 6th Jul 2010 17:16 UTC
mtzmtulivu
Member since:
2006-11-14


In HDTV for example, VP8 performed similar to x264 (considered the best implementation of h.264 by previous comparisons)


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?

Reply Score: 6

RE: Comment by mtzmtulivu
by boulabiar on Tue 6th Jul 2010 17:24 UTC in reply to "Comment by mtzmtulivu"
boulabiar Member since:
2009-04-18

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.

Reply Score: 2

RE[2]: Comment by mtzmtulivu
by mtzmtulivu on Tue 6th Jul 2010 17:42 UTC in reply to "RE: Comment by mtzmtulivu"
mtzmtulivu Member since:
2006-11-14

vp8 here mean the codec OR the encoder.

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


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

Reply Score: 6

RE[3]: Comment by mtzmtulivu
by MamiyaOtaru on Wed 7th Jul 2010 01:11 UTC in reply to "RE[2]: Comment by mtzmtulivu"
MamiyaOtaru Member since:
2005-11-11

Using the same name for both a codec and an encoder/decoder

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

Reply Score: 6

RE[3]: Comment by mtzmtulivu
by J. M. on Wed 7th Jul 2010 01:32 UTC in reply to "RE[2]: Comment by mtzmtulivu"
J. M. Member since:
2005-07-24

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.

Reply Score: 14

RE[4]: Comment by mtzmtulivu
by mtzmtulivu on Wed 7th Jul 2010 02:20 UTC in reply to "RE[3]: Comment by mtzmtulivu"
mtzmtulivu Member since:
2006-11-14

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.

Reply Score: 4

RE[5]: Comment by mtzmtulivu
by J. M. on Wed 7th Jul 2010 08:52 UTC in reply to "RE[4]: Comment by mtzmtulivu"
J. M. Member since:
2005-07-24

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.

Reply Score: 2

RE: Comment by mtzmtulivu
by tux68 on Tue 6th Jul 2010 17:32 UTC in reply to "Comment by mtzmtulivu"
tux68 Member since:
2006-10-24

a terrible encoder can produce terrible files from an excellent codec. Isnt it unfair to judge a codec based on what encoders do?


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.

Reply Score: 7

RE: Comment by mtzmtulivu
by Quikee on Tue 6th Jul 2010 18:08 UTC in reply to "Comment by mtzmtulivu"
Quikee Member since:
2010-07-06

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

Reply Score: 8

RE[2]: Comment by mtzmtulivu
by umccullough on Tue 6th Jul 2010 18:53 UTC in reply to "RE: Comment by mtzmtulivu"
umccullough Member since:
2006-01-26

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).


and FTA:

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.


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.

Reply Score: 3

times, not percent
by martinus on Tue 6th Jul 2010 19:51 UTC
martinus
Member since:
2005-07-06

The article says 5-20 *times* slower with 10-20% better quality compared to Xvid...

Reply Score: 3

RE: times, not percent
by boulabiar on Tue 6th Jul 2010 19:59 UTC in reply to "times, not percent"
boulabiar Member since:
2009-04-18

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"

Reply Score: 1

RE[2]: times, not percent
by galvanash on Tue 6th Jul 2010 21:52 UTC in reply to "RE: times, not percent"
galvanash Member since:
2006-01-25

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)

Reply Score: 2

RE[2]: times, not percent
by stippi on Sun 11th Jul 2010 16:27 UTC in reply to "RE: times, not percent"
stippi Member since:
2006-01-19

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.

Reply Score: 1

Wow
by deathshadow on Tue 6th Jul 2010 23:02 UTC
deathshadow
Member since:
2005-07-12

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?

Reply Score: 5

RE: Wow
by ggeldenhuys on Wed 7th Jul 2010 12:28 UTC in reply to "Wow"
ggeldenhuys Member since:
2006-11-13

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

Reply Score: 1

RE[2]: Wow
by Soulbender on Sat 10th Jul 2010 07:24 UTC in reply to "RE: Wow"
Soulbender Member since:
2005-08-18

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

Reply Score: 2

Some questions
by diegoviola on Wed 7th Jul 2010 03:42 UTC
diegoviola
Member since:
2006-08-15

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

Reply Score: 3

RE: Some questions
by mtzmtulivu on Wed 7th Jul 2010 04:13 UTC in reply to "Some questions"
mtzmtulivu Member since:
2006-11-14

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?


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

Reply Score: 5

RE: Some questions
by lemur2 on Thu 8th Jul 2010 13:05 UTC in reply to "Some questions"
lemur2 Member since:
2007-02-17

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?


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

Reply Score: 3

RE[2]: Some questions
by diegoviola on Thu 8th Jul 2010 14:59 UTC in reply to "RE: Some questions"
diegoviola Member since:
2006-08-15

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

Reply Score: 2

RE[3]: Some questions
by lemur2 on Thu 8th Jul 2010 23:49 UTC in reply to "RE[2]: Some questions"
lemur2 Member since:
2007-02-17

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

Reply Score: 2

RE[3]: Some questions
by lemur2 on Fri 9th Jul 2010 03:54 UTC in reply to "RE[2]: Some questions"
lemur2 Member since:
2007-02-17

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


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

Every video on YouTube will be transcoded into WebM. They have about 1.2 million videos available today and will be working through their back catalog over time. But they have committed to supporting everything.


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.

Reply Score: 2