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.

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?

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.

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

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

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.