VP8 and H.264 Codecs Compared In Detail 170
Posted
by
timothy
from the you-can-only-get-so-much-detail-though dept.
from the you-can-only-get-so-much-detail-though dept.
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."'"
Re:In the real world (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.
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:Reading Bitrate/Quality Graphs (Score:1, Interesting)
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 (Score:3, Interesting)
Re:DCT (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.)
$699 (Score:1, Interesting)
$699 [regnow.com]for what essentially is a research paper???
Re:Misleading statements (Score:2, Interesting)
Re:In the real world (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.
Re:Misleading statements (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)
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: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: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: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.
Re:which brings us back to "for now" (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:In the real world (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 than something converted from another format.
To comment on the parent, assuming that content will usually already have been compressed in H.264 is short sited - still plenty of people compressing in WMV, Indeo, MJPEG, and other implementations of MPEG4 that are NOT H.264.
I think the parent should have said "The source content is usually already in some comrpession format" rather than saying its h.264. In fact, I haven't seen in years something that doesn't default to some compression format. Even HDV encodes in MPEG-2 http://en.wikipedia.org/wiki/HDV#Video_and_audio_coding [wikipedia.org]
My last couple of analogue video capture cards default to MJPEG. My last card that even offered uncompressed video was an All In Wonder.
The only way you are going to get uncompressed video this day and age, that I know of, is to use a film scanner, or to output your video project uncompressed. Which really is still probably going to have been compressed at some point - where did the source video come from?
The going saying in video editing used to be (dont know if it still is) to not compress your video at all until you are ready to export it to your final format. Avoiding compression at some point in the chain is almost impossible. What needs to be done is try to recompress as few times as possible, try not to change formats, to use the best encoder possible for your situation, and to use the highest bitrate you are able to spare.