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

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.

Re:

[tomstdenis]

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

Standards change

[dazedNconfuzed]

I'd like to point out that 1680x1050 is huge.

[Ahem] The new standard is 1920x1080. Cope.

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.

Re:

[ncc74656]

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.

mplayer works well enough playing HD H.264 on my MythTV box, and it's just an Athlon 64 3700.

Re:

[Silverlancer]

With CABAC, 16 reference frames, and 1080p resolution? Wow.

Re:

[WuphonsReach]

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

Yes, it's sent at 19mbps (or so) for a reason: they're using a MPEG2 codec to do the compression. Not a more modern codec.

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:

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

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:

[russ1337]

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:

[Kadin2048]

That page is either oversimplifying, or just wrong. I'm not sure which.

MPEG-4 is a group of specifications. It's not just one video format, or one codec. Just talking about "MPEG-4 video" is bad, because it could refer to any one of several video formats, and any of those formats could have been produced with a variety of codecs.

Within "MPEG-4," you have multiple "parts" which are actual specifications for video encodings. Wikipedia explains slightly:

MPEG-4 is still a developing standard and is divided into

mod up all the parents and grandparents

[PopeRatzo]

See, now this is why I read Slashdot. Thank you,Kadin and your progenitors for the excellent primer on codecs. If not a full course, it gives me enough to use.

Re:

[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

Re:

[Rui del-Negro]

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

Re:

[russ1337]

Thanks for your comments. After having read your articles that you posted later in this thread it is obvious you know your stuff. Thanks.

I would be interested if you had a reply to JohnnyLocusts reply above...? http://slashdot.org/comments.pl?sid=237843&cid=194 40487 [slashdot.org]

Re:

[Rui del-Negro]

Not really, beyond telling him to read the H.263 specification...

http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T -REC-H.263-200501-I!!PDF-E&type=items [itu.int] ...where he won't find any reference to the MPEG (let alone MPEG-4, which was published after H.263).

MPEG-4 is "H.263 compatible" in the sense that a basic H.263 stream can be correctly decoded by a "complete" MPEG-4 video decoder, but MPEG-4 decoders aren't required to be "complete" (which is not to say that a lot of them don't cover what's requir

Re:

[CryoPenguin]

Yes, h.263 is a subset of MPEG-4 part2. Note, however, that h.263 has some extensions of its own called h.263+, and h.263+ is not a subset of MPEG-4 part2.

Re:

[Rui del-Negro]

Saying that could seem to imply that H.263 was "extracted" from MPEG-4, which was not the case. It would be more accurate to say that MPEG-4 part 2 was drafted in such a way that it covers everything required to decode "baseline" H.263 (there are some variations of H.263 not covered by MPEG-4).

In other words, basic H.263 is "covered" by MPEG-4 part 2 (but the two are not identical), whereas MPEG-4 part 10 (AVC) and H.264 are identical (they're separate standards, but there's a working group that keeps them

Re:

[russ1337]

Again, thanks. I appreciate your comments and I've certainly learned something.

H.263 baseline==MPEG-4 short header

[benwaggoner]

I'll take a whack at it.

H.263 baseline is the same bitstream as MPEG-4 pt. 2 short header (and forms the basis of the Flash Spark codec). Both H.263+ and ++ and MPEG-4 pt. 2 Simple Profile and Advanced Simple Profile have further (and different) enhancements to that core bitstream.

Being based on H.263 proved to be much more of a limit for MPEG-4 pt. 2 development than was original determined, which led to the development of newer codecs like VC-1 and H.264.

Re:

[Rui del-Negro]

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

Re:

[DigitAl56K]

Hey,

Product manager for the DivX codec here :)

It's always very difficult to run a comprehensive codec comparison because each of the competing codecs offers a wide range of settings, and to test comprehensively over many different clips and bitrate is extraordinarily time consuming - so kudos to the author of TFA. However, I'd like to offer some brief feedback:

• It would be my expectation (based on a lot of experience!) that Xvid and DivX should always be grouped tightly together. If this is not the case it

Re:

[SeaFox]

For those not wanting to read the article:
Rated best to worst with default settings
Low Bitrate go with XVID, DIVX, h.264, WMV

Wow, thanks for saving me from the time I would have wasted reading this article. As I know it has to be junk to say that XviD is better than h.264 at low bitrates,

Summary

[Silverlancer]

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.

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

[Noose For A Neck]

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

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

Re:

[benwaggoner]

Note that adaptive quantization isn't something particularly magic in x264. Our released VC-1 (WMV9) codec supports Differential Quantization and Adaptive Deadzone.

I just wrote up a blog post about using them in a downloadable 1080p version of the Elephant's Dream clip:

http://on10.net/Blogs/benwagg/elephants-dream-samp le/ [on10.net]

Re:

[Silverlancer]

It is something special about x264, because no other H.264 encoder has it. VC-1 is a joke though; its quality is absolutely laughable compared to H.264. Microsoft should be able to do better.

Re:

[benwaggoner]

I think our qualty is very competitive with H.264! Bear in mind that the majority of HD optical (HD DVD and BD) discs use VC-1. Did you check out my sample encode?

http://on10.net/Blogs/benwagg/elephants-dream-samp le/ [on10.net]

I've got lots of bandwidth - feel free to suggest a scenario where you feel VC-1 isn't competitive, and I'll see if I can come up with a counterexample.

Re:

[Silverlancer]

I did an encoding test of WMV9 and WMV9 Advanced Profile (VC-1) against x264-encoded H.264 High Profile using SSIM as the metric. The quality of WMV9 Advanced Profile was about the same as WMV9 but it dropped frames (!!!) and so it broke the SSIM measuring tool after 10-15 seconds of measurement, so I compared WMV9 and H.264 only. Let's just say that H.264 at 2000kbps was much better quality than WMV9 at 4000kbps, by a considerable margin.

Re:

[benwaggoner]

We've done lots of testing, and that hasn't been our results.

Can you share what settings you were using? If you're seeing a lot of dropped frames, one possibility is you cranked the Quality slider up to 100. That sets the minimum quality of each frame really high, telling the codec to drop frames in order to maintain data rate. A quality of 90 will give you much less trouble.

WMV9-AP is a superset of WMV9, so there shouldn't be any cases where you get fewer frames out of AP.

Also, the current codec has som

Re:

[Silverlancer]

I just used the Windows Media Encoder with the quality slider maxed (not the one that affects quantizer, the one that affects motion precision and so forth). I should probably try a more fully-featured VC-1 encoder. Are there any VC-1 encoders that support multiple reference frames, mixed references, rate-distortion optimization, and trellis quantization? Those are the main features that I find really help in H.264 over most other codecs (along with CABAC, of course).

Re:

[benwaggoner]

Actually, go ahead and use one less than the max complexity. It's actually ever-so-slightly better, and quite a bite faster, in the current verison.

As for most of the other feaures, you can get them via that PowerToy tool, or they're already on:

Multiple Reference Frames: Not explicitly supported in VC-1 (they're a huge decode complexity hit). Instead, we get the same benefit for stuff like flashes and strobes by using BI frames - an intra-only encoded B-frame, which then lets the frame after the flash re

Re:

[GeffDE]

What is laughable, however, is the fact that the H.264 codecs run on anything (mulitple OSes and processor architectures) while WMP is restricted solely to...Windows. VC-1 is completely uncompetitive, by default, for anyone not using Windows (and not using the latest version of WMP, which precludes anyone not using Vista or XP SP2 "Genuine.)"

That being said, will VC-1 ever make it to a wider audience?

Re:

[Goaway]

ffmpeg already supports VC-1. That's about as broad an audience as you get these days.

Re:

[benwaggoner]

VC-1 Main and Simple profiles *are* WMV9, and so are compatible to out of the box WMP9, 10, or 11, which gives compatibility down to Win 98 and 2K. WMV9-AP/VC-1 Advanced Profile, which is really only needed when you're doing native interlaced encoding, is an automatic free download for WMP 9 and 10, and installed with WMP 11.

On Mac, Flip4Mac is our recommended solutions for playing back WMV files, and we distribute it free for Telestream.

For other OS's, many companies have licensed WMV playback, like the K

Re:

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

Re:

[LarsG]

"Microsoft made the original reference encoder for MPEG-4 (hence the venerable MPEG-4v3 codec)."

The 'reference encoder' that doesn't even manage to output a valid MPEG4 bitstream? My hat off to Microsoft for the way they fragmented MPEG-4 part 2.

Re:

[benwaggoner]

Actually, there are a number of independent implementations of the VC-1 encoder not based on any input from Microsoft. Main Concept and Sonic Cinevision are probalby the most prominant. There's also an open source one that came out of a "Summer of Code" project.

I'm not really sure what you're getting at about Sorenson and all that. Sorenson Media had many generations of popular codecs. You're right about a connection between that and H.263 - reverse engineering determined a few years ago that the origin

You're a little on the history

[benwaggoner]

I'm not sure what you think really happened, but you've got some of the major facts wrong here.

First, the presentation of VC-1 to SMPTE always hat the explicit goal of standardizing WMV9, and everyone knew it. The working name for it for quite a while was VC-9 in explicit recognition that it was a standardized version of WMV9. WMV9's bitstream was locked down with the Corona launch back in 2001, well before H.264 was complete. If anything, H.264 got more from WMV9, for example the addition of variable block

Re:

[LarsG]

Dude, use [enter] once in a while.

MS has submitted VC-1 as a standard because they wanted an alternative to h.264 (aka Mpeg4 part 10 and Mpeg4 AVC). Their main selling point was that VC-1 would have lower licensing fees. Unfortunately for them, they underestimated the number of patents held by other companies. http://www.theregister.co.uk/2007/04/14/microsoft_ vc-1_codec_analysis/ [theregister.co.uk]

As for MSMPEG4v1/2/3.. MS did originally participate in the MPEG4 process, and during that time they released the MSMPEG4 codecs.

Re:

[Noose For A Neck]

Yes, thank you for pointing that out. I was referring to encoders in this instance.

Re:

[molarmass192]

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.

Re:

[Goaway]

WMV3/VC-1 is definitely not MPEG-4. You are confusing the ancient MS-MPEG4 codecs with the ones currently in use. And there are certainly areas where it might beat h.264.

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 [digg.com]

Grab it while you can.

Re:

[Anonymous Coward]

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

and everyone gets sent the same serial number:

Windows

SMYCU67X83BBA68TIT48

Mac OS X

358DSZ7D96C5X66BI48E

Nothing more expensive than free

[Lead Butthead]

DiVX demands your e-mail address to receive "reg key," then immediately sells your e-mail address to douche bag spammers.

Re:

[DynaSoar]

> DiVX demands your e-mail address to receive "reg key," then immediately sells
> your e-mail address to
[AHEM]
> douche bag spammers.

That didn't happen when I got their free codec. It didn't happen when I got their free package with the player and converter. It didn't happen when I bought the Pro version with the VOB conversion extension. It didn't happen when I registered an account with their site. It didn't happen when I changed my registration to add the fact I got a DivX capable home DVD player.

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 [apple.com] 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...

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

Re:

[autophile]

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

Re:

[forkazoo]

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

Re:

[toddestan]

I still think that the "Silicon Age" is what is ultimately going to stick.

Re:

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

Re:

[BitterOak]

Codec stands for COmpression/DECompression algorithm. There certainly are data formats for video which are uncompressed, but they are not Codecs.

Re:

[Doc Ruby]

No, CODEC stands for [reference.com] "coder/decoder", of which de/compression is only one kind of encoding.

As the article said, as I said, as the TMDS article to which I linked said.

Re:

[Doc Ruby]

There are plenty of software only codecs that don't compress, like G.711. The fact that TDMS is hardware, and is a physical layer rather than application layer encoding, is irrelevant to the falsity of the statement that all codecs compress. TDMS shows that even high bandwidth video can be encoded but not compressed. And it shows that sometimes size isn't as important as a cheaper codec (and downstream data processing) that handles uncompressed data at full bandwidth.

There are plenty of video codecs, such a

Image Algorithms

[Rac3r5]

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

Re:

[Silverlancer]

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

WMA 10 Pro LBR!

[benwaggoner]

Oh, I'm really a big fan of our WMA 10 Professional low bitrate modes (

And on a practical level, we support rate control modes rarely seen in other audio codec implementations, like 2-pass CBR and 2-pass VBR. This lets us get more bang for the bit compared to 1-pass CBR and VBR modes.

Re:

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

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 fo

Re:

[PitaBred]

And how does that help me, as a Linux user? Let me know when WMA is portable.

Re:

[benwaggoner]

The codec has already been licensed by vendors of Linux-based devices. We offer a complete source code implementation as a porting kit.

Re:

[Rui del-Negro]

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

Re:

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

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 [digitalmedianet.com]

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

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

Re:

[russ1337]

Wow dude. Those are some great, fantastic articles.

Re:

[Man Eating Duck]

Time to shamelessly plug my articles about compression.

I agree with the others here, incredibly good articles!
A very thorough introduction, and still easy to follow for a lay-person. Recommended!
You wouldn't happen to have written any other works of similar quality you'd like to share with us? :)

A question as well: Do you know if this Photoshop plugin (j2k) [fnordware.com] is a good implementation of jpeg2000? Maybe it's a stupid question, but I have no idea how strict the standard is, or if there are differences between

Re:

[Rui del-Negro]

Well, in English, for Digital Media Net, I've also written an article about the exciting subject of... alpha channels:

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

And I'll probably write a couple more, the first of which will be about HDR (high dynamic range) digital imaging. The problem with DMNet is they pay the same for a 3-paragraph article about "how to make your photos sharper in Photoshop" and a 20,000-word article about "how to build a working time machine and fix gl

Re:

[kinglink]

Even worse is the fact they have 5 codecs? Indepth look at video codec? More like "really fast look". I've used more codecs when I was converting old tv shows. Divx, Xvid? WMP7? x264 and Cinepak?

How about these tests....

Which one is the least hassle to set up?

Which one is the least hassle to convert from or to?

Which one is the most accepted format? (let's be honest, APE and FLAC might be good audio codecs, too bad only a handful of players play them but Mp3s play on every player out there that I know o

Re:

[Rui del-Negro]

Well, using the "must play anywhere" metric, I'd say MPEG-1 ranks the highest.

Re:

[kinglink]

Divx has been gaining enough support there that it's worth looking at. I'm not looking for stuff to work on antiquated devices, but can it work on the Ipod Video, is it easy to get codecs for use with software? Can you transcode it easily (minimal processor power)? Or even can you convert it easily?

The biggest problem any audio codec has is getting people to realize that while it might be better than MP3 for what ever reason you want to sell us, the new codec also has to be around the same size, and able

Re:

[Rui del-Negro]

If it's wrapped in a common container (ex., AVI, Quicktime) and if downloading and installing the codec is an option, then pretty much anything can be converted into anything (at least within the same container format), so the point becomes more or less irrelevant. I thought you meant "will play anywhere right 'out of the box' ", that's why I mentioned MPEG-1.

It's rarely necessary to have faster-than-realtime transcoding, so "how long does it take" is usually less relevant than "can it be done dynamically,

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:

[Overzeetop]

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

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

[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

Re:

[Miseph]

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.

Re:

[ChrisA90278]

Doesn't everyone get some Fourier analysis in college these days?

No, The people who study English, Journalism and Education don't have to take any math past finger counting. OK, well maybe decimals and fractions. It's quite rare to find someone who can understand "technical stuff" and write well enough to explain it.

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

Re:

[autophile]

You forgot the start- and end-markers for compression: o hai, and kthxbai.

--Rob

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 [3ivx.com]

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.

The meaning of "print"

[autophile]

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

>:(

--Rob

What about Wavlet CODECs?

[SpinyNorman]

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

Re:

[imsabbel]

Wavelet based codec SUCK for video. REALLY REALLY REALLY suck.

You can get a bit of boost by compressing the I-frames with wavelets, and doing P/B frames classically, but that aint giving you much of a benefit, at the cost of having to worry about the convolution of 2 completely different error sources.

(and yeah, i know stuff like snow. Those actually prove that point)

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

Factual errors...

[evilviper]

From TFA:

an uncompressed two-hour film in digital cinema resolution and quality will clock in at about 12 terabytes,

That number doesn't sound REMOTELY reasonable.

4K is 4096 x 2160 = 4,527,360 pixels/frame

32bpp per pixel == 144,875,520bits == 17,685 kilobytes/frame

4K is 24fps == 424,440 kilobytes/sec.

2 hours == 7,200 seconds

Which makes 3,055,968,000 Kbytes total or 2.846 Terabytes for 2 hours of uncompressed video.

And I agree with everyone who's already said how useless this article is. If you don't unders

Re:

[evilviper]

I think your calculator had a meltdown.

Good catch. I imagine that number was due to a typo.

Re:

[Rui del-Negro]

"AVI" is a container format, AVI files can use hundreds of different codecs.

If you want the best possible quality, stick to the original format (ex., if your source are DV tapes, use DV-compressed AVI or MOV files).

If you want the best quality vs. size ratio, a MPEG-4-based codec (ex., XviD, x264, etc.) is probably the best choice. Using an AVI / MOV container will give you compatibility with a lot of existing software.

Good luck using Theora with video editing / compositing software...

Re:

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

Re:

[Constantine XVI]

You mean like H.264?