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."
Though it does require that you use a commercial mpeg2 encoder, possibly an outdated one which can probably only be acquired illegally at this point.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
DivX is still where it's at.
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.
" 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."
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.
Right click, save picture as.
View in your favorite slideshow program.
There is no sanctuary. There is no sanctuary. SHUT UP! There is no shut up. There is no shut up.
To avoid Slashdotting the poor server, a mirror is available here:
mirror.
|/usr/games/fortune
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.
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)
The DVD's of The Matrix and SPR are pretty well done, transfer wise.
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.
Fully standards compliant mpeg4. It's not going to look nearly as good as XviD or DivX5, but it will be "durable."
DV is compressed.
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
Quicktime is a container format (like AVI), not a codec.
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.
i would suggest ffdshow. i believe it is generally regarded as the least cpu-intensive MPEG4 decoder (depending of course on the configuration, of which it has lots!)
This is my Sig, this is my Gun. One is for Slashdot and one is for Fun.
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.
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.
mov is a container format, like avi.
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.
GPL Deconstructed
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
You don't need the XVID codec. XVID attempts to be Mpeg-4 compatible as does DIVX5. That being said You can decode XVID with the DIVX5 codec and vice versa. What you need is a simple FourCC changer to change the FourCC (the software "marker" which tells your computer what codec is being used and what to decode with).
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.
http://sourceforge.net/project/showfiles.php?group _id=53761
use the latest alpha version.
This is my Sig, this is my Gun. One is for Slashdot and one is for Fun.
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
Both XviD and DivX5 can be fully standards complaint mpeg4. They offer a few (very few, optional, generally experimental) features which are outside the standard, but for the most part, they *are* mpeg4. Some of the seemingly basic differences between XviD and DivX5 is that mpeg4 has a lot of features which are not mandatory for encoders, and (for the longest time at least) they implemented different sets of optional features. And while the XviD and DivX5 teams are both attempting to implement as many of the fancy features as possible, they haven't polished them all off yet.
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).
That's for decoding. ffmpeg as an encoder is designed for realtime compression and thus doesn't match the quality of the mpeg4 codecs that don't have to worry about how long they take.
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.
I use huffyuv to archive my videos, it's a quite simple lossless codec with the source code available. If it dies it shouldn't be too hard to write a own decoder to it after 10 years...
Only disadvantage is the size of the videos, it only compresses to about 40% of the uncompressed original.
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.
I am TheRaven on Soylent News
I've done a lot of Bink encoding (Bink is featured in one of the tutorials in my book).
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 downloaded from the web.
My video compression blog
Well, the MPEG-2 part 2 codecs (the one's you've seen so far) are really suped-up versions of the H.263 videoconferencing codecs. It uses a lot of the same concepts as MPEG-2, but tuned for better performance at lower data rates. The new AVC MPEG-4 codec (which is what the 2004 version of this article will likely be about) is way better than both, and not based on either. Lots of whacky new stuff like multiple reference frame (so you can predict parts of the current frame on a frame THREE back, for example. Very nice with muzzle flashes!).
My video compression blog
The QuickTime MPEG-4 encoder is actually pretty bad (single pass only, speed instead of quality tuned). Sorenson Squeeze, Envivio Encoding Station, and plenty of other tools can make a QuickTime-compatible MPEG-4 file without a hitch, and with much better compression efficiency.
My video compression blog
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).