VP8 and H.264 Codecs Compared In Detail 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."'"
In the real world (Score:5, Insightful)
Re: (Score:3, Insightful)
For now at least.
Re:In the real world (Score:5, Informative)
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 (Score:4, Informative)
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: (Score:3, Interesting)
Except that in the US at least, the only one of those things that use it is BluRay.
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" (Score:4, Insightful)
...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: (Score:2)
...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.
All the big camcorder manufacturers are H.264 licensees and license holders.
Re: (Score:3, Interesting)
Sure. They also know that their products aren't licensed for anything except personal use.
Is this so? [zdnetasia.com] (spoiler: no it isn't)
Re: (Score:2)
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
The moving image has the power to raise the dead.
To take you back in time.
The camera isn't about fame - it's about family. It's about the most intimate and precious of memories.
YouTube is an afterthought. YouTube is nothing.
As Google and other companies break the cycle by convincing people that the format will come into common support, man
Re: (Score:2)
heya,
Lol, there's a get off my lawn comment if ever I saw one...
Yes, I've had to sit through many a shaky home-video session of random niece/nephew/family friend eating a cake, but to write off YouTube as an afterthought...haha...gosh, where have you been for the last few years? Youtube, Facebook, MySpace, that's where the videos are being shared today.
When was the last time a friend asked you over *to their house* to share a funny video with you?
And at the big end of town, well, that's not for personal use
Re: (Score:2)
That's a false premise, though, on two accounts.
For one, you're not going to stream camcorder video directly -- any web video site is going to re-code your video, no matter what format you chose for deliver. AVC from a consumer-grade camcorder is likely to be in the 17-24Mb/s range. Streaming video is more like 2-3Mb/s, depending on the specific resolution and service (of course, most sites trancode your submission to multiple resolutions for delivery, too).
Second... your camcorder manufacturer does pay the
Re:In the real world (Score:4, Interesting)
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.
Huh? I believe ALL of the HD offerings on DIsh and Directv are now h.264 only. For awhile, after the near completion of the migration, the NYC and LA locals remained MPEG-2, but I think even that's done. Also, uVerse is h.264. Also OTA high def. supports h.264 Wikipedia link. Don't know much about cable, to be honest, but h.264 is pretty common... everywhere. Flash videos use it, most HTML 5 videos use it, your satellite receivers use it, your MKVs use it, your BluRay's use it...
Re: (Score:3, Interesting)
http://en.wikipedia.org/wiki/Dish_Network#Broadcast_technology [wikipedia.org]
Back to the original article, VP8 does have a point - I have noticed myself when I have to recompress material (for whatever reason) in the same format, I get faster speed and less artifacts introduced than I do when I convert to another format. This is nothing new - been dealing with this since I started messing with video 14 years ago.
And, duh, if the video is uncompressed, it is always going to yeild faster processing times and less artifacts
Re: (Score:2)
Their issue isn't with H.264 specifically, that's just the latest flavor. Rather, they're claiming some sensitivity to other DCT-based encoding mechanism: H.264/AVC, WMV9/VC-1, MPEG-2, MPEG-4/ASP, MPEG-1, even motion JPEG and DV are all DCT-block based compression algorithms.
Though far as I know, so it VP8. I would expect complaints more from maybe the Dirac people, since Dirac is another thing entirely (wavelet compression, not DCT).
Re: (Score:2)
Didn't realize there was something other than DCT available. Have to look into this, although, as all my source material is using some DCT compression, I doubt I will see much benefit
Also many cameras are MPEG-2 (Score:5, Insightful)
While most of the card ones are AVCHD which is H.264, HDV cameras are MPEG-2. They are quite popular as there's reason to want tape as a storage medium.
Then of course in terms of pro video, it is still compressed, raw video is just too daunting to store, but again with different codecs. They are often takeoffs of DV where there is just very light per frame compression as well as chroma downsampling. That offers better quality on subsequent recompression and editing, as well as lower hardware requirements to encode.
This idea that everything will be H.264 as a source is inaccurate. It is popular no doubt, and I believe it will continue to be, but it isn't universal and probalby won't be.
Re: (Score:2)
Satellite might use MPEG2 TS (transport streams), but the encoding for HD is almost always MPEG4 (section 10), aka h.264.
Re: (Score:2)
Actually, in the USA, satellite is largely H.264. Both Dish Network and DirecTV launched H.264 based systems about three years ago. While they still support MPEG-2 for some feeds, HD is exclusively broadcast in H.264.
And really, that's not the issue anyway... the issue is capture and conversion. At present, most current consumer camcorders, and increasingly large number of professional models (Panasonic's AVCCAM and Sony's NXCAM, for example) capture in H.264. And if it's not H.264, it's very likely MPEG-2,
10 cents a dance (Score:3, Informative)
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 e
Re: (Score:3, Insightful)
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: (Score:2)
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.
Yeah, just like they don't produce any MP3 hardware without paying any fees. Honestly.
Re: (Score:2, Interesting)
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.
Re:In the real world (Score:4, Insightful)
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.
Re: (Score:3, Informative)
You can do realtime, baseline H.264 encoding on Cortex A8 and A9 chips with x264.
Re: (Score:2)
Which means you can do similar with VP8...
Re: (Score:2)
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: (Score:2)
When their best quality is only slightly better or equal to H.264's baseline quality, then yes that is "much lower".
Re: (Score:3, Informative)
Re: (Score:3, Informative)
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: (Score:2)
Actually, all current high-end smartphone do MPEG-4 encoding: iPhone 4, Droid, Nexus One, etc. There's enough horsepower for at least D1-class video; most of the phones with 1GHz CPU or so are doing 720p. And just as on playback of H.264, many of these devices have other resources (dedicated hardware, DSPs, etc) to streamline the process.
Similarly, most new consumer P&S cameras are using H.264 or "AVC-Lite" (base level and 720p only) for video, replacing the MJPEG that's been popular. Nearly all tapeles
Very simple (Score:3, Insightful)
Re: (Score:2)
I am trying to figure out what extorsion is.
Re:Very simple (Score:5, Funny)
Torsion is what you feel when someone twists your balls.
Extorsion is that lingering pain afterward.
Re: (Score:2, Insightful)
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: (Score:2, Insightful)
And once again, idealistic people get behind an inferior technology for ideological reasons while everyone else moves forward.
Re: (Score:2)
And once again, idealistic people get behind an inferior technology for ideological reasons while everyone else moves forward.
What a crock. Avoiding patent lawsuits and patent trolls is as important as any other licensing constraints. It has nothing to do with idealogy and everything to do with practical and pragmatic legal and business realities.
VP8 may or may not be technically inferior to H264--an article comparing encoders tweaked to support specific benchmarks against one that is not is hardly a def
Re: (Score:2, Insightful)
http://xkcd.com/743/ [xkcd.com]
Misleading statements (Score:5, Insightful)
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 (Score:5, Informative)
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: (Score:2, Insightful)
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: (Score:3, Insightful)
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
Re: (Score:2)
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: (Score:2)
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. A
Re: (Score:2, Interesting)
Re:Misleading statements (Score:5, Interesting)
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: (Score:2)
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: (Score:3, Interesting)
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 (Score:5, Interesting)
An x264 developer may have said it, but that doesn't make it true. He contradicts himself often enough, anyhow...
Yes, the macroblock size is the same, however, that's just about it... VPx codecs use rather different quantizer matrices, never use B-frames, store motion vectors differently, and in general just have a very different and unusual encoding method. There are many ways in which it is different, and more to the point, far more different from H.264 than H.264 is from MPEG-2... Of course it can be over-stated, but it's very, very real.
And BTW, what the hell is a "transform"? If you're going to pretend to be knowledgeable about a subject, you could at least have the decency to use precise terminology, so I can more efficiently ridicule you... If you're talking about the "T" in DCT, then I've got bad news for you. While nearly all lossy codecs are indeed using DCT, that's about as relevant as saying all vehicles burn fuel.
I'll see your x264 developer quote, and raise you one ffmpeg/Adobe Flash developer quote: http://multimedia.cx/eggs/dct-pr/ [multimedia.cx]
While he's talking about Theora, all points apply directly to VPx. Highly relevant quotes below:
"Theora is rather different than most video codecs, in just about every way you can name"
"As for the idea that most DCT-based codecs are all fundamentally the same, ironically, you can't even count on that with Theora- its DCT is different than the one found in MPEG-1/2/4, H.263, and JPEG (which all use the same DCT)."
But you can ignore him if you like. He's just the guy who actually wrote the VP3 and Theora decoders for FFmpeg, and has reverse engineered numerous other codecs, so I'm sure he doesn't have a clue... You know, unlike a vocal x264 developer...
And just to push further off topic, DCT isn't all that good, anyhow. The default in FFmpeg encoding isn't DCT, but SAD (Sum of Absolute Differences). SAD happens to be much faster, and more importantly, doesn't leave strangely colorful 16x16 blocks (usually green, but often red or other colors) as artifacts in low-bitrate encodings, which then have to be masked, wasting bits which could be better used elsewhere.
Facts aren't determined by popular opinion... And 2 people isn't much of a vote, anyhow.
Re: (Score:2)
Nonsense. SAD is a direct alternative to DCT for macroblock comparison functions, and motion vector search. It appears most other encoders use DCT (at least by default), which has a serious negative effect on video quality.
But honestly, if the only thing you can find issue with is my small little out of context and off-topic rant at the end, that's a pretty good implicit endorsement of the meat of everything else I've said...
Re: (Score:2)
>Nonsense. SAD is a direct alternative to DCT for macroblock comparison functions, and motion vector search. It appears most other encoders use
>DCT (at least by default), which has a serious negative effect on video quality.
When we're talking about DCT based codecs, we're talking about the base transform set in stone by the standard, not the motion search algorithm, which tends to be implementation specific and can be changed without breaking compatibility.
>But honestly, if the only thing you can f
Re: (Score:2)
No mistake at all. I merely didn't explain the point I was making, and now YOU try to stretch it into a straw man you can knock down as if it matters. Try as hard as you like, I'll still know far more about lossy codecs than anyone here... I have yet to have an intelligent conversation about lossy encoding in the many years I've been on /. You don't seem to be changing that run.
Re: (Score:2)
Nonsense. SAD is a direct alternative to DCT for macroblock comparison functions, and motion vector search. It appears most other encoders use DCT (at least by default), which has a serious negative effect on video quality
I don't know very much about video compression so excuse my ignorance, but what compressors use DCT (Discrete Cosine Transform) to compare blocks? My understanding is that SAD (Sum of Absolute Differences i.e. Manhattan distance) is used to compare pixel blocks for "similarity" though some might use a cheap transform (e.g. Hadamard), on the block data prior to "SAD", to find better matching blocks whose residual, i.e. after differences are taken, would compress with DCT.
Re: (Score:2)
The quote really isn't off-topic, it's quite relevant. My little rant was the off-topic bit.
And your quote doesn't help your argument... The only thing listed that is shared with H.264 is "intra prediction". The other bits of ffmpeg that are shared with VP8 are from PREVIOUS VPx codecs. Yes, I certainly won't deny that VP8 is VE
VP8 holds its own? (Score:5, Insightful)
"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.
Re:VP8 holds its own? (Score:5, Interesting)
Well if your demand is "In every way as good or better," then no, VP8 is not that and probalby never will be. If that's your criteria go use H.264. Just don't come crying if you get smacked with a large licensing fee for your stuff.
However, if you ease off and say "Can it produce a good looking image, something of similar subjective quality, at a reasonable bitrate?" then yes, VP8 holds its own. So does VC-1 for that matter. In all cases you can encode a video at a similar bitrate and still have it look good. The H.264 will probalby look a bit better, but not so much as to really matter a lot. Also, perhaps more importantly in some applications, it is a similar bitrate when encoding artifacts start to drop below human perception. So if you need something that's "lossless" as far as the view is concerned, you are doing it in around the same amount of space. Sure, H.264 can squeeze it down a bit more, but not a massive amount.
To put it in sports terms they may not all be the best hitter, but they are all playing in the major leagues. This is as compared to an older codec like, say MPEG-2 or especially MPEG-1. For those, you need a substantially higher bitrate to look as good, and something even then it just isn't possible.
Its future is transcoding!!! (Score:1)
Also, remember almost all new camcorder/camera
Reflecting the real world (Score:1, Insightful)
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. (Score:3, Interesting)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
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: (Score:2)
Well if they keep doing it what will happen is people will stop using Firefox and move to Opera and Chrome.
If they did it correctly I.E. use the OS's built in codec support they wouldn't have any patent issues at all since any patent infringing code would not be part of FireFox.
Re: (Score:2)
Chrome doesn't use built in codec support because it doesn't have too. They have a license to use H.264 so they can build it in.
There is no reason to "enforce" OS codec support. There are a lot of good reasons to use it including not having to write your own code for everything. There are some good reasons to not use it if you want to be sure that x Codec will work no matter what is installed on the PC.
The ideal solution IMHO would be to use the built in codec if an OS codec couldn't be found. Or to have th
Re: (Score:2)
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 co
Re: (Score:3, Informative)
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: (Score:2)
No, I'm thinking of it like I have spent the last decade writing software for STBs, TVs, and DVD/BD players that currently decode almost entirely H.264 content.
To get technical, you are (somewhat) correct that the hardware/microcode/software stack that is capable of decoding H.264 *might* allow the updatable bits to decode VP8 (though unlikely to impossible on a fair amount of the HW I have worked with). But even IF it is possible, the current manufacturers of SoCs ("system on a chip", ie the guys like Bro
Re: (Score:2)
You're wrong. The iPhone isn't using additional CPU instructions or an output DSP - the PowerVR graphics module has silicon for decoding MPEG video.
Re: (Score:2)
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: (Score:2)
Yeah, it's called Chrome Frame.
Reading Bitrate/Quality Graphs (Score:5, Insightful)
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 (Score:5, Insightful)
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?
Re: (Score:3, Interesting)
Re: (Score:2)
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: (Score:2)
(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).
Really? Could you cite some examples?
The impression I got was x264 is one of the best, or perhaps the best one out there.
I see some people criticizing VP8 maximum for only matching H.264 baseline. I have to say... I don't care. I care about encoding time. On modern 6+ core systems, x264 encodes faster than XviD, even with tons of quality settings enabled. If VP8 can encode faster with a similar bitrate, for the same perceived quality, it's useful.
Near enough (Score:3, Insightful)
Since when did "near enough" become "good enough"? We might as all switch to Windows...
Re:Near enough (Score:5, Insightful)
It's not just "near enough", it's "near enough and unencumbered by patents". (Of course, MPEG LA will contest that...)
I think too many people forget that (Score:2)
They go out and download x264 and think "H.264 is free, I just downloaded the encoder and it was open source." No, not by a longshot. H.264 has hefty licensing fees in many areas. What's more, every 5 years they review the licensing and decide if it is going to change. Originally, they had it such that you had to pay per viewer for streaming media, with no cap on royalties. While that's gone now, perhaps they bring it back when they have a monopoly.
WebM on the other hand is truly free. If you look at Google
Re: (Score:2)
Indeed. And the best way to stop the H264 guys exploiting their huge market share with high royalties is to have one or more "good enough" free alternatives widely available.
Re:Near enough (Score:4, Insightful)
Well if you're into the FOSS philosophy, "near enough"(WebM/VP8) is better than "not at all"(H.264).
Re: (Score:2)
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.
Re: (Score:2)
Windows is good at just working with hardware and loads of software. It might suck at other things compared to other OSes, but it certainly has its strengths, and the parts that aren't as good are apparently good enough for most people.
The Nintendo Wii might have sucky graphics compared to the competition, but they are apparently good enough for most people. And the Wii remote outweighed the "only-good-enough" graphics.
VHS might have had worse quality tha
What's wrong with the site? (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:2, Informative)
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.
DCT (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:3, Interesting)
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: (Score:3)
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).
Something to think about (Score:4, Informative)
Re: (Score:2)
Cameras = MPEG, for now (Score:4, Insightful)
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: (Score:3, Insightful)
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
Well, duh! (Score:2)
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.
Encoding 'standard' (Score:2, Insightful)
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.
Want free video (off topic rant) (Score:2)
Listen, who cares for these marginal speed differences. All I want is a way to watch videos for free without having to install malware, a way to publish my videos commercially or non-commercially without having to pay license fees to stupid lawyers now or later, and a way to check and modify the source code and implement video playing and streaming abilities in my software as I like. I know this is a bit off topic, but this is really starting to make me angry. I just can't understand why media companies and
uptake rate? (Score:2)
Has a rate of uptake that exceeds any previous codec?
Where do you get that information from?