Video Codec Comparison 266
FonkiE writes "Doom9 wrote a good article: After more than 3 weeks of work and no free time during that period it has been done: The latest codec comparison is online. 7 codecs have been put through one of the hardest tests in the history of codec testing. The results: find out on your own ;) I had planned to change the presentation somewhat but certain events (forum problems and such) prevented me from completing this for the release. I plan to eventually supply an updated version of the comparison."
Spoiler! (Score:5, Informative)
For animated features, the two proprietary solutions deliver good results with XviD pulling slightly ahead.
heh (Score:5, Funny)
test 2: Saving Private Ryan
test 3: Futurama
Heh, the pinnacle of humankind's moving image creations
Re:heh (Score:4, Informative)
I agree that some better choices could have been made though (keeping in mind this is a video test only), such as:
- Terminator 2: Ultimate Edition.
- LOTR: Fellowship Extended DVD.
- Star Wars EP 1 or 2.
- Bridge on the River Kwai (awesome 2.40:1 transfer).
- Lawrence of Arabia
- Doctor Zhivago
The last 3 are about as visually stunning as movies can get.
Why use Jpeg? (Score:5, Insightful)
Re:Why use Jpeg? (Score:2, Informative)
View in your favorite slideshow program.
Re:Why use Jpeg? (Score:2)
Does the phrase 'slashdotted' mean anything to you?
-s
Re:Why use Jpeg? (Score:2, Insightful)
I
Should have used PNG (Score:2)
Of course, encoding in JPEG @ 100% quality would have been effectively as good. There really isn't any excuse for having still image artifacts on top of the source artifacts in this kind of article.
Re:Why use Jpeg? (Score:2)
It's not like PNG is a new image format...
Re:Why use Jpeg? (Score:2)
It would have been better to not show any screenshots at all than to show screenshots that distort the quality of the tested codecs.
music codecs (Score:2, Insightful)
what is odd is that while the final mp3 shows only 12% rms distortion (actually that's a fair bit if you're an audiophile) the intermediate AIFF shows massive added noise when I convert by imovie. this added noise is spread over the spectrum but has significant c
Re:music codecs (Score:5, Informative)
Like you said, out of band from the codec's point of view is the most likely answer I can give without playing with the files myself.
quite the wrong way to go about it (Score:5, Interesting)
Re:music codecs (Score:2)
Re:music codecs (Score:2)
there's issues other than psychoacoustics (Score:2)
Mirror available (Score:5, Informative)
mirror [128.220.194.209].
nice article, but.. (Score:5, Interesting)
many things left out... (Score:4, Informative)
Re:many things left out... (Score:4, Informative)
Re:many things left out... (Score:2)
Re:many things left out... (Score:2)
Bink? (Score:4, Interesting)
Re:Bink? (Score:3)
Who knows.
Re:Bink? (Score:3, Informative)
Bink's adavantages are a really mature, widely ported (lots of consoles, Mac, Windows, Linux), fast, and highly-featured API. However, its internal codec isn't really THAT great in terms of compression efficiency (bang for the bit). It's fine for CD-ROM games where having a rich, fast, stable video playback system is more important than keeping space to a minimum. But I certainly wouldn't use it for content to be downloa
Re:Bink? (Score:2)
3ivx and encoding (Score:5, Interesting)
The video quality is actually pretty damn good, IMO. I suggest trying it out for yourself. Check my webpage for more relevant information.
Re:3ivx and encoding (Score:2)
The fact that Vorbis audio is standard in OGMs is good enough for me. Quicktime still doesn't have built-in support for Vorbis, AFAIK.
Also, 3ivx isn't your only option. You could just as easily have used VP3, and would have had no licensing/patent problems to deal with. Not to mention that it's almost universally accepted
Sigh, Quicktime and MP4-video? (Score:4, Interesting)
Re:Sigh, Quicktime and MP4-video? (Score:4, Informative)
Re:Sigh, Quicktime and MP4-video? (Score:5, Informative)
Re:Sigh, Quicktime and MP4-video? (Score:3, Informative)
Re:Sigh, Quicktime and MP4-video? (Score:4, Informative)
Quicktime is a framework, with encoding, codecs, playback, and other features.
Quicktimes also has an mp4 implementation, as well as Sorenson, h264, mpeg2, and others.
Re:Sigh, Quicktime and MP4-video? (Score:2)
Quicktime is a framework, with encoding, codecs, playback, and other features.
Quicktimes also has an mp4 implementation, as well as Sorenson, h264, mpeg2, and others.
And don't forget that mov is the official container format for MPEG-4.
Which formats are the most durable? (Score:5, Interesting)
Are any file formats and codecs likely to be visible?
Re:Which formats are the most durable? (Score:2)
Seriously, I think that the persistence of Atari video cartidges and C64 hackers proves that we will have access to this stuff, at least on a hobbyist basis, for a long time.
Re:Which formats are the most durable? (Score:5, Informative)
Re:Which formats are the most durable? (Score:5, Informative)
To repeat: DivX5 and XviD are both implementations of the core MPEG4 specification, plus some set of optional features which are included in the MPEG4 specification, plus an extra or two which don't really make any quality differences (yet).
Re:Which formats are the most durable? (Score:2)
Re:Which formats are the most durable? (Score:3, Informative)
Actually, the 'official' container format for MPEG-4 is Apple's .mov format used in QuickTime. .MP4 files are usually just raw MPEG-4 bitstreams dumped into a file with no real container format.
Re:Which formats are the most durable? (Score:3, Informative)
This is incorrect. MP4 is a container file format, originally based on the QuickTime .MOV format. Google: mp4 file format, or see ISO/IEC 14496-1, "Information technology - Coding of audio-visual objects - Part 1: Systems" (MPEG/4 systems specification).
Re:Which formats are the most durable? (Score:4, Insightful)
Re:Which formats are the most durable? (Score:2)
Dave
Re:Which formats are the most durable? (Score:2)
Re:Which formats are the most durable? (Score:2, Informative)
Only disadvantage is the size of the videos, it only compresses to about 40% of the uncompressed original.
Re:Which formats are the most durable? (Score:2)
MPEG1, still the best (Score:4, Interesting)
1. MPEG1 is not encumbered by patent problems as MPEG2 and 4 are. http://www.mpegla.com Thus it is effectively free-as-in-beer by default.
2. MPEG1 is playable everywhere from the old Solaris and SGI boxen to the newest PCs.
3. No finding out after the fact that the
4. It is not a tool to let Microsoft, Sorenson, or Real dominate all online video and divide the web into gated communities.
Re:MPEG1, still the best (Score:5, Informative)
Defines the "transport stream", for delivery over unreliable networks (Internet). MPEG-1 only has the concept of "program streams", useful only for data stored on a reliable media (eg CDROM or DVD);
Defines profiles and levels, which put contraints on ranges and parameters. For example, MainProfile @ MainLevel is good for standard def video, while MainProfile @ HighLevel is suitable for HD;
Support for interlaced pictures;
16:9 aspect ratio, pan and scan;
scalable coding profiles, 3:2 pulldown, concealment motion vectors, 9-10 bit quantization, etc, etc etc
MPEG-2 is really what spawned the digital video age, and it's the standard used for practically all of the digital video that you watch (digital cable, satellite TV), DVD, SVCD, and many PC codecs.
MPEG-1 just doesn't cut it for all of these applications.
MPEG-1 can change aspect ratio (Score:2)
While all of the above are important for digital broadcasting applications, for storing progressive-scan content, MPEG-1 is pretty much identically good, and players are much more widely distributed (it still costs $2.50 to distribute a MPEG-2 decoder legally).
Mock me , or curse my not-so-good sight (Score:2)
Where's libavcodec/ffmpeg ? (Score:4, Informative)
Re:Where's libavcodec/ffmpeg ? (Score:2)
Profile@Level (Score:2)
For an encoder Profile@Level defines the maximum features you can use to make a compliant bitstream (so it's okay not to use all the tools and still claim to make an Advanced Simple stream - the encoder is compatible, just not maximum quality)
Re:Where's libavcodec/ffmpeg ? (Score:4, Informative)
Now, I haven't tried xvid/Divx in quite some time, but I can still say that, of the mpeg4 videos I'e downloaded, commonly encoded with Divx 4/5, Xvid, and 3ivx, the quality is always lower than what I can get from ffmpeg.
In addition, I'd say the reason you don't see more ffmpeg videos is just because there aren't that many Unix machines around. You probably haven't downloaded even 10% of the videos on the internet, so you probably can't make a fair estimate. Also, the legal issues (licensing) lead most people to stick with Divx, WMP, or Quicktime. Also, it's not hard to imagine that Ffmpeg would gain popularity if it came in a simple, easy-to-use, installer for Windows.
Arrrr Maties...
What a decoding (Score:3, Insightful)
Re:What a decoding (Score:3, Informative)
link to latest ffdshow (MPEG4 decoder) binaries (Score:2, Informative)
http://sourceforge.net/project/showfiles.php?group _id=53761 [sourceforge.net]
use the latest alpha version.
Compressing the Compressed!!! (Score:2, Interesting)
Re:Compressing the Compressed!!! (Score:2, Interesting)
Re:Compressing the Compressed!!! (Score:3, Informative)
I've done some work in video compression, and it was a non-trivial task to get never-compressed source. Indeed, we had to generate it ourselves, and were limited to low-motion real life (stop motion-style pan over a roo
Re:Compressing the Compressed!!! (Score:2)
Still, it befuddles me how much time people are willing to spend copying a DVD that only cost
yay, the good guys won (or something) (Score:3, Interesting)
I've been semi-following XivD for about a year, occasionally compressing one of my DVDs to see how it's doing. (which always seems to be: Great, but better the next week (i.e. a severe double-edged sword!).
One thing you know about Xvid is that those problems (the ones Doom9 found) will get addressed. Cheers XviD team.
Isn't there something missing from this "review"? (Score:4, Insightful)
There's a reason why you're really supposed to re-encode from the CD when you're producing
The same applies to video files.
This is not to say that what Doom9's doing isn't important or relevant- it is if you're using the codecs to space shift (i.e. Put several movies on your laptop so you're not carrying the DVD's on your business trip...) or pirating movies. The reality is that the codecs he's reviewing are largely designed for previously untouched video feeds- someone ought to test that as well.
Anything else is not really a proper review- unless you're only caring about ripping and re-encoding DVDs. To me, that's something useful to know about, but I'm as or more interested in the intended usages of this stuff as well.
Re:Isn't there something missing from this "review (Score:3, Insightful)
Re:Isn't there something missing from this "review (Score:2)
What I don't agree with is the use of JPEG to encode captures of the footage for demo purposes. PNG would have been a far far better choice. I know still images alone are never a good indication of a c
Re:Isn't there something missing from this "review (Score:3, Funny)
DivX 5 (Score:2, Interesting)
Re:DivX 5 (Score:2, Informative)
Or you can just DL FFDSHOW (check SourceForge. I reccomend the Alphas... lots of features yet quite stable) And use that to decode all your MPEG4 type files.
Ah, that's why we have ffdshow (Score:2, Interesting)
The format war continues, but ultimately the majority of the codecs are trying to implement the mpeg4 standard. Surveys and comparisons aside, if you trawl around you'll find that most "users" (ie not companies) are using either DivX3/5 or XviD.
Some clever individual has come up with ffdshow, which you can get off doom9.org, which will play either DivX or XviD without having either codec installed on your system. And at around 500k, it's a smaller download than either of those codecs
Tables Aversion? (Score:2, Interesting)
Helix license forbis comparison? (Score:5, Interesting)
https://reguseronly.helixcommunity.org/2002/cli
Entry 2(a)(vii)
You may not make available to any third party the results of any evaluation or testing of the Software by You under this License. Any such forbidden use shall immediately terminate Your license to the Software.
Just a thought
Similar test in current issue of C't magazine (Score:2)
Sound and vision... (Score:4, Interesting)
For whatever reason, some programs mess up the spacing of the video and sound streams, for example, Variable Bit-Rate Audio often gives problems. The thing is that it isn't the video codec itself, just the delays getting sound and vision to run concurrently.
How much detail is needed? (Score:3, Interesting)
Don't believe me? Try this: scroll through the screenshots (at about the rate of 1 image going from the bottom of the screen to the top per second - 1fps) and tell me if you can pick out the glitches in most of these codecs.
What's more, if anyone was walked into several rooms in sequence, all playing the same movie, but one being DVD, one being DivX3, one being WMV9, etc. I suspect nobody would be able to distinguish one from the other, provided they're encoded at one of the higher quality settings - even if they're intimately familiar with the film.
This is a load of garbage. DVD is a broken codec to begin with.
How are we supposed to know... (Score:2)
Why only 2-pass? (Score:2)
An increase in quality has been debated, but DivX with six passes has, at least for me, always come within 1MB of the target size and never over.
Re:after working with lots of them (Score:5, Informative)
I had that problem early on, then I found the 'Maximum Quantizer' setting. It defaults to 16. I think what that means is "How big of artifact should you allow?" (I'd appreciate some correction on that if I'm wrong...) I turned that down to 8 (sometimes even 4) and it behaved MUCH better.
Just thought I'd recommend you try that. If you already have, I'm not sure what to tell ya. I've had pretty good luck with it, but I haven't compared it to MPEG2 because the video I do is pretty much for web delivery.
Re:after working with lots of them (Score:5, Informative)
Bitrate is generally controlled by modifying the quantizer values as the video progresses. So lowering the maximum quantizer is the same as specifying a higher minimum bitrate. In theory, a good implementation of a codec (using 2-pass quality-based VBR, B-frames, QPel, etc.) will function best if you don't restrict it's choice of quantizer. However, a really high quantizer value generally means that the codec screwed up, so limiting it doesn't hurt too much.
What is a quantizer? (Score:5, Informative)
To compress a sample of audio or video data, you want to throw away details that don't matter. So you transform the data using a function, and then you apply a quantizer to throw away some of the data. The whole point of the transform function is to make a data set that is "safer" to quantize.
Most audio and video codecs use the DCT function, which decomposes an image into a series of waves. If you throw away some of the wave data, you get a similar series of waves, and hopefully humans won't notice the differences.
Applying the quantizer is the "lossy" step in lossy compression. Here's how you do it:
You divide the output data (from the transform function) by some integer number, the quantizer, and you use integer division. (Because you want to simplify the data, you actually want the fractional part discarded!) The bigger the quantizer, the more data is thrown away. A quantizer of 1 would give perfect quality, but very poor compression.
Here is a semi-real example:
You have some data to compress. Let's say it's eight bytes (maybe an audio sample for Ogg Vorbis).
After the DCT, it looks like this (using decimal numbers because it's easier):
355 244 33 192 43 9 3 8
Quantize with a quantizer of 8:
{8} 44 30 4 24 5 1 0 1
The {8} is intended to show that the quantizer has to be stored with the quantized data stream, so we know what quantizer was used so we can dequantize.
On dequantization, we just multiply by 8 again:
352 240 32 192 40 8 0 8
Then we feed these resulting numbers into the inverse DCT, and get back some data that is hopefully not full of artifacts.
When you are encoding, you quantize, and then you encode the resulting stream of numbers. Because the values of the numbers are smaller (e.g. 24, instead of 192) you can encode the values with fewer bits. And you can apply run-length compression to the quantized values; in my example it wouldn't buy you much, but in real examples you will often have a bunch of zeroes in a row.
Video compression dialogs (such as the JPEG options in "Save As" in The GIMP) often give you a slider for a quality percentage. This is actually controlling the quantizer. For JPEG, you have 31 possible settings for the quantizer, so there is no difference between 80% and 81%.
By the way, my personal experience with video compression is that a quantizer of 8 gives pretty good compression with very few visible artifcats. An 8 quantizer corresponds with about a 75% in the quality sliders (such as Save As in The GIMP).
Some afternoon when you are bored, save the same JPEG image over and over with different quality settings, and watch what happens with the artifacts. When you set the quality down to 2% (corresponding to a 31 quantizer) you get ugly, coarse blocks. The GIMP under Linux is particularly good for this because you can drag the quality slider and the preview updates instantly, so you don't have to save and re-open.
steveha
Comment removed (Score:5, Funny)
Re:after working with lots of them (Score:3, Informative)
Re:after working with lots of them (Score:5, Informative)
In any event, the differences in quality you see are more than likely related to implementation (i.e. differences in spec implementation between XviD, DivX 5, MS Mpeg-4, etc.), user error, and the fact that you're taking a compressed video source and compressing it again. Although many people do insist that Mpeg-4 over-quantanizes black and other 'dark' colors, resulting in no true 'black', that could just be perception.
For a better view of how something like this works, open a PNG, save it as a JPG with a high compression level. Open the JPG, save it as a another JPG with a high compression level. Repeat 10 times and tell us the result.
Re:after working with lots of them (Score:5, Informative)
One issue that sometimes bites people is converting between RGB-style and YUV-style color spaces. A round-trip from 8-bit R'G'B' to 8-bit Y'CbCr is always lossy, although not terribly so. The killer is when different codecs disagree on how to map the R'G'B' values to Y'CbCr values. MPEG-2 is nominally Y'CbCr with Y' in the range 16-235. Some encoder expect R'G'B' values in the range 16-235 and others expect 0-255. If there is a mis-match, shadows and highlights will get clipped and the translation will be much lossier.
IMHO the non-video parts of MPEG, like "face compression," are just wishful thinking. Most optional parts of the spec are only going to be implemented by one or two vendors.
Re:after working with lots of them (Score:4, Informative)
DV is compressed at a fixed 5:1 ratio.
Uncompressed video at a resolution of 720x480x24 is ~1MB per frame and 1.7GB per minute (at 30fps). DV uses about 220MB per minute including sound.
Re:after working with lots of them (Score:2, Insightful)
Yeah, I do mean the developers of DV, however this doesn't appear to be the most complex codec to build in the world (if only the author's website was still up) -- I was just wondering why they never thought of this. Then again, at a decade old, I doubt any hardware could have handled it in realtime, so it makes sense that even if they had thought of this scheme they would have dropped it.
Re:after working with lots of them (Score:5, Informative)
However, a lot of the features included in MPEG4 make it equivilent to MPEG2 in quality potential. It would be proper to think of MPEG4 as MPEG2 with a bunch of extra options. If you turn the options off, then you can expect very similar results. Since people generally are using MPEG4 to generate medium-quality (say, around SVHS) video at low (yes, 3 hours of video on 2 CDs is _low_ bitrate), most implementations are much more aggressive about allocating bits than most MPEG2 implementations are. Indeed, at the target bitrates people are choosing, most MPEG2 implementations will utterly fall apart (although MPEG2 itself ought to hold up better than actual performance would suggest).
Among the key new features of MPEG4 are:
1) QPel - MPEG2 allows you to say that a block in a frame is the same as a previous (or future) frame shifted by x pixels, or x.5 pixels, or is kinda like this block and kinda like this other block. MPEG4 extends this to quarters, rather than halves. This is supposed to really help very low motion, or small variations in globally compensated motion.
2) Global motion compensation - MPEG4 allows you to say that the whole frame is panning/sweeping so-and-so much, and then make localized offsets. Actually, IIRC, it lets you make "global" statements at the object level, which leads to...
3) Object-based decomposition - consider a video scene. You have a background, and several "objects" in the foreground. In theory, it would be nice to encode the background with low-motion assumptions (or constant panning assumptions), and the foreground with higher-motion assumptions. Additionally, picking out the different objects in traditional cel-style animation should let MPEG4 totally kick-ass in compressing animation. In practice, all of the techniques for separating out objects automatically suck royally (how you identify objects is not a matter of the spec, the spec just says that if you've separated out, you can handle them individually and paste them together later). This is MPEG4's biggest unrealized potential. The first implementation with good object decomposition should be a huge improvement over all past attempts at video compression. OTOH, don't hold your breath waiting for good object decomposition--it's a "hard" problem, as in computer-vision hard. Developing even half-way decent object decomposition ought to be good for at least 3 or 4 PhD theses.
4) MPEG4 is looser. Just in general it leaves more things up to the encoder, such as what quantization tables to use, letting you vary q-levels more drastically, etc. Also, IIRC, MPEG2 only allows for certain fixed ratios of B-frames and P-frames. MPEG4 loosens these restrictions (all the way?) to allow much greater use on B and P-frames. These frames (especially B-frames) tend to be very compressable, although there are signifigent CPU-usage tradeoffs involved. If nothing else, MPEG2 implementations will almost never let more than 8 frames go by without an I-frame, regardless of whether the spec allows more or not.
5) MPEG4 includes a wavelet-based transform for certain elements. I don't believe that anybody actually uses it for anything, but it is in the spec.
6) Not a spec difference, but in practice, only MPEG4 uses 2-pass encoding. MPEG2 is heavily used for live stuff (well, 3 seconds delay for the censors plus a second for motion comp), and 2-pass is not an option. 2-pass has been implemented in MPEG2 (indeed, the first work with 2-pass was done with MPEG2), but the idea is relatively new. So most MPEG2 implementations don't do 2-pass, and never will, since all the new development effort is going into MPEG4. Many/most MPEG4 implementations include 2-pass since it lets the coder be much smarter about bitrate allocation, and it is a known technique.
That just about sums up the major differences between MPEG2 and MPEG4. Oh yeah, and MPEG4's number is 2 higher
Re:after working with lots of them (Score:2, Insightful)
WTF? Never seen a DVD-Video, then?
This whole test is bullshit because a) all their source material was compressed and b) they left out some of the best GENUINE, commercial codecs. Total waste of time.
Re:after working with lots of them (Score:4, Interesting)
The trick to good encoding is in knowing how to use NanDub (or VirtualDub, or VegasVideo, or whatever you use..) and knowing ALL of the various little settings that can be tweaked. The default settings INVARIABLY SUCK, with the quantizer matrix being set for fast, crappy quality video output. The max. quantizers (if using SBC or DivX5) should NEVER exceed 9, for example; however, the default is usually 31! You shouldn't use the default settings and still expect near-DVD quality.
I'm writing a proper, updated tutorial on SBC and Divx 5 Pro right now, which I will submit to various newsgroups when it's done. In the meantime, check out Doom9.org for a rough idea of how to rip properly. They ignore some pertinent details (ie, filters - esp. contrast filter) but you should get a very good idea of the work involved to produce a decent rip.
Re:after working with lots of them (Score:3, Interesting)
At NAB I demoed a 1280x720 24p 4 Mbps MPE
Re:For my fellow ADD'ers (Score:5, Funny)
Yes, this comparison of video codecs is quite HEY LOOK A GUY ON A BICYCLE!
Re:For my fellow ADD'ers (Score:2)
Re:For my fellow ADD'ers (Score:2)
ObSimpsons ADD reference:
"hey! That kid has bosoms!"
"Don't chase me! I'm full of chocolate!"
etc etc...
Re:Doom9 is my hero, dvd2svcd owns you. (Score:4, Informative)
Re:Doom9 is my hero, dvd2svcd owns you. (Score:4, Informative)
Re:Doom9 is my hero, dvd2svcd owns you. (Score:2)
XviD is licensed under GNU GPL. Open source as it gets.
As for Theora, it's not even half done.
Re:Doom9 is my hero, dvd2svcd owns you. (Score:2, Informative)
This might also be the reason it is only distributed as source code.
Re:Doom9 is my hero, dvd2svcd owns you. (Score:3, Funny)
Also, where's Ogg Tarkin? A video codec test isn't complete unless an vapourware Free codec is there to rank with all the real proprietary ones.
Re:FFMPEG (Score:2, Informative)
This is for the average user (Score:2)
99.99% of people don't have the hardware necessary to do uncompressed video, either their camera can't do it, their video card can't do it, or their hard drive can't write it without dropping frames.
640x480[low res]x30[fps]x3[bytes per pixel]= 27.6 MB/sec sustained writing. Or you can try doing HDTV resolutions at 83 (720p) to 186 (1080p) MB/sec.
Re:Ogg theora? (Score:4, Interesting)
Unfortunately, it appears that Ogg Theora development is "mostly dead". The main developer has been stuck doing contract work (on the integer decoder for Vorbis, as far as I can tell) and can't get to it "for the foreseeable future". The mailing lists are almost completely dead, and, most tellingly, Xiph hasn't updated the theora.org page since January.
I doubt very much they'll have the 1.0 release next month as they have been saying since last June that they'd do...Alpha 1 was looking really promising, but Alpha 2 got pushed back twice (originally scheduled for early December 2002...then late December...then they stopped talking about it anywhere.) Last I'd heard was they were planning to skip Alpha 2 and go straight to Beta in March. Obviously that didn't happen. I do know Monty managed to get some (non-Theora-specific?) work done that will benefit Ogg Theora, but that was back in February, and nobody's talking about it since then.
There are hints that there are other people puttering with the code a little (and VP3 decoding support [the "video codec" part of Ogg Theora - I gather there are still a few "tweaks" to be worked out to turn VP3 into "Ogg Theora"] is slowly being worked on for ffmpeg [sourceforge.net], Xine [sourceforge.net], and MPlayer [mplayerhq.hu].) but I don't know if Xiph has enough attention on it to get anything out. (Support for VP3/Theora video codec going into Xine is mentioned - very briefly - in the latest "Ogg Traffic" newsletter [vorbis.com] which at least indicates SOMEBODY remembers that Theora exists. I think if they at least got out some documentation on the format (particularly the .ogg part - they say .ogm is 'horribly hacked' but until there's a "proper" standard available for people to work to, that's all we have for "video-in-ogg") it would help. (If encoding support for Theora in ffmpeg/mplayer isn't far behind, then adoption and work on it outside of Xiph will probably pick up pretty quickly.)
Kinda sad to see the project languish silently as it has for most of the year - some days I can't tell if Xiph will be abandoning Ogg Theora or ever getting back to it or what...
As a side note, back on the topic of "codec comparison", my playing with the one and only release of Ogg Theora way back when it was released (8 months ago!) gave me the impression that it can be a very nice format, especially for more compressed bitrate. Where most codecs seem to get "blockier" as they compress, VP3/Theora seems to get "blurrier" instead, which to my eye generally "looks nicer", despite the fact that it has lost as much actual information from the video as the "blockier" codecs (e.g. mpeg4). IF Xiph ever gets around to some file format documentation and VP3/Theora encoding support appears relatively soon, I can easily imagine Ogg Theora becoming a popular format for internet video and archiving home video.