Comparing Codecs for 2004

MunchMunch writes "Popular encoding/guide/news site doom9.org has just put up its codec shoot-out for 2004, comparing 3ivx 5.0, Divx Fusion 5.9 (prerelease 6.0), Nero Digital Main Profile and High Profile, RealVideo 10, On2 VP6, VideoSoft's VSS, Xvid 1.0, MS's WMV9 and, last, newcomer Jomingo's HDX4. The comparison covers the speed, accuracy, target-file-size-adherence and other aspects of the codecs -- but also lets you compare yourself via high- and low-bandwidth framegrabs of each codec with a nice zoomable image-swap script."

Comments

Progress

[bigberk]

Overall, the progress is just astounding. When I compare clips of say movies from 3 years ago to ones you can find now, the file sizes have remained the same but the quality of both video and audio have gone way up. I don't know much about video codecs but I do recall back then there still being MPEG 4 in the game, so maybe it's more about modern tweaks?

Re:Progress

[bigberk]

Also makes one snicker... I recall content producers saying that selling high quality television/video streaming over the Internet is not feasible (the amount of data that has to be shipped). Well, they were wrong it seems... instead of putting all that money in lawyers' pockets, they could have helped develop technologies to produce new revenue streams. As is, they sat idly by while others made the technologies that will probably obsolete TV/movie content producers.

Re:Progress

[lavaface]

they sat idly by while others made the technologies that will probably obsolete TV/movie content producers

It's just a small point, but I think it's the distributors who are in for a rude awakening. The producers of content will continue to thrive.

Time to move on?

[zmollusc]

Erm, this may only apply to old codgers with failing faculties like myself, but I think that a level of acceptability has been reached.
Just as mp3(and similar) is good enough to listen to and jpg, bmp and gif are good enough for the various static images needs, divx(xvid) and mpeg2 fill the processing requirements for moving images.
With the cost of storage falling there is less need to build a higher compression video codec. If you want to do some good, come up with faster and higher quality ways to transcode things to an existing open codec standard.

Re:Time to move on?

[HFShadow]

No, they don't meet the processing requirements. "Just as mp3(and similar) is good enough to listen" - Mp3 files are small enough that even when encoded at a high bitrate, you can download a file reasonably fast. Audio quality is also alot more subjective to the listener then video is. Anyone can take a video and pause it and point out all the things that don't look quite right, something that can't be done with an MP3. Also since you know what a video is "supposed" to look like, you notice the errors more. Those stairs aren't blurry in real life, why are they in the movie? Same for faces, rain and other objects. Video codec's will always be worked on and updated, as higher quality video is demanded, sizes get larger and larger and more unworkable. When you have a large HDTV, do you really want to watch a divx video with blocky motion artifacts?

Re:Time to move on?

[liangzai]

What you are saying is that 640 kB should be enough for everyone, or that since we have Microsoft Word we have reached a level of acceptability...

This is not so, since new codecs do so much more than conserve bandwidth (which is in itself a good purpose, considering the Slashdot effect and other congestions that will always occur on tah intarweb). Some of them DO have better quality per se than MPEG-2, and some of them DO scale enormously much better. MPEG-4 was developed for these and other reasons, and there is a tremendous need for such a codec, not least from a wireless perspecive.

Furthermore, it would be desirable to have a codec that can handle as many things as possible, rather than relying on a bunch of different codecs for different purposes.

Finally, I believe in standards rather than proprietary formats and codecs. DivX is fine, but it is a bastardized version of MPEG-4, and there are also many different implementations. Most of them generate errors in VLC, whereas I have yet to see a failing MPEG-4 video.

There are also the aspects of cross platform implementation (forget WMV9), simplicity, scalability and ingenuity in the architecture (why Quicktime was chosen as the MPEG-4 file architecture), and industry support (everyone but Redmond City supports MPEG-4). There.

Mission option!

[serviscope_minor]

What about the mpeg4 codec from ffmpeg?

Re:Mission option!

[Replicant7]

.. but blocky artifacts are easier to repair with postprocessing ..

Re:Theora works.

