Slashdot Mirror
Video Codec Comparison
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."
In conclusion: When encoding regular movies, if you look for a quick and dirty average solution DivX5 is your fix. If you're an SBC guru, want maximal details at high speed you can still stick to SBC, if you want details and are not worried about the alpha status and speed you should give XviD a shot. DivX5 and XviD also offer standalone playback capability on selected devices. If you don't worry about details too much and prefer to remain almost blockfree you should give RV9 a shot, or alternatively WMV9. Interestingly, the lead developer of XviD has offered to send me a build that would perform just like RV9.. I might take up that offer one day when I'm bored.
For animated features, the two proprietary solutions deliver good results with XviD pulling slightly ahead.
test 1: The Matrix
test 2: Saving Private Ryan
test 3: Futurama
Heh, the pinnacle of humankind's moving image creations
" I haven't really gotten mpeg4 to look as well as mpeg2 even with the lowest compression setting. I'm not sure if mpeg4 was simply designed for streaming or whatnot. "
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.
"Derp de derp."
Comment removed based on user account deletion
Along a few of the pictures he says along the lines of "jpeg helped this codec. In this one it hurt this codec.." Granted he probably wanted to save bandwidth but why couldnt he post zipped up uncompressed files to download? Also, I think a single image with side by side comparisons of parts of each scene would be nice as I cant flip back and forth between all the pictures and remember what I liked and disliked about them all.
You can use the exact same compression matrices and quants from Mpeg-2 with Mpeg-4. Both support interlaced and progressive video (although you may have a harder time finding a reliable field-based format for Mpeg-4) and both support HD resolutions. The main difference between the two, is that Mpeg-4 video is part of a much larger specification designed to deal with not only video, but content delivery mechanisms (i.e. interactive things). If the specs could have been finalized quicker, it would have been a Flash killer.
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.
To avoid Slashdotting the poor server, a mirror is available here:
mirror.
|/usr/games/fortune
there is lots of things left out like bitrate/quality comparisons, some codecs, like realvideo do a much better job at low bitrates (200k/s) then say xvid at the same bitrate.
Real easy answer, the distortion is part of what mp3 just throws away, it's actually quite a lossy codec in some areas.
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.
For my fellow ADD'ers
Yes, this comparison of video codecs is quite HEY LOOK A GUY ON A BICYCLE!
there are a lot of common codecs left out of here, for example Sorenson. (yeah yeah, can't view on Linux, but it's popular and quite good)
I keep hearing good things about Bink. Anyone have any experience with it, one way or the other? Seems to be used in a lot of games.
A signals-processing attempt to measure audio quality isn't useful in general, and especially when dealing with lossy codecs. The various measured distortion values aren't really interesting -- the only relevant result is audio quality. As such, the only interesting tests are blind listening tests.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Well, if you have read the article, you can see that 3ivx (not 3ivX as the article states :) ) does not fare well. However, 3ivx does have one thing that the others do not have whatsoever... it was built from scratch for QuickTime compatability. The reason that this is a good thing is the versatility you can achieve with a QuickTime movie. I have personally ripped and encoded an anime movie, and was able to put both English and Japanese, as well as English subtitles, all controlled by a flash menu. The few OGMs I have seen have similar capabilites, but nothing quite as nice as QuickTime.
The video quality is actually pretty damn good, IMO. I suggest trying it out for yourself. Check my webpage for more relevant information.
I wish they tested that too, the encoder isn't free, but it is cheap. Then the question is, is the price worth it?
GPL Deconstructed
If you wanted to make video files that will have the best chance of being viewable in 10 or 20 years, what are the best file formats and codecs?
Are any file formats and codecs likely to be visible?
All these years and MPEG1 is still the only truly universal video format.
.mov or .avi you downloaded requires a codec you don't have.
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.
libavcodec is actually just as good as divx5, and certainly better than xvid. While it's true that it produces stuff that's compatible with divx decoders (theoretically all MPEG4s should be compatible with each other, but that's only the theory), it is certainly not subsumed by divx5. It also has many of the codec features of divx5 pro - e.g. B-frames, Trellis quantizer (which improves quality / reduces bitrate big time(tm))
The Raven
It seems that everyone is worried about encoding and what I would like to know is which format takes the least cpu to decode. I'm running on a rather weak laptop and even mpg1 gives me mismatched audio. Are the mpg4/SBC decoders less cpu intensive?
A better translation of "Maximum Quantizer" would be "what's the most information you should throw away". The lossy compression formats get a lot of their effectiveness by quantizing the data. Specifically, a quantizer of n means divide everything by n and throw away the fractional part on compression, then multiply everything by n on decompression. From a practical standpoint, it is the same thing as throwing away the least signifigant bits (a q of 16 throws away 4 bits, for example).
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.
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.
This is my Sig, this is my Gun. One is for Slashdot and one is for Fun.
To be sure, he's comparing the performance of the codecs against content that is popular (and typically difficult to compress...)- but he's pulling it from a lossy format, namely the MPEG2 stream off of a DVD.
.OGG's or something like them instead of pulling them from MP3's as source. With a lossy format, you're deliberately losing content, introducing hopefully un-noticable distortions into the reproduction of the sound. Unfortunately, the varying formats use different assumptions, which produce differing kinds of distortions into the result. Because of this, re-encoding from MP3's, your sound files end up with distortions on top of distortions- the quality and compression suffers as a result.
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.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
I can explain quantizers.
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
lf(1): it's like ls(1) but sorts filenames by extension, tersely
MPEG is a very rich spec and leaves a LOT of room for encoders to find different and better algorithms. In fact you can almost think of an MPEG decoder as a virtual machine that executes a program to reconstruct the video. The encoder has a lot of freedom in choosing where to put I frames and how to find the motion vectors. (as opposed to say GZIP or JPEG, where there is pretty much only one way to encode things).
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.
Thought this was important such than a non-A/C should post it also:
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.
Article X: The powers not delegated... by the Constitution...are reserved...to the people
MPEG4 _was_ initially intended for very low bitrate applications. And indeed, if bitrate is not an issue, then MPEG2 can (and generally will) produce output that is indistinguishable from the source.
:)
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
IANAL but looking at the Helix binary EULA there seems to be a clause disallowing this sort of thing.
c kw rap/eula-clickwrap
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
Never mind that so far as video goes, getting totally uncompressed source is nearly impossible. 640 wide*480 high*24 bit*30 fps = 221Mbps. Yep, two-hundread and twenty-one million bits per second. That translates to under 30 seconds of video on a standard CD, or about 6 minutes on a DVD.
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 room) and animation (hours upon hours of Bryce). And at that, it turned out that in practice, we could have just ripped some DVD and gotten identical results.
You make a good point but it's not just DVDs that use compressed video. Digital cable, satellite, digital video cameras, etc. are all pretty common sources for people using these codecs and they're all compressed. Heck, most of the stuff I encode has been through compression/decompression twice allready, once by Directv (mpeg2)and once by my pvr (mjpeg) and when I want to store it long term I use mpeg4.
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.
See my journal, I write things there
since MPEG2 requires such a high bitrate for decent looking video to emerge, I can give you five times better quality (for same size video file) using DivX ;-) because Divx ;-) is many times more efficient. Also note that MPEG2 is quite limited, doesn't work nicely with high resolutions, etc.
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.
Doom9 could have used PNGs. Quite annoying that half of the screenshots were totally destroyed by using ANOTHER lossy compressor on them. Yes, I should be looking at the video clips and not the screen shots, but then why the hell provide them at all?
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, Xine, and MPlayer.) 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 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.
Hacker Public Radio is our Friend
I would gladly encode material from the digital master tapes but my chances of getting access to those are pretty slim :/
why provide them? because people demand them. Watch out for the next site update (due in roughly 2h).. I have made some improvements in the futurama comparison (no PGN.. that would increase the size too much, but the new shots are a lot nicer).