Forgot your password?
typodupeerror
Google Media News

VP8 and H.264 Codecs Compared In Detail 170

Posted by timothy
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."'"
This discussion has been archived. No new comments can be posted.

VP8 and H.264 Codecs Compared In Detail

Comments Filter:
  • In the real world (Score:5, Insightful)

    by DrXym (126579) on Wednesday July 07, 2010 @05:29PM (#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: (Score:3, Insightful)

      by TheKidWho (705796)

      For now at least.

      • Re:In the real world (Score:5, Informative)

        by westlake (615356) on Wednesday July 07, 2010 @06:39PM (#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 (Score:4, Informative)

          by prockcore (543967) on Wednesday July 07, 2010 @07:54PM (#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: (Score:3, Interesting)

            by westlake (615356)

            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.

            • by KingSkippus (799657) on Wednesday July 07, 2010 @09:26PM (#32834480) Homepage Journal

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

              • by tyrione (134248)

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

              • by westlake (615356)

                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

                • 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

              • by hazydave (96747)

                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)

            by sglewis100 (916818) on Wednesday July 07, 2010 @10:54PM (#32834982)

            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)

              by gravis777 (123605)

              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

              • by hazydave (96747)

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

                • by gravis777 (123605)

                  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

          • by Sycraft-fu (314770) on Wednesday July 07, 2010 @11:16PM (#32835120)

            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.

          • by mikeage (119105)

            Satellite might use MPEG2 TS (transport streams), but the encoding for HD is almost always MPEG4 (section 10), aka h.264.

          • by hazydave (96747)

            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,

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

    • by Jah-Wren Ryel (80510) on Wednesday July 07, 2010 @05:43PM (#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.

  • Very simple (Score:3, Insightful)

    by dimethylxanthine (946092) <mr...fruit@@@gmail...com> on Wednesday July 07, 2010 @05:30PM (#32832196) Homepage
    One is an extorsion accessory, the other is not (yet).
    • by Nadaka (224565)

      I am trying to figure out what extorsion is.

      • by Shark (78448) on Wednesday July 07, 2010 @06:11PM (#32832808)

        Torsion is what you feel when someone twists your balls.

        Extorsion is that lingering pain afterward.

      • Re: (Score:2, Insightful)

        by LaRainette (1739938)
        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: (Score:2, Insightful)

      by bonch (38532)

      And once again, idealistic people get behind an inferior technology for ideological reasons while everyone else moves forward.

      • by FreeUser (11483)

        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)

        by wannabgeek (323414)
  • by Lunix Nutcase (1092239) on Wednesday July 07, 2010 @05:31PM (#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.

    • by unix1 (1667411) on Wednesday July 07, 2010 @05:58PM (#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: (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)

          by unix1 (1667411)

          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

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

            • by unix1 (1667411)

              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)

                by Aboroth (1841308)
                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
                • by unix1 (1667411) on Wednesday July 07, 2010 @09:04PM (#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?

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

                  by unix1 (1667411)

                  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.

    • by evilviper (135110) on Wednesday July 07, 2010 @11:05PM (#32835052) Journal

      VP8 and H.264 and other MPEG codecs use basically the same transform so their statements of bias against VP8 ring untrue

      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.

      One of the professors who was part of doing this test even confirmed that the VP8 developers statement was untrue and misleading.

      Facts aren't determined by popular opinion... And 2 people isn't much of a vote, anyhow.

  • VP8 holds its own? (Score:5, Insightful)

    by Anonymous Coward on Wednesday July 07, 2010 @05:39PM (#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.

    • by Sycraft-fu (314770) on Wednesday July 07, 2010 @11:34PM (#32835220)

      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.

  • 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
  • by Anonymous Coward

    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.

  • by LWATCDR (28044) on Wednesday July 07, 2010 @05:45PM (#32832438) Homepage Journal

    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.

    • by hedwards (940851)
      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.
      • by LWATCDR (28044)

        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.

    • by Dahamma (304068)

      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)

        by prockcore (543967)

        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.

        • by Dahamma (304068)

          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

        • by _merlin (160982)

          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.

    • by Draek (916851)

      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.

  • by Anonymous Coward on Wednesday July 07, 2010 @05:46PM (#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).

    • by DJRumpy (1345787) on Wednesday July 07, 2010 @06:02PM (#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: (Score:3, Interesting)

        by braeldiil (1349569)
        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.
        • by unix1 (1667411)

          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.

    • (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)

    by curmi (205804) on Wednesday July 07, 2010 @05:52PM (#32832548)

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

    • Re:Near enough (Score:5, Insightful)

      by SheeEttin (899897) <sheeettin&gmail,com> on Wednesday July 07, 2010 @06:10PM (#32832802) Homepage

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

      • 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

        • by Zelos (1050172)

          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)

      by Klinky (636952) on Wednesday July 07, 2010 @06:19PM (#32832906)

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

    • by Draek (916851)

      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.

    • by hkmwbz (531650)
      That depends on what you need it to be good at.

      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

  • 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?

    • It renders oddly in Chrome as well.
  • 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 "lo
    • 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.

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

      by mbone (558574)

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

      • by PybusJ (30549)

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

  • by joe_cot (1011355) on Wednesday July 07, 2010 @06:18PM (#32832902) Homepage
    While looking at encoder comparisons, keep in mind this post from a x264 developer [multimedia.cx] about cheating on encoder comparisons. I'm not saying that these guys are cheating, just things to look out for.
    • by devinoni (13244)
      As the VP8 vs x264 test is using SSIM, I found these important from the article [multimedia.cx] about encoder cheating.

      3. Making invalid comparisons using objective metrics. I explained this earlier in the linked blog post, but in short, if you’re going to measure PSNR, make sure all the encoders are optimized for PSNR. Equally, if you’re going to leave the encoder optimized for visual quality, don’t measure PSNR — post screenshots instead. Same with SSIM or any other objective metric. Furtherm

  • by mbone (558574) on Wednesday July 07, 2010 @06:32PM (#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: (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

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

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

  • 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

Machines certainly can solve problems, store information, correlate, and play games -- but not with pleasure. -- Leo Rosten

Working...