[Weird O'Puns]

As I said, Theora is good at lower bitrates but with higher bitrates there's still some performance problems with the codec. The Doom9.net comparison focused on ripping movies and they used bitrates between 600 - 1000 kbps. At these rates the Theora codec still performs quite poorly.

If (or when) the developers manage to solve these problems Theora will become a viable codec, but if they had reviewed it now, it would have only gotten a bad publicity.

Re:Theora?

[Bulln-Bulln]

Argh, I don't like to reply to myself, but check out the first page:
"I've re-included Microsoft's WMV9 (...)"
This means that WMV9 was dropped in the past, too.

It contimiues: "(...) especially since it is part of the specification of HD DVD and Blu-ray. There have been some improvements in WMV9 (...)"

So this means that Theora is not dropped forever. When Theora hits a significant milestone (1.0?) and shows improvements in quality over VP3, it's likely to be tested again.

Re:H.264

[michaeldot]

Thank you for today's example of Apple fanboy hating curmudgeonliness.

Fanboy or not, he gave useful information: H.264 does indeed have more industry credibility than the list of toy codecs who main use is to swap pirated TV shows on the eDonkey network.

And the fact that you've started to get modded up informative is what gives Slashdot a bad taste in the mouth.

Seriously, this place is looking more like comp.sys.advocacy.* every day...

Theora is a victim of xiph's own anti-marketing

[rseuhs]

The sad truth is that as long as xiph is dominated by stubborn, arrogant technocrats, it will have a pretty hard time.

Ogg-Vorbis is the best audio-codec technically - but everybody calls it "ogg" and not "ogg-vorbis" because the file extension is .ogg

Effectively, xiph does everything possible to sabotage their own product: It doesn't have a good sounding name, it doesn't have a consistent name ("ogg" versus "ogg-vorbis"), they don't have any buttons/banners to put on products on xiph.org and there is lots of confusion about container format (ogg) and codec (vorbis), which is the "U"-part from FUD.

The only reason anybody uses ogg at all is because it is excellent technically and beats all other audio codecs by a longshot.

Unfortunately, the guys at xiph don't acknowledge that fact and insist of wanting to have videos with .ogg extension, too, which is doomed to fail because nobody wants to have audio and video to have the same file extension.

The users have created a pseudo standard file extension of .ogm for XVid/Vorbis streams which does quite well in the P2P-networks (= successful), but Ogg/Theora has the problem that it isn't as mature and even when they mature probably won't be *that* much better than the others. So even if the xiph guys manage to put out a competitive Theora codec, their own confusion and uncertainity (especially their stubborn and idiotic decision to have .ogg for both audio and video) will sabotage any hopes of success, the way I see it.

Which is really unfortunate.

Things would be much better if they would use .ogt or something for ogg/Theora, but the guys at xiph just refuse to :-(

Flawed comparison?

[spectecjr]

Am I the only person here who thinks that recompressing an already MPEG2 compressed source is going to cause lots of problems for other compressors? At the very least, they now have to deal with block quantization artifacts, and all of the associated ringing etc.

Not to mention that because the sources were not compressed in a lossless fashion, there's less data to work with than they started out with.

So I guess if your goal is to test how well other codecs can recompress MPEG2 data, it's all well and dandy. What might be a better test is to see how all of the codecs work on DV encoded data, as that is rapidly becoming a common source of video information.

Re:Flawed comparison?

[Anonymous Coward]

The 'flaw' is that the study was targeted towards backup of DVDs, so it's not really flawed. The best general test would be to generate some high-quality uncompressed (or Huffyuv) material and run it through the codecs. Perhaps one could use the newest BBC test card as one of the tests, as it includes quite a bit of stress testing (perhaps designed for MPEG-2, but might be usable with MPEG-4 or H.264/AVC).

DV wouldn't give as good results, given the lower chroma resolution, although the 25Mbps CBR can make up for that in some cases, exhibiting less blocking in the source (although most professionally mastered DVDs don't exhibit too many blocks).

Re:Winner

[Dahan]

Um, libavcodec isn't a codec. It's a library implementing various codecs. So which codec in libavcodec did you want to test?

MPEG1
MPEG2
MPEG4
MSMPEG4 V1
MSMPEG4 V2
MSMPEG4 V3
WMV7
WMV8
H.261
H.263(+)
MJPEG
Lossless MJPEG
DV
Huff YUV
FFmpeg Video 1
FFmpeg Snow
Asus v1
Asus v2
Sorenson Video 1
FLV
ZLIB

Those are the video codecs that libavcodec currently implements an encoder for.

It sounds like you've confused the codecs with specific implementations of those codecs.