In-Depth Look At Video Codecs

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

Comments

so which one wins?

[datapharmer]

Oh wait I'm "new" here.... let me go RTFA. Be right back.

Re:so which one wins?

[datapharmer]

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?

[Silverlancer]

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.

but i don't see..

[mrzaph0d]

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

[reaktor]

http://digg.com/apple/DivX_Pro_Mac_Free_on_June_7

Grab it while you can.

Re:OT: Divx Pro is free

[Anonymous Coward]

The windows version is free too
http://www.divx.com/dff/index.php?version=win

and everyone gets sent the same serial number:

Windows

SMYCU67X83BBA68TIT48

Mac OS X

358DSZ7D96C5X66BI48E

ascii and zip

[Anonymous Coward]

I've found the best way to highly compress movies on OS X is to use the ASCII Movie Player codec to display the video in Terminal.app, capture that to a text file using a pipe, and then zip it all up.

Re:ascii and zip

[smbarbour]

After looking at it for years, you don't even see the code anymore. You just see redhead, blonde, brunette...

Re:H.264 isn't a codec, it's a standard

[Silverlancer]

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!

Uncompressed Codecs

[Doc Ruby]

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

Re:Uncompressed Codecs

[Tab is on Slashdot]

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." ... What? The DCT is a complex algorithm that converts an array or matrix of values into frequency space, producing a set of frequency coefficients that represent respective values of cosine waves at different frequencies along the set. Halving the data has nothing to do with it unless you're using a quantizer of two and a quantization matrix of all ones (or a QM of all twos and a quantizer of one...).

This is also wrong:
"Think of a quantisation matrix as a palette of values that controls how the pixels in a macroblock are converted from pixels to a formula."

That's the DCT that he's describing. The quantization matrix simply defines what values the frequency coefficients are divided by. I think he has quantization and the DCT mentally swapped.

Oh also, he acts like QPel and GMC are Xvid inventions. In actuality, most MPEG-4 codecs implement these. Granted, DivX's GMC is inferior to Xvid's implementation (one warp point vs three), but it certainly does have it."

Of course, this got dugg down to hell because my comments about the DCT were mistaken for boasting. Hopefully the same won't happen here.

Image Algorithms

[Rac3r5]

Does anyone have a similar link to imaging and sound compression algorithms?

Re:Image Algorithms

[Rui del-Negro]

Yes, I was talking about stereo (which is still how >90% of music reaches the end users).

For audio production, lossy compression is a no-no (bandwidth and space are seldom issues), so there's no point in comparing lossy codecs.

For the vast majority of consumers, what matters is their perception of quality.

The point of quality comparisons is not to say "I recognise this version as the uncompressed one". It's to listen to several versions and pick the "best" one. And for that you don't need to know the piece at all. In fact, I'd argue that if you know a particular recording of that piece, you won't be judging abstract "quality"; you'll just be judging similarity to the version that you're used to.

In other words, like you say, (in a proper double-blind test), you'll only see consistent results if something "encodes really badly" (i.e., has obvious compression artifacts).

For image and video, where compression is often a requirement due to bandwidth and space issues (even during the production stages), it makes more sense to do comparisons to the original, rather than abstract "quality" evaluations. Which is not to say that consumer perception isn't still important. For instance, point & shoot digicams frequently over-saturate and over-sharpen images, because many consumers prefer that "look". Professional photographers prefer raw (or at least rawer) images, because they preserve more of the original information.

AVP beats ASP, no surprise.

[Kadin2048]

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:AVP beats ASP, no surprise.

[russ1337]

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.263. In these standards a GOB is defined as one or more rows of macroblocks (MBs).......
...... The video packet approach adopted by MPEG-4 is based on providing periodic resynchronization markers throughout the bitstream. In other words, the length of the video packets are not based on the number of macroblocks, but instead on the number of bits contained in that packet. If the number of bits contained in the current video packet exceeds a predetermined threshold, then a new video packet is created at the start of the next macroblock.

Bold emphasis mine.

Can any video experts comment? Can you provide me with a reference or some more information that would stand up in court? (not that it will get to that)

Re:AVP beats ASP, no surprise.

[JohnnyLocust]

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.

Re:AVP beats ASP, no surprise.

[NoMaster]

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 the developers to re-implement without being tainted by the original. The only real difference between MPEG-4 and what the PC BIOS cloners did (and the wireless / video firmware hackers in Linux / BSD development are doing) is that the MPEG-4 references themselves are covered by copyright and patent law. You can't take the specs and use them to produce an implementation, because that runs afoul of their licencing provisions. You could take an implementation, reverse-engineer it, and produce descriptive specs - but you'd want to be damned sure the descriptive specs you produced didn't look even remotely like the MPEG-4 group's specs...

FWIW, Part 7 is set aside for optimisations to the reference examples given in Part 5 (and I think Parts 2 & 3).

In this case, don't RTFA

[Rui del-Negro]

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.

Re:In this case, don't RTFA

[Rui del-Negro]

God, I've just read his description of DCT. It's even worse. He seems to think that DCT consists of "dividing numbers by two" (he doesn't even use the word "quantization", that probably has too many syllables). And people complain about Wikipedia...

Time to shamelessly plug my articles about compression. Some parts are simplified (they're aimed at "end users") but, compared to this Atomic article, anything is flawless:

Lossless (data, image, audio)
http://digitalproducer.digitalmedianet.com/article s/viewarticle.jsp?id=106309

Lossy + Hybrid (image, audio)
http://digitalproducer.digitalmedianet.com/article s/viewarticle.jsp?id=109739

Video (lossless, lossy)
http://digitalproducer.digitalmedianet.com/article s/viewarticle.jsp?id=125089

The description of DCT is pretty funny

[Hoplite3]

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.

Re:The description of DCT is pretty funny

[Rui del-Negro]

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

(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:The description of DCT is pretty funny

[bodrell]

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 met with a blank stare.

I first came across Fourier transforms in chemistry--specifically IR spectroscopy. I had the unfortunate experience of using a non-Fourier Transform Infrared Spectrometer (FTIR), a.k.a. a single-wavelength IR. It was a pain, and very time consuming, since the instrument scanned through each individual wavelength measuring absorbance of the sample. When I first used an FTIR, well, wow. It was explained to me that the FTIR measured all wavelengths at the same time, then crunched some numbers to calculate the absorbance at each wavelength. That's not so hard to understand for something that is time-invariant, but audio and video don't fit that description. That's why I'm still trying to figure out codecs, DCT, etc.

All chemical and electrical engineers, at the very least, know what frequency space is. Not just the small subset of occupations you mentioned. Wrapping one's brain around the Laplace transform is trickier than grasping the Fourier transform, in my opinion. The Dirac delta function is counterintuitive, to say the least. And frequency space--that at least has some physical sense. But s-space? WTF? It is only used to solve tricky differential equations, then you transform back into the time domain. If there is a physical interpretation for s-space, someone please correct me.

I thought there was too much information...

[CaptainPatent]

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

[azav]

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

Cheers

A wide range?

[jd]

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.

Re:Standards change

[tomstdenis]

At 1mbps? Um hell no. HDTV is 19mbps for a reason (which of course is probably sent over the wire at ~8mbps or so ... cheap bastards).

Tom

Re:Standards change

[Silverlancer]

1080p works pretty well at 3-4 megabits with H.264 High Profile. You can fit a full-length movie on a DVD5 that way. Of course, it'll be completely unplayable without CoreAVC.

The meaning of "print"

[autophile]

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

>:(

--Rob

Re:You mean the Reverse Engineered H.264 ripoff...

[benwaggoner]

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 going beyond what MPEG-4 was capable of, since we and everyone else started hitting our heads against its architectural limitations. Microsoft was also quite involoved in H.264 as well, including a Microsoft employee who chaired the committe that developed the standard.

That said, we find VC-1 is a better codec for many uses. H.264 was really designed more for an ASIC environment, and uses computationally and bandwidth intensive techniques like CABAC and a really strong loop filter that make it much more expensive for PC playback (in CPU requirements and battery life in a laptop) than a VC-1 encode of equivalent quality and bitrate. Also, VC-1's simpler loop filter design makes it easier for us to preserve textures like film grain at lower bitrates. This lower horsepower needed for decode makes it possible for us to do stuff like software-only decode of HD content inside the Silverlight brower plugin, where we have no access to hardware acceleration.

Re:WMA 10 Pro LBR!

[Movi]

I know youre kind of on-topic but this is the 2nd time ive seen you in this thread waving about what cool codecs you have. Thats fine, however, what good is it when i can't hear it/see it since i use Linux and Mac OS X. I _hate_ it when some doofus encodes something i want to see into wmv9 - this means extra hassle for me - either with maplyer and binary codecs, or WMVPlayer from flip4mac. The upside of _all_ other codecs mentioned here is that theyre all open source (ok, exclude divx, its superseeded by xvid anyway). So please, stop astroturfing.

Non-Windows VC-1/WMA Pro playback

[benwaggoner]

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 format that QuickTime Player and the QuickTIme browser plugin can use. Can you go into some more detail as to why it's a painful option for you?

VLC 0.8.6 added WMV playback support, including VC-1. It's got some glitches around playing back B-frames, but I'm sure they'll address those. I haven't tried WMA Pro in it yet, I must admit.

Since VC-1 is a SMPTE standard, with full decoder reference source code avilable, adding decoding for it isn't harder than any other codec.

And of coures Silverlight will provide WMV playback on Mac and Windows as a browser plugin. We haven't committed to doing a Linux port post 1.0, but we've certainly gotten a lot of feedback from people who'd like to see it.

Re:We Don't Care!!

[Rui del-Negro]

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

Man, is that a useless article!

[benwaggoner]

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