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!
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.
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.
Yes you can view ALL sorenson material on linux, try the latest STABLE version of mplayer or the latest beta10 of xine-lib.
I believe he meant the Quicktime MPEG-4 codec...which is specific only to quicktime (and is quite good IMHO)
I'm out of my mind right now, but feel free to leave a message.....
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.
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.
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
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).