×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

VP8 and H.264 Codecs Compared In Detail

timothy posted more than 3 years ago | from the you-can-only-get-so-much-detail-though dept.

Google 170

An anonymous reader writes "Moscow State University's Graphics and Media lab have released their sixth MPEG-4 AVC/H.264 video codecs comparison. Also of note is a recently added appendix to the report which compares VP8, x264, and Xvid. The reference VP8 encoder holds its own against x264 despite the source material offering x264 a slight advantage. The VP8 developers comment in the report: 'We've been following the MSU tests since they began and respect the group's work. One issue we noticed in the test is that most input sequences were previously compressed using other codecs. These sequences have an inherent bias against VP8 in recompression tests. As pointed out by other developers, H.264 and MPEG-like encoders have slight advantages in reproducing some of their own typical artifacts, which helps their objective measurement numbers but not necessarily visual quality. This is reflected by relatively better results for VP8 on the only uncompressed input sequence, "mobile calendar."'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

170 comments

RTFA?? -- I think I'll wait for the movie (0, Funny)

Anonymous Coward | more than 3 years ago | (#32832160)

RTFA?? -- I think I'll wait for the movie

Re:RTFA?? -- I think I'll wait for the movie (-1)

Anonymous Coward | more than 3 years ago | (#32832416)

It looks more like an advertisement.. so I guess this would be the previews before the movie?

fisrt psot (-1, Troll)

Anonymous Coward | more than 3 years ago | (#32832170)

frist post

In the real world (5, Insightful)

DrXym (126579) | more than 3 years ago | (#32832184)

Input content *will* usually have been compressed with H264. Even the likes of Google will find itself transcoding 99% of its content into VP8 from some other codec. That might suck for comparison tests but its a fact of life.

Re:In the real world (2, Insightful)

TheKidWho (705796) | more than 3 years ago | (#32832310)

For now at least.

Re:In the real world (4, Informative)

westlake (615356) | more than 3 years ago | (#32833126)

For now at least.

You have to be realistic.

H.264 isn't just about the cell phone phone and the web.

It's a broadcast, cable and sattelite video standard, a Blu-Ray standard. It is deeply entrenched in industrial and security video.

A search of Google Shopping for "H.264" will return 40,000 hits.

There are 847 AVC/H.264 Licensees [mpegla.com]

The Asian industrial giants like Mitsubishi are very well represented.

Re:In the real world (0)

Anonymous Coward | more than 3 years ago | (#32833360)

And there's almost two billion chinese trying to make hardware that doesn't infringe pattens so they can sell obscenely cheaper here in the west.

10 cents a dance (2, Informative)

westlake (615356) | more than 3 years ago | (#32833760)

And there's almost two billion chinese trying to make hardware that doesn't infringe pattens so they can sell obscenely cheaper here in the west.

The manufacturer's license for H.264 is $0 - for sales of 100,000 units or less each year.

20 cents a unit - for sales of 100,001 to 5 million units a year.

10 cents a unit - for sales above 5 million a year.

With an "Enterprise Cap" of $5 million a year.

SUMMARY OF AVC/H.264 LICENSE TERMS [mpegla.com]

The Korean Samsung Group - for comparison - has about a quarter of a million employees and annual revenues of $170 billion.

Re:In the real world (2, Insightful)

shutdown -p now (807394) | more than 3 years ago | (#32833788)

Since when did Chinese hardware manufacturers cared about patents? And yet, they seem to be selling DVD players that completely ignore CSS, region coding etc here in the West just fine...

Re:In the real world (3, Informative)

prockcore (543967) | more than 3 years ago | (#32833808)

It's a broadcast, cable and sattelite video standard, a Blu-Ray standard. It is deeply entrenched in industrial and security video.

Except that in the US at least, the only one of those things that use it is BluRay. Broadcast, Cable, and Satellite still use mpeg2. Even many Blu-Ray's use mpeg2.

Re:In the real world (2, Interesting)

westlake (615356) | more than 3 years ago | (#32834008)

Except that in the US at least, the only one of those things that use it is BluRay.

...and every camcorder among the 40,000 items you'll discover in a quick search of Google Shopping for H.264 video.

YouTube receives 24 hours of amateur video every minute of every day - and inevitably more and more of that video will be H.264 recorded at 720p or 1080i.

which brings us back to "for now" (3, Insightful)

KingSkippus (799657) | more than 3 years ago | (#32834480)

...Which brings us back to the "for now" part of the comment.

If you're a camcorder manufacturer, chances are you're using H.264 (and paying licensing fees to do so) precisely because it's convenient for people to upload to YouTube and otherwise muck with the video without having to transcode it. If that changes because YouTube and other mainstream sites and software support VP8, and you have the ability to offer consumers the option of doing the same thing without paying licensing fees by encoding in VP8, you'll likely do so to increase your profit margin.

Your logic here supports the chicken-and-egg scenario that MPEG is praying for: manufacturers unwilling to support a format not in common use, and a format won't get in common use because manufacturers won't support it. As Google and other companies break the cycle by convincing people that the format will come into common support, manufacturers will be more willing to jump on board, bringing consumers with them.

Re:In the real world (1, Interesting)

Lunix Nutcase (1092239) | more than 3 years ago | (#32832320)

The problem is that their statement is mostly bogus as VP8 and MPEG codecs use a transform that is basically identical. They just threw that statement out there to muddy the waters because VP8 didn't stack up.

And on slashdot (-1)

Anonymous Coward | more than 3 years ago | (#32832326)

All people will care about is which codec makes Gay Niggers from Outer Space look better. That and porn.

Re:In the real world (3, Insightful)

Jah-Wren Ryel (80510) | more than 3 years ago | (#32832406)

Input content *will* usually have been compressed with H264. Even the likes of Google will find itself transcoding 99% of its content into VP8 from some other codec. That might suck for comparison tests but its a fact of life.

That's not relevant to the point - the problem is that the tests measure how well each codec reproduces the input, but there is little value accurately to reproducing errors. So what if VP8 fudges macroblocked input? If it was macroblocked to begin with, then short of doing something crazy like xor-ing the colors, it doesn't really matter if VP8 fudges it up a little bit, its still going to look all blocky anyway.

It's also almost never H264 first (0)

Anonymous Coward | more than 3 years ago | (#32832796)

It's also almost never H264 first but MJPEG/XVid/MPEG2/etc and NOT H264. For a start, encoders for mobile phones don't have the power to encode H264 live. So the OP assertion is obviously and trivially wrong.

Re:It's also almost never H264 first (2, Informative)

Lunix Nutcase (1092239) | more than 3 years ago | (#32832848)

You can do realtime, baseline H.264 encoding on Cortex A8 and A9 chips with x264.

Re:It's also almost never H264 first (1)

Svartalf (2997) | more than 3 years ago | (#32833434)

Which means you can do similar with VP8...

Re:It's also almost never H264 first (1)

RocketRabbit (830691) | more than 3 years ago | (#32833796)

Can do? Or theoretically could do if somebody spent the time making a good encoder...

When there is a nice, portable, accelerated ARM version of VP8 then you can claim what you have.

Re:It's also almost never H264 first (1)

Lunix Nutcase (1092239) | more than 3 years ago | (#32833818)

Which means you can do similar with VP8...

At a much lower quality as this comparison shows. H.264 baseline was pretty equal with VP8's maximum quality.

Re:It's also almost never H264 first (0)

Anonymous Coward | more than 3 years ago | (#32834370)

You have a very different definition of "much lower" than most.

Re:It's also almost never H264 first (3, Informative)

zim2411 (700459) | more than 3 years ago | (#32832992)

iPhone 4 records video at 10.8 Mbps baseline 3.1, 1280x720 at 29.97fps. Most of the DSLRs that shoot video, shoot in h264 and consumer cameras are increasingly switching to h264 as they dump tape based recording methods. It's nice that the authors didn't really bother trying to find properly high bitrate stuff as source materials. Oh well.

Re:It's also almost never H264 first (2, Informative)

RobertM1968 (951074) | more than 3 years ago | (#32833160)

It's also almost never H264 first but MJPEG/XVid/MPEG2/etc and NOT H264. For a start, encoders for mobile phones don't have the power to encode H264 live. So the OP assertion is obviously and trivially wrong.

Really? My team works with a lot of Prosumer cameras that output H264. There's a quickly growing amount of content on YouTube and elsewhere that's filmed on such cameras, or even their lower end brethren - which also often output in H264.

Re:In the real world (0, Flamebait)

LaRainette (1739938) | more than 3 years ago | (#32833226)

You, moronically, make it sounds like it is a law of nature where in fact it is just the the result of the pre-existence of h.264.
This is definitely something you should take into consideration when you are trying to determine which codec is best intrinsically.

Very simple (3, Insightful)

dimethylxanthine (946092) | more than 3 years ago | (#32832196)

One is an extorsion accessory, the other is not (yet).

Re:Very simple (1)

Nadaka (224565) | more than 3 years ago | (#32832668)

I am trying to figure out what extorsion is.

Re:Very simple (0)

Anonymous Coward | more than 3 years ago | (#32832774)

Extortion. So what - On2 Technologie's website doesn't validate [w3.org]. Excuse my spelling at 1 o'clock in the morning. Good night! ;-)

Re:Very simple (5, Funny)

Shark (78448) | more than 3 years ago | (#32832808)

Torsion is what you feel when someone twists your balls.

Extorsion is that lingering pain afterward.

Re:Very simple (2, Insightful)

LaRainette (1739938) | more than 3 years ago | (#32833272)

Getting money out of people using leverage you should have.

The mafia extorted money from the shop owners in the 30s, using leverage it got from the monopoly of the usage of strengh it had taken from the state authority (the police which was unable to fight the aforementioned mafia)

MPEG LA will extort money out of us and any video content provider/creator using leverage it will have gotten from abusive patents and technological monopoly reached through lobbying.

Re:Very simple (0)

Anonymous Coward | more than 3 years ago | (#32833662)

Whoosh!

Misleading statements (5, Insightful)

Lunix Nutcase (1092239) | more than 3 years ago | (#32832204)

Unfortunately their statement is very misleading considering how VP8 and H.264 and other MPEG codecs use basically the same transform so their statements of bias against VP8 ring untrue. One of the professors who was part of doing this test even confirmed [doom9.org] that the VP8 developers statement was untrue and misleading.

Re:Misleading statements (4, Informative)

unix1 (1667411) | more than 3 years ago | (#32832642)

First, that claim was made by an x264 developer. Second, that comment in itself is misleading. VP8 developers didn't claim the bias affected visual quality. Here's the exact quote:

H.264 and MPEG-like encoders have slight advantages in reproducing some of their own typical artifacts, which helps their objective measurement numbers but not necessarily visual quality.

x264 developers need to take it easy and let their implementation speak on its merits rather than attempt to discredit VP8 at every opportunity.

Re:Misleading statements (2, Insightful)

Lunix Nutcase (1092239) | more than 3 years ago | (#32832722)

First, that claim was made by an x264 developer.

And was backed up by the professor doing the test when he responded saying: "Yes, you are absolutelly right".

x264 developers need to take it easy and let their implementation speak on its merits rather than attempt to discredit VP8 at every opportunity.

Then maybe the VP8 developers need to stop making misleading statements about the capabilities of their codec?

Re:Misleading statements (2, Insightful)

unix1 (1667411) | more than 3 years ago | (#32832960)

Then maybe the VP8 developers need to stop making misleading statements about the capabilities of their codec?

I'm not convinced anything was misleading in the original comment. It was made clear they were not talking about visual quality. But there were no technical details presented on either side, so take it with a grain of salt, that's all.

On the other hand, I've seen more than one misleading claim made by x264 developers against VP8 since it was announced as WebM by Google. It's like they are on a crusade or something. Take it easy guys - your implementation is one of the best, if not the best. Just keep up the good work and try to not make it look like you are on a personal mission to bury VP8.

Re:Misleading statements (1)

Lunix Nutcase (1092239) | more than 3 years ago | (#32832968)

I'm not convinced anything was misleading in the original comment.

You mean other than their implication of a bias against VP8 that doesn't exist? Yes, other than that claim which was the heart of their comment there is nothing misleading.

Re:Misleading statements (1)

unix1 (1667411) | more than 3 years ago | (#32833196)

You mean other than their implication of a bias against VP8 that doesn't exist?

You are implying that the x264 developer's claim is a fact. I am willing to entertain the idea that there could be bias against VP8 in some metrics. However, given no other info, it stands as unsubstantiated in my mind. There's nothing misleading about that.

On the other hand, I don't buy that either x264 developer, or the professor in question, have absolute knowledge of VP8 where they have verified that there is indeed no such "slight advantage."

I don't take anything stated from those 2 comments as fact. And, I certainly don't blindly trust x264 developers' comments about VP8.

Re:Misleading statements (2, Interesting)

Aboroth (1841308) | more than 3 years ago | (#32833636)

At what point will you "buy" the claims? You aren't an expert, so you can't decide, but here we have an independent expert disputing the claim that the VP8 developers made. Why isn't this expert good enough? You just assume that they don't know enough about VP8, when this is his specialty. Why? I'm all for learning as much about a topic as possible before forming an opinion on it, but that doesn't mean you *have* to form an opinion on everything. At some point, you have to allow the specialists to do what they do. And if you have no idea what they are doing or talking about (like here), maybe you shouldn't bother being in the discussion, as you add nothing to it.

Re:Misleading statements (5, Interesting)

unix1 (1667411) | more than 3 years ago | (#32834304)

At what point will you "buy" the claims?

Is that a rhetorical question? Because it doesn't help their case that x264 developers have themselves made misleading comments about VP8 since it was introduced by Google.

here we have an independent expert disputing the claim that the VP8 developers made. Why isn't this expert good enough?

No that's not what you have. What you have is an x264 developer complaining about the comment made by a VP8 developer.

The professor replying to the complaining x264 developer agreed with the complaint but let the comments stand.

You just assume that they don't know enough about VP8, when this is his specialty. Why? I'm all for learning as much about a topic as possible before forming an opinion on it, but that doesn't mean you *have* to form an opinion on everything.

I didn't form an opinion about the claims either way, but merely stated the original VP8 comment was not misleading. It did not mislead me into anything.

The original poster of this thread, on the other hand, had actually taken the x264 developer's opinion as statement of fact when there was no evidence presented to support it. And based on that assumption, he formed an opinion that the VP8 comment was untrue.

At some point, you have to allow the specialists to do what they do. And if you have no idea what they are doing or talking about (like here), maybe you shouldn't bother being in the discussion, as you add nothing to it.

I always "love" these types of remarks where people are asked to shut up because [insert an assumption/generalization here]. If you believe I didn't add anything to the discussion, then you certainly didn't either - so why did you bother replying, or even reading to this point in this thread?

Re:Misleading statements (1)

Lunix Nutcase (1092239) | more than 3 years ago | (#32833804)

You are implying that the x264 developer's claim is a fact.

In what way is it not fact? They both use an almost identical transform of any claims of bias against VP8 when it comes to MPEG artifacts is bunk. Basically all you are doing is being contrarian with no actual facts to back it up.

Re:Misleading statements (2, Interesting)

unix1 (1667411) | more than 3 years ago | (#32834084)

In what way is it not fact?

It's a fact that it's his opinion. I saw nothing where he backed up his claim (or counter-claim) with any actual facts. And given the x264 developer hostility against VP8 ever since it was announced by Google, that kind of opinion does not hold much weight with me.

They both use an almost identical transform of any claims of bias against VP8 when it comes to MPEG artifacts is bunk.

Do they? VP8 for me produces artifacts that are visibly different from x264.

Basically all you are doing is being contrarian with no actual facts to back it up.

Really? I merely stated that the original VP8 comment was not misleading. It didn't mislead me into anything, that's for sure.

Re:Misleading statements (0)

Anonymous Coward | more than 3 years ago | (#32833868)

Then maybe the VP8 developers need to stop making misleading statements about the capabilities of their codec?

Oh go suck on your baby bottle

VP8 holds its own? (5, Insightful)

Anonymous Coward | more than 3 years ago | (#32832342)

"The reference VP8 encoder holds its own against x264 despite the source material offering x264 a slight advantage."

Um, sure, if VP8 on its "best" preset being roughly equivalent to x264 on its "high speed" preset means it's holding its own, I guess that's a fair statement.

Its future is transcoding!!! (1)

zrelativity (963547) | more than 3 years ago | (#32832382)

One important consideration is how the encoder is "set up". On2/Google has probably been tested using standard test material (such as Mobile Calendar), but does not perform so well across a wider range of material. I would like to see its performance on wide range of material, particularly slow pan with fast small objects. For these scene, it will be forced to use more SPLITMV macroblock type. This has more bit required for MVs or worse coding more Intra MBs.
Also, remember almost all new camcorder/camera are AVCHD, and TV broadcast is MPEG2/AVC. So, On2's future, if it exists, has to be good at transcoding from such source material.
**Z

Reflecting the real world (1, Insightful)

Anonymous Coward | more than 3 years ago | (#32832402)

One issue we noticed in the test is that most input sequences were previously compressed using other codecs. These sequences have an inherent bias against VP8 in recompression tests.

Then that reflects the real world. Most footage that a person shoots will be compressed anyway (during recording or in editing). The fact that VP8 still looks good after the recompression tells me that we have a real winner.

It doesn't matter how good VP8 is. (2, Interesting)

LWATCDR (28044) | more than 3 years ago | (#32832438)

It will all come down to support. Which codec has the widest support.
Even Firefox will eventually add H.264 support even if it is with a plug in.

Re:It doesn't matter how good VP8 is. (1)

hedwards (940851) | more than 3 years ago | (#32832640)

Not any more than at present. At least not until it' s freed, of patent issues. Doing otherwise would lead to either fragmentation or infinge on known Patents.

Re:It doesn't matter how good VP8 is. (0)

Anonymous Coward | more than 3 years ago | (#32833680)

That's what he meant by "even if it is with a plug in." Software distributers won't dare to infringe the patent, but telling people to download a plug in from a sane (no software patents) jurisdiction is ok, and letting users make the fateful move of infringing a patent by installing the software, is ok.

We went through all this shit with MP3. Hardly anyone can legally use MP3, and yet lots of people use MP3. Shit, remember the LZW patent? Many of us switched to zlib but there were still a lot of GIF images out there in the big world. End users are ok with violating patents.

Re:It doesn't matter how good VP8 is. (1)

shutdown -p now (807394) | more than 3 years ago | (#32833802)

Well, so far Firefox developers have been intentionally blocking extensibility for HTML5 video codecs, so any such plugin is impossible to write. Unless you are willing to fork Firefox.

Re:It doesn't matter how good VP8 is. (1)

LWATCDR (28044) | more than 3 years ago | (#32834128)

Not at on. On windows just use the Direct Show framework and use that "legal" H.264 codec. On Linux use FFMPEG framwork. OS/X Quicktime will handle it for you.
All will involve no legal issues for Firefox.

Re:It doesn't matter how good VP8 is. (-1, Flamebait)

Anonymous Coward | more than 3 years ago | (#32832654)

Opera has it, FF has it, Chrome has it. That's the three best browsers. Hmmm, IE doesn't yet and Gayfari won't while Mr. am_i_really_HIV+ is running the show.

Re:It doesn't matter how good VP8 is. (1)

Dahamma (304068) | more than 3 years ago | (#32832854)

You are correct, but I think PC browser support (which everyone seems to focus on in this "battle") is really the least important segment to worry about.

As video consumption moves more and more to mobile devices and televisions (where it should be!) it's all about hardware support, where EVERYONE supports H.264 and NO ONE (yet) supports VP8. Not to mention backend encoding, where billions has been spent worldwide on various H.264 encoders, if you count all of the real time stat muxers that the cable/sat companies use...

Re:It doesn't matter how good VP8 is. (2, Informative)

prockcore (543967) | more than 3 years ago | (#32833864)

You're thinking of it like there's dedicated h264 hardware in, say, the iPhone. There isn't. There's hardware that accelerates decoding of h264... that same exact hardware can be used to decode VP8.

Think of it like how your desktop uses SSE3 to speed up h264 decoding... SSE3 doesn't contain an h264 decoder.

Re:It doesn't matter how good VP8 is. (0)

Anonymous Coward | more than 3 years ago | (#32834032)

You're thinking of it like there's dedicated h264 hardware in, say, the iPhone. There isn't. There's hardware that accelerates decoding of h264... that same exact hardware can be used to decode VP8.

[citation needed]

Last I saw, Apple hadn't released register level specs on any iPhone, so I'm a bit curious to know how it is that you know, with great certainty, that the hardware is general enough to assist in accelerating any codec similar to H.264.

Re:It doesn't matter how good VP8 is. (1)

Draek (916851) | more than 3 years ago | (#32832932)

It will all come down to support. Which codec has the widest support.
Even Firefox will eventually add H.264 support even if it is with a plug in.

Tell me which one is more likely: Firefox adding a legally-problematic h.264 plugin to the base distribution, or Google creating a VP8 plugin for IE and publicize the hell out of it in their webpage.

Yeah.

Re:It doesn't matter how good VP8 is. (0)

Anonymous Coward | more than 3 years ago | (#32833290)

IE9 will load the system's default VP8 decoder. Ditto with H.264.

I don't use IE, but this is one lesson the other browsers (including Chrome) could learn from Microsoft. Firefox and Chrome bundle the decoders themselves, similarly to Flash. This is bad for several reasons:

1) If browsers are going to take on the role of the OS (no more media players) then it is the responsibility of the browser to utilize whichever codecs the person has installed or licensed.

2) Chrome (FFmpeg) and Flash both perform poorly at H.264 decoding. Several other decoders (CoreAVC for one) exist that provide MUCH better performance. The only alternatives will be to watch videos in IE (*gasp*) or to use a capable accelerated media player.

Re:It doesn't matter how good VP8 is. (1)

Tubal-Cain (1289912) | more than 3 years ago | (#32833292)

Third-party media players have Firefox/Mozilla plugins (VLC comes to mind). Can they make their plugins intercept and play <video>?

Re:It doesn't matter how good VP8 is. (0)

Anonymous Coward | more than 3 years ago | (#32833262)

It will all come down to support. Which codec has the widest support. Even Firefox will eventually add H.264 support even if it is with a plug in.

Firefox already has H.264 support via a plugin. It's called Flash. Firefox won't need native support for H.264 as VP8 is making steady progress in being deployed by the largest video sites in the world. The world's largest video site, YouTube, already supports VP8.

Web browsers, major video sites, and even Flash will support WebM and as a consequence it will be the format with the widest support in fairly short order.

Re:It doesn't matter how good VP8 is. (0)

Anonymous Coward | more than 3 years ago | (#32833282)

Firefox has H.264 support through a free plugin already, DivX Plus Web Player supports both DivX/MP3/AVI and H.264/AAC/MKV.

Reading Bitrate/Quality Graphs (5, Insightful)

Anonymous Coward | more than 3 years ago | (#32832458)

I don't understand the "VP8 holds its own against x264".... The graphs show that it certainly does not hold it's own against x264. For example, if you look at the best quality settings of x264 vs VP8 for the Ice Age clip, at the same quality (SSIM=0.97), x264 takes 800Kbps while VP8 takes ~1.2Mbps... So VP8 takes 50% more bits to achieve the same quality. This shows that VP8 is not nearly as efficient as x264. (Also, note that x264 is only one implementation of an H.264 encoder. There are other implementations that will make different tradeoffs to get better compression efficiency at the cost of performance).

Re:Reading Bitrate/Quality Graphs (1, Interesting)

Anonymous Coward | more than 3 years ago | (#32832562)

I don't understand the "VP8 holds its own against x264".... The graphs show that it certainly does not hold it's own against x264. For example, if you look at the best quality settings of x264 vs VP8 for the Ice Age clip, at the same quality (SSIM=0.97), x264 takes 800Kbps while VP8 takes ~1.2Mbps... So VP8 takes 50% more bits to achieve the same quality. This shows that VP8 is not nearly as efficient as x264. (Also, note that x264 is only one implementation of an H.264 encoder. There are other implementations that will make different tradeoffs to get better compression efficiency at the cost of performance).

I had the same thought. Perhaps "VP8 holds its own against" is code for "VP8 is massively outperformed by..."

Re:Reading Bitrate/Quality Graphs (4, Insightful)

DJRumpy (1345787) | more than 3 years ago | (#32832704)

Agreed, this reads as if it's nothing more than a promotional ad for the VP8 codec. How do they expect everyone to take this seriously?

I don't understand the "VP8 holds its own against x264".... The graphs show that it certainly does not hold it's own against x264. For example, if you look at the best quality settings of x264 vs VP8 for the Ice Age clip, at the same quality (SSIM=0.97), x264 takes 800Kbps while VP8 takes ~1.2Mbps... So VP8 takes 50% more bits to achieve the same quality. This shows that VP8 is not nearly as efficient as x264. (Also, note that x264 is only one implementation of an H.264 encoder. There are other implementations that will make different tradeoffs to get better compression efficiency at the cost of performance).

Re:Reading Bitrate/Quality Graphs (3, Interesting)

braeldiil (1349569) | more than 3 years ago | (#32832788)

The money quotes from the article: "Movies Comparing VP8 to XviD, VP8 is 5-25 times slower with 10-30% better quality (lower bitrate for the same quality). When comapring VP8 and x264 VP8 also shows 5-25 lower encoding speed with 20-30% lower quality at average. For example x264 High-Speed preset is faster and has higher quality than any of VP8 presets at average." Real competitive.

Re:Reading Bitrate/Quality Graphs (1)

unix1 (1667411) | more than 3 years ago | (#32833442)

The comment from WebM said they had just started the work to optimize the VP8 encoder. Given that, and the fact that x264 is at a pretty mature stage, the speed comparisons are not all that surprising. So, no, it's not "competitive" but it's not surprising either.

Re:Reading Bitrate/Quality Graphs (1)

timmarhy (659436) | more than 3 years ago | (#32834308)

so why waste our time with this dribble then? h.264 has won, /. get over it

Re:Reading Bitrate/Quality Graphs (0)

Anonymous Coward | more than 3 years ago | (#32833456)

It's very unlikely that you'll find an implementation of h264 with significantly better quality than x264. Most are markedly worse.

However, SSIM is not a good measure of quality. x264's psy-RD optimizations reduce SSIM while increasing image quality.

Near enough (2, Insightful)

curmi (205804) | more than 3 years ago | (#32832548)

Since when did "near enough" become "good enough"? We might as all switch to Windows...

Re:Near enough (0)

Anonymous Coward | more than 3 years ago | (#32832732)

Since forever. Cassettes vs vinyl or CD, VHS bs Betamax, MP3 vs raw or wav files, divx vs MPEG-2 or DV, h.264 vs MPEG-2 or VC-1, AC3 vs DTS-MA. Ethernet vs Tokenring, etc. Get the picture? Cheapest always win, starting in consumer-land.

Re:Near enough (1)

dimethylxanthine (946092) | more than 3 years ago | (#32832800)

Nearly all of us already have ;-)

Re:Near enough (0)

Anonymous Coward | more than 3 years ago | (#32833654)

No, nearly all of you never left it to begin with since its existence or at least your use of a windowing environment.

Re:Near enough (5, Insightful)

SheeEttin (899897) | more than 3 years ago | (#32832802)

Since when did "near enough" become "good enough"? We might as all switch to Windows...

It's not just "near enough", it's "near enough and unencumbered by patents". (Of course, MPEG LA will contest that...)

Re:Near enough (4, Insightful)

Klinky (636952) | more than 3 years ago | (#32832906)

Well if you're into the FOSS philosophy, "near enough"(WebM/VP8) is better than "not at all"(H.264).

Re:Near enough (1)

Draek (916851) | more than 3 years ago | (#32832976)

If your philosophy was "the best performance, and cost be damned" you should be using AIX on an IBM mainframe.

For the rest of the world however, "good enough" is good enough.

What's wrong with the site? (1)

bogaboga (793279) | more than 3 years ago | (#32832592)

Does anyone have the comparison site [compression.ru] rendering poorly? I am running Firefox 3.6.6 and I can confirm that the site looks awful. Something is surely wrong.

The graphs and the text just below them appear 'cut off' in a way. Anyone experience this as well?

Re:What's wrong with the site? (1, Informative)

Rockoon (1252108) | more than 3 years ago | (#32832762)

Renders fine in Opera, a standards compliant browser :)

Re:What's wrong with the site? (1, Informative)

icebraining (1313345) | more than 3 years ago | (#32833674)

But the site isn't [w3.org], it has 165 errors and 8 warnings. So in fact a strict compliant browser shouldn't render it fine.

Re:What's wrong with the site? (1)

Klinky (636952) | more than 3 years ago | (#32832920)

Yes it looks terrible, like something out of the 90s.

Re:What's wrong with the site? (0)

Anonymous Coward | more than 3 years ago | (#32833270)

Yes it looks terrible, like something out of the 90s.

Like Ace of Bass??

Re:What's wrong with the site? (1)

Klinky (636952) | more than 3 years ago | (#32833648)

Sure maybe they reused the same beat over and over and their lyrics were poofy, but the chicks were hot and playing with Legos while listening to Ace of Bass on the radio weren't bad times at all..

Re:What's wrong with the site? (1)

Anaerin (905998) | more than 3 years ago | (#32834808)

I think both you and the parent mean the Swedish pop band "Ace of Base [wikipedia.org]", rather than any group involving large fish.

Re:What's wrong with the site? (1)

steeviant (677315) | more than 3 years ago | (#32834892)

Like Ace of Bass??

I saw the site, and it opened up my eyes.
I saw the site.
The colors were rotten, I wish that I'd forgotten.
I saw the site, and it opened up my eyes.
I saw the site.

DCT (1)

proudfoot (1096177) | more than 3 years ago | (#32832658)

Both H.264 and VP8 use the pretty much the same exact approximation of DCT. They should be identically good at reproducing each others errors. The better performance in the mobile calender test is probably more representative of either a coincidence or the fact that the encoder has especially been optimized for certain standard test sequences. Also, I'm glad that the people doing this comparison tested for SSIM rather than PNSR. It's a metric which, while not perfect, has a much better correlation with "looks good" than psnr.

Re:DCT (1)

Lunix Nutcase (1092239) | more than 3 years ago | (#32832780)

But...but...that can't be true! That would mean that all the VP8 marketing claims of 50% efficiency gains over H.264 were untrue! And yes, they did make that claim on the page that is no longer available from their site.

Re:DCT (1)

proudfoot (1096177) | more than 3 years ago | (#32832834)

The marketing which claimed that VP8 was better than x264 used a two year old build of x264, and optimized VP8 for PSNR, while x264 was not optimized for that. Also, note that even in the mobile calender test, x264 was still ahead.

Re:DCT (1)

Lunix Nutcase (1092239) | more than 3 years ago | (#32832860)

Exactly. Basically On2 and the current VP8 developers have done nothing but completely overstate the capabilities of the codec and throw out bogus claims like the one in that addendum in order to muddy the waters when their codec routinely fails to measure up.

Re:DCT (2, Interesting)

mbone (558574) | more than 3 years ago | (#32833034)

H.264 doesn't actually use a DCT, but a non-exact integer approximation to a DCT, the Integer Cosine Transform [springerlink.com], which is exactly invertible [nasa.gov],, at the cost of a slightly loss of accuracy in the transform coefficients . (Floating point DCTs have rounding errors, and thus are not exactly invertible. If content is encoded multiple times, then the numerical noise introduced by this will accumulate to troublesome levels.)

Re:DCT (2)

PybusJ (30549) | more than 3 years ago | (#32834348)

What's more VP8 also uses an integer approximation to the DCT, but a different one to H.264 (quite possibly the H.264 version is patented).

Cameras = MPEG, for now (3, Insightful)

mbone (558574) | more than 3 years ago | (#32833054)

Most video material comes, originally, from a camera of some sort. (Obviously, this isn't the case for animation.) All of the HD camera systems I know of record in H.264, MPEG-4 or MPEG-2. (It might be called HD-DV or something else, but it's MPEG compressing under the hood.) So, if that gives H.264 an advantage, there isn't much that can be done about it. It will take a long time to replace all of the camera gear out there...

Re:Cameras = MPEG, for now (2, Insightful)

Undead Waffle (1447615) | more than 3 years ago | (#32833656)

Most video material comes, originally, from a camera of some sort. (Obviously, this isn't the case for animation.) All of the HD camera systems I know of record in H.264, MPEG-4 or MPEG-2. (It might be called HD-DV or something else, but it's MPEG compressing under the hood.) So, if that gives H.264 an advantage, there isn't much that can be done about it. It will take a long time to replace all of the camera gear out there...

As I understand it the argument is that when you're comparing the final result to the source material the results will show H.264 being more "accurate", but since we are talking about "accuracy" of artifacts it may or may not be an indication of video quality.

There is also this little piece of text on the bottom of the page (from the VP8 developers):

Even with this limitation, VP8 delivered respectable results against other encoders, especially considering this is the first time VP8 has been included in the test and VP8 has not been specifically optimized for SSIM as some other codecs have.

To date, WebM developers have focused on the VP8 decoder performance and are only starting to optimize the encoder for speed. The WebM project has only been underway for three weeks, and we believe that our encoder speed will improve significantly in the near future.

Yeah it sounds a little bit like they're making excuses but their claims are believable. We'll see if they are telling the truth about these "significant speed improvements in the near future".

$699 (1, Interesting)

Anonymous Coward | more than 3 years ago | (#32833112)

$699 [regnow.com]for what essentially is a research paper???

Well, duh! (1)

scdeimos (632778) | more than 3 years ago | (#32833252)

From TFS:

The VP8 developers comment in the report: 'We've been following the MSU tests since they began and respect the group's work. One issue we noticed in the test is that most input sequences were previously compressed using other codecs. These sequences have an inherent bias against VP8 in recompression tests.

I'm sorry, but what do you expect from a report that's all about transcoding performance? From TFR:

The main task of the comparison is to analyze different H.264 encoders for the task of transcoding video—e.g., compressing video for personal use. Speed requirements are given for a sufficiently fast PC; fast presets are analogous to real-time encoding for a typical home-use PC.

Licensing Cost and Legality (1)

poly_pusher (1004145) | more than 3 years ago | (#32833354)

Is it legal to distribute media that is for profit using the x264 codec in the United States? I was under the impression that x264 infringes on H.264 patents in the US and that distribution of media that is encoded using H.264 has licensing fees associated with it.

I could be way off base here and would like some clarification. If this is true, then VP8, as long as it does not have licensing fees, is by far the way to go. I have been concerned about this as I have been considering developing and distributing video tutorials for 3d apps. It would seriously suck to discover that I was infringing and at risk of legal action.

Encoding 'standard' (2, Insightful)

TimothyDavis (1124707) | more than 3 years ago | (#32833810)

I was under the impression that there is no standard for encoding a video stream, and that the standard is in the decoding of the stream.

It makes it unlikely that this comparison of codecs shows the full potential of one standard over another - and I would be wary of drawing any conclusions.

General statements (1)

mrpiddly (1568401) | more than 3 years ago | (#32833834)

General statements/headlines about a comparison between "VP8 to h.264" are absurd. One can compare aspects of each standard or how the standard performs in a single field, but not the standards themselves. H.264 will always come out ahead if you do that, because, as a standard, it is clearly better and I do not think many people would argue otherwise.

Just Pay The Man (0)

Anonymous Coward | more than 3 years ago | (#32834054)

H.264

-Produces superior video
-Is already widely supported in software players, hardware players, games consoles, cameras etc.
-Produces results that most people are very happy with

I don't like the idea of them trying to replace a widely supported codec with something inferior and which nothing currently supports. Google have arrived about five years too late and with a substandard codec. I for one would be happy to pay a small additional fee for H.264 support.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...