Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

In-Depth Look At Video Codecs

Posted by kdawson on Fri Jun 08, 2007 11:19 AM
from the jaggies-and-artifacts dept.
Software Graphics
johnsee writes "Atomicmpc has an incredibly in- depth look at a wide range of video codecs. It looks not only at their inner workings, but also shows the quality produced by each at a variety of settings and situations."
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

In-Depth Look At Video Codecs 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • so which one wins? (Score:4, Funny)

    by datapharmer (1099455) on Friday June 08 2007, @11:22AM (#19439089) Homepage
    Oh wait I'm "new" here.... let me go RTFA. Be right back.

    • Re:so which one wins? (Score:5, Informative)

      by datapharmer (1099455) on Friday June 08 2007, @11:29AM (#19439249) Homepage
      Apparently some people have no sense of humor. BTW I am back.

      For those not wanting to read the article:
      Rated best to worst with default settings
      Low Bitrate go with XVID, DIVX, h.264, WMV
      Medium: XVID or h.264 depending on lighting and motion, WMV, DIVX
      High: h.264, WMV, XVID, DIVX

      • Re:so which one wins? (Score:5, Insightful)

        by Silverlancer (786390) on Friday June 08 2007, @11:31AM (#19439295)
        Xvid is horrible at low bitrates in my experience. For example, I did a test encode of a 1680x1050 FRAPS video at 1000kbps. H.264 was actually quite watchable (!!!) and you could even read the size-12 text in the chat windows. Xvid couldn't even get below 1400kbps or so with every frame at quantizer 31 with max motion search settings and the like. So I'd say Xvid is the opposite--good at higher bitrates, worthless at low ones.
        • I'd like to point out that 1680x1050 is huge. For ref, DVDs are encoded ~9000kbps at 720x480. Granted with an inferior codec, but still.

          I wouldn't expect many codecs to handle that size frame spectacularly well. That any of them did [h.264 in your case] is amazing.

          Tom
        • XviD is an H.263, aka MPEG-4 Part 2 "Advanced Simple Profile" (ASP) encoder, no?

          This is quite different from the newer H.264 (MPEG-4 Part 10 "Advanced Video Profile" (AVP)) encoders like x264 (which is part of ffmpeg, at least recently, I believe). H.264 is a much better match for high-definition video that's going to be played back on HD equipment.

          I think it's been known since the AVP codecs arrived on the scene that they pretty much kicked the crap out of the ASP ones; their only major downside is the processing requirements both to encode and decode, and (more true in the past than now) limited installed base of people with the codecs.

          • Re: (Score:3, Informative)

            by russ1337 (938915)
            I've had some guys at my work try to tell me that H.263 = MPEG4. It actually got quite nasty.

            I recognize their are similarities, but I do not believe they are the 'exact same'. My evidence is that the video cards we use have Mpeg4 hardware encoders, yet will not 'hardware decode' the H.263 stream.

            also, FTFA's reference:

            The resynchronization approach adopted by MPEG-4, referred to as a packet approach, is similar to the Group of Blocks (GOBs) structure utilized by the ITU-T standards of H.261 and H.2

            • Re:AVP beats ASP, no surprise. (Score:5, Informative)

              by JohnnyLocust (855742) on Friday June 08 2007, @12:38PM (#19440487) Homepage

              I've had some guys at my work try to tell me that H.263 = MPEG4. It actually got quite nasty. I recognize their are similarities, but I do not believe they are the 'exact same'.
              H.263 is a part of the entire MPEG4 specification (as is H.264).

              ie the following statement is always true:
              H.263 is always MPEG4

              However the the folloing statement is not always true:
              MPEG4 is always h.263

              My evidence is that the video cards we use have Mpeg4 hardware encoders
              Not true at all. There are some hardware MPEG4 encoders on the market, but it is for the most part, not included in modern GPUs. For decoding purposes, portions of the h.263 (IDCT to be exact) has been implemented in hardware on video cards for quite sometime. However, combined with programmable shaders, a good deal of h.263 decoding can be greatly accelerated by most modern GPUs (nVidia's PureVideo DirectShow codec is an example of this). ATI's AVIVO XCode app does use a great deal of shaders to speed up the encoding process for several codecs. Even though it's been shoehorned to work with other GPUs, it was intended to work thier X1X00 line of video cards.
              • Thanks for your response. I really appreciate it. If i've got this straight you're saying H.263 is a subset of MPEG4. I'm still a little confused though as I've been reading through the page linked: http://www.chiariglione.org/mpeg/standards/mpeg-4 / mpeg-4.htm [chiariglione.org], which says...

                H.263 uses 'Group of Block' (macroblock) resync, and Mpeg 4 uses ' the packet approach'

                H.263 also puts information on the macroblock in the header, the document says MPEG4 uses a 'picture start code'. These appear to be different

                  • Re: (Score:3, Informative)

                    by NoMaster (142776)
                    Almost right, but the "Part"s are descriptive standards or references, not implementations. H.264 is not "MPEG-4 Part 10" - Part 10 describes a standard which is technically the same as H.264, but does not provide an implementation (beyond pointing at the ITU-T's H.264). It's a subtle difference, but important, and Wikipedia is not always clear on this.

                    It's a bit like reverse-engineering in a cleanroom environment - the various MPEG-4 parts describe exactly how things should work, then you'd pass it off to
            • H.263 is indeed not the same as MPEG-4. H.263 was published in 1995 by the ITU, MPEG-4 (first "official" draft) was published in 1998 by the MPEG. H.263 is based on H.261 and MPEG-2, but was developed without the MPEG's help.

              It uses similar concepts to MPEG-4 (all BMC-based algorithms do), but several details in stream structure are different (which is not to say parts of a MPEG-4 codec can't be used to accelerate H.263 compression or decompression).

              H.264, on the other hand, was developed by the ITU in part
          • Not exactly. H.263 is not the same as the MPEG-4 ASP. XviD is indeed based on the MPEG-4 ASP, and can also produce H.263 files, but the two things are different (albeit similar, especially if you consider H.263 v2).

            Also, bear in mind that video compression standards focus on "what" the encoders must create, not "how". Even if a certain standard supports more advanced features, a "smarter" encoder using a "lesser" standard can produce similar, or even better results.

            As H.264 encoders improve, they should cle
  • You don't even have to read the article to guess that H.264 destroyed everything. Even VP7 doesn't stand a chance, though from my experience its the closest codec there is to H.264.
    • What would be more interesting is, "which H.264 codec performed the best?" They probably answer this question in the article, but I can't read it because it seems to be Slashdotted right now.

      • Re:H.264 isn't a codec, it's a standard (Score:5, Informative)

        by Silverlancer (786390) on Friday June 08 2007, @11:38AM (#19439421)
        There are a number of comparisons around the internet, and the last ones from 2006 show that x264 and Mainconcept are basically tied as the best, with Mainconcept having a tiny lead. However, x264 now has Adaptive Quantization available, an experimental feature that can help eliminate blocking in dark scenes which is pretty much impossible to avoid without AQ unless you use absurdly high bitrates. This feature alone puts it way over the top, IMO.

        --aq-strength for the win!

            • Re: (Score:3, Informative)

              by benwaggoner (513209)
              Are you aware that VC-1 in the SMPTE spec for VC-1? So both codecs have fully publshed specifications, and reference source code for both encoding and decoding.

              All the info about algorithms in the video codecs is fully public. The same body, MPEG-4 LA, handles licensing for both technologies, and handling patent issues around them.

              Going back to the paleolithic era, Microsoft made the original reference encoder for MPEG-4 (hence the venerable MPEG-4v3 codec). Windows Media Video 7 and later were about goi
      • At the heart of it, they're both variants of MPEG4 video, however, H.264 is an open standard while WMV is a proprietary wrapper around that open standard. I'm not surprised that H.264 beats WMV however. There are about a gazillion different options/combinations of options for encoding H.264 so you can define specialized profiles for particular video types. Given this fact, H.264 will always outshine WMV, it's simply that much more flexible.

  • but i don't see.. (Score:5, Funny)

    by z@ph0d (25646) <zaph0d@@@curztech...com> on Friday June 08 2007, @11:25AM (#19439141) Homepage
    ..any of the codecs the porn..i mean video sites i visit ask me to install before i get to see the videos..

  • OT: Divx Pro is free (Score:3, Informative)

    by reaktor (949798) on Friday June 08 2007, @11:30AM (#19439265)
    http://digg.com/apple/DivX_Pro_Mac_Free_on_June_7 [digg.com]

    Grab it while you can.

  • ascii and zip (Score:5, Funny)

    by Anonymous Coward on Friday June 08 2007, @11:31AM (#19439281)
    I've found the best way to highly compress movies on OS X is to use the ASCII Movie Player codec [apple.com] to display the video in Terminal.app, capture that to a text file using a pipe, and then zip it all up.

  • Uncompressed Codecs (Score:5, Interesting)

    by Doc Ruby (173196) on Friday June 08 2007, @11:50AM (#19439631) Homepage Journal
    The article makes some serious errors in overgeneralizations. It says that all codecs have in common that they make bitstreams shorter for transmission. But not all codecs compress (or otherwise reduce) their data. Some codecs transmit uncompressed raw data, increased in size by adding encoding data. For example, HD video monitors connected by HDMI (or DVI) use TDMS [wikipedia.org] encoding not for compression, but to increase reliability in transmitting large raw data streams (10.2Gbps) quickly enough (340MHz) over cheap HW.

    And though humans learned stone tools remarkable close to finally learning to load CD-ROMs, the stone tools were paleolithic ("old stone"), while the CDs were at worst neolithic ("new stone"). Someday we'll look at the modern era as a new age, probably "hualic" [foreignword.com], or "glass" age. These silicon chips and glass fibers have changed us as much as we've changed the glass from which we make them.

    Just for kicks, I note that we've encoded the Si atoms into the new tools that define our age.

    • And though humans learned stone tools remarkable close to finally learning to load CD-ROMs, the stone tools were paleolithic ("old stone"), while the CDs were at worst neolithic ("new stone").

      In keeping with the naming of capital-A Ages after prevalent use of materials, I like to refer to the period from 1912 to 2045 as the "Plastic Age" (or possibly the "Polymer Age" or "Polyfantasic! Age"), covering the use of Bakelite on up in consumer goods.

      Your guess as to what happens after 2045 :) (Hint: Ray Kurz

      • In keeping with the naming of capital-A Ages after prevalent use of materials, I like to refer to the period from 1912 to 2045 as the "Plastic Age" (or possibly the "Polymer Age" or "Polyfantasic! Age"), covering the use of Bakelite on up in consumer goods.

        Your guess as to what happens after 2045 :) (Hint: Ray Kurzweil has something to say about that)

        --Rob

        No, it seems like all the materials that are whizzy and new now days are "Space Age Materials." Stuff like carbon fiber. So, that makes this the "Space

    • Exactly. I'll copy/paste my response to this highly innacurate article on Digg:

      "Some other major inaccuracies:

      This site says that motion compensation was introduced in MPEG-4. What? Motion compensation and motion estimation are at the core of every MPEG and most other codecs.

      Also, his understanding of the DCT is way off (and no, you don't need a degree to understand it -- I was building JPEG encoders in 11th grade).

      "During an encode, every number in a series is simply halved and the remainders thrown away."

  • Image Algorithms (Score:4, Interesting)

    by Rac3r5 (804639) on Friday June 08 2007, @11:52AM (#19439661)
    Does anyone have a similar link to imaging and sound compression algorithms?
    • You hardly need a link: most of the popular low-to-mid bitrate sound algorithms are pretty straightforward in effectiveness. Low bitrate, AAC-HE is the king. Ogg is close though. At higher bitrates AAC and Ogg become more equal and eventually Lame MP3 catches up at the highest bitrates (192+).
          • Well, the OP was about how good codecs are :).

            Actually, there are more non-Windows playback options than you think.

            First, Flip4Mac can play back all VC-1 flavors and WMA Pro today. It doesn't play back the higher frequencies of WMA Pro, but they continually improve their support every release (full VC-1 Advanced Profile came in 2.1.1 last month). Downloading it seems pretty simple, but it isn't open source. And it nicely integrates with QuickTime, so once it's installed, WMV beccomes just another file fo
    • If by "similar" you mean "completely clueless", yes, I know a few, but can't really see the point in propagating them. :-) If you want an article with some theory and a visual comparison of JPEG and JPEG-2000, here:

      http://digitalproducer.digitalmedianet.com/article s/viewarticle.jsp?id=109739 [digitalmedianet.com]

      (disclaimer: I wrote it, but I don't get any $$$ from page views... unfortunately :-P)

      There are lots of articles about sound codecs, but most of them seem a bit too "mystical" to me (as is typical with all things audiop

  • In this case, don't RTFA (Score:5, Interesting)

    by Rui del-Negro (531098) on Friday June 08 2007, @11:58AM (#19439787) Homepage
    I've just read a bit of the article and the only thing I can think of is to paraphrase Stanislaw Lem: "it always amazes me that people need a license to drive a car but can write and publish all sort of nonsense without any clue about the subject".

    His descriptions of "temporal compression" and "motion compensation" (to name just two of the fundamental building blocks of modern video codecs) are so wrong they don't even qualify as an error. He confused delta compression with motion compensation, thinks MPEG1 lacked the latter, doesn't understand why the former is virtually useless for video... sigh... even trolled Wikipedia articles manage to be more accurate than that.

    I feel truly sorry for the people who read that and think they've learned something about the subject.

  • The description of DCT is pretty funny (Score:5, Interesting)

    by Hoplite3 (671379) on Friday June 08 2007, @11:59AM (#19439803)
    I'm a bit skeptical of information in that article after reading the DCT description that described it as a rounding trick. What, is frequency-space too hard of a concept? Doesn't everyone get some Fourier analysis in college these days? You need to know it to be informed about a lot of modern data analysis.
    • If you grabbed 1000 people at random - heck, I'll even give you 1000 people between the ages of 20 and 40, you'd be hard pressed to find 20 that have ever heard of DCT or Fourier analysis, and phenominally lucky to find one that could actually describe what it means.

      Oh, and the answer to your question is "yes." Saying "Frequency Space" as part of a description to anyone who is not involved in either said data analysis, compression, or vibrations (my former, and sometimes current, field) is guaranteed to be

      • Re:The description of DCT is pretty funny (Score:5, Informative)

        by Rui del-Negro (531098) on Friday June 08 2007, @12:32PM (#19440371) Homepage
        And so you should describe it as "dividing numbers by two and then multiplying them again"...? In other words, a "simple" description is preferable, despite the fact that it's completely wrong...? Hell, "dividing numbers by two" isn't even an accurate description of quantization, let alone of a DCT.

        I think I made a pretty decent job of explaining what "frequency space" is, and why it can be used to improve compression, here:

        http://digitalproducer.digitalmedianet.com/article s/viewarticle.jsp?id=109739-2 [digitalmedianet.com]

        (scroll down to "The transformers")

        It also explains why DCT isn't a form of compression per se, it simply makes it possible to use quantization in a way that does not affect quality as much as it would in "pixel space".

        Several "non-techies" have read that and, although they realised the transform itself is not something trivial, they understood what it did and what it was used for. Something that you can't really say about the Atomic article (or its author).

      • Re: (Score:3, Interesting)

        by bodrell (665409)

        If you grabbed 1000 people at random - heck, I'll even give you 1000 people between the ages of 20 and 40, you'd be hard pressed to find 20 that have ever heard of DCT or Fourier analysis, and phenominally lucky to find one that could actually describe what it means.

        Oh, and the answer to your question is "yes." Saying "Frequency Space" as part of a description to anyone who is not involved in either said data analysis, compression, or vibrations (my former, and sometimes current, field) is guaranteed to

    • Nope, only the people who learn how to do modern data analysis. You can pretty much assume that anyone with a liberal arts background 9literature, history, law, psychology, etc.) has not.
  • So I compressed it for ease of reading:

    "Atmcmpc has n n-krdibly n-depth lûk ata wide rng of video codcs. It lûks not nly at ther iner wrkngs, but also shws thá kwality produced by each ata vriety of settngs and situashuns."

    please note a lossy codec was used for paraphrasing

  • They missed 3ivx (Score:5, Informative)

    by azav (469988) on Friday June 08 2007, @12:27PM (#19440273) Homepage Journal
    This is not "everything you wanted to know about codecs." In fact, 3ivx just released 3ivx 5.0 for encoding to MPEG4 a few days ago.

    A bit of a bummer that an Australian website missed reviewing an Australian created codec.

    FYI, here's the press release. And YES! It does do Linux!. Tux be praised.

    http://www.3ivx.com/pr/pr20070607_50.html [3ivx.com]

    Cheers

  • A wide range? (Score:5, Interesting)

    by jd (1658) <imipak@yahCOFFEEoo.com minus caffeine> on Friday June 08 2007, @12:45PM (#19440607) Homepage Journal
    I've seen more codecs on the back of a postage stamp. Seriously, one "modern", effectively one "old" (DivX and XviD are forks of the same original design), and one "archaic" does not make for much of a range. It doesn't even cover the spectrum of eras, never mind the spectrum of codecs.

    For those who like laundry lists, here are some codecs not listed: Dirac, Theora, Huffyuv, Lempel-Ziv-Oberhumer Codec, MNG, Cell, NV, WaveCodec, Motion JPEG and MSU Lossless Video Codec. The wikipedia page doesn't list all of these, it took some scouting to find others and some of the early early ones are apparently only listed in the documentation on Open Source videoconferencing software I had back in the early 1990s.

    Are any of these significant, though? Well, Dirac (BBC) damn well should be - we're only talking a high-definition TV quality codec by a major broadcaster with on-site offices in most countries that would be a logical choice for their remote bureaus to use and be a good candidate for competing with digital broadcasters in general.

    Theora - well, it would be the ideal desktop videoconferencing codec in many ways. Those in common use today are heavier than necessary but the quality you buy with that at the bandwidth generally available just isn't worth it.

    Huffyuv is said to be the fastest codec on the planet by some, which is entirely possible. That would make it good for most things where CPU power is expensive but bandwidth is cheap. (Embedded systems would probably fall into that category a lot.)

    MSU's Lossless Codec is probably the slowest codec ever written, but gives by far the best compression. It makes a great reference codec to compare others against, apparently. If you could develop a decent hardware implementation, it might be a serious competitor to HD-DVD and Blu-Ray, as you could pack a comparable volume of material onto a standard DVD and therefore use already-existing commodity disks and players. All you'd need is a patch kit to add the decoder. This would likely appeal far more to consumers, as they wouldn't need to spend as much, but the studios and the manufacturers would hate and despise it for the same reason.

  • The meaning of "print" (Score:3, Informative)

    by autophile (640621) on Friday June 08 2007, @01:00PM (#19440917)

    "Print" does not mean stipping out all graphics and ads, but leaving the number of pages the same.

    >:(

    --Rob

  • Leaving aside how crap the article is in terms of what it does cover, it didn't even include any Wavelet CODECs (Dirac, Snow, etc, ...) which outperform the DCT based methods, both for video and for still images (JPEG 2000).
  • The Slashdotting finally eased up enough for me to finally get to Page 4. Earlier complaints about the complete absence of accurate facts in the technical part were dead-on. But in the proceudre, wow, it's hard to know what relevant of the test would be.

    40 FRAME clips? The default GOP length of most of these codecs is longer than that! There's no useful test of rate control in there, or keyframe supression popping.

    And as far as compression setings, all they say is "we used the defaults, but set it to highest quality". There isn't just ONE defualt in these products. We don't know if they're even comparing CBR and VBR, 1-pass or 2-pass. And there are lots of tweaks appropriate to different kinds of content that would be used in practic - one doesn't compress film source like cel animation!

    Sheesh, there's really no useful information here at all. The average reader would probably wind up knowing less about compression after reading it...
    • I don't know who the "we" you're talking about is, but some people do understand that different situations correspond to different needs. Sometimes you need lossless quality, sometimes you need the lowest possible data rate, sometimes you need a format that can be decoded with very little CPU power.

      Do you also think that there should be a single type of paint, a single type of tire, a single type of lightbulb, and so on...?

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.