Slashdot Mirror
In-Depth Look At Video Codecs
johnsee writes "Atomicmpc has an incredibly in- depth look at a wide range of video codecs. It looks not only at their inner workings, but also shows the quality produced by each at a variety of settings and situations."
Apparently some people have no sense of humor. BTW I am back.
For those not wanting to read the article:
Rated best to worst with default settings
Low Bitrate go with XVID, DIVX, h.264, WMV
Medium: XVID or h.264 depending on lighting and motion, WMV, DIVX
High: h.264, WMV, XVID, DIVX
Get a web developer
http://digg.com/apple/DivX_Pro_Mac_Free_on_June_7
Grab it while you can.
There are a number of comparisons around the internet, and the last ones from 2006 show that x264 and Mainconcept are basically tied as the best, with Mainconcept having a tiny lead. However, x264 now has Adaptive Quantization available, an experimental feature that can help eliminate blocking in dark scenes which is pretty much impossible to avoid without AQ unless you use absurdly high bitrates. This feature alone puts it way over the top, IMO.
--aq-strength for the win!
Do you mean: "Which H.264 encoder works the best?"? Or are you talking about the different profiles and features within the codec?
I believe that there is only one H.264 (but you might correct me) however different encoders and decoders have been created for it. All decoders should be equivalent (although some might choose to add some post processing) but the developer can vary the encoding method as long as the output still meets the standard.
I recognize their are similarities, but I do not believe they are the 'exact same'. My evidence is that the video cards we use have Mpeg4 hardware encoders, yet will not 'hardware decode' the H.263 stream.
also, FTFA's reference: Bold emphasis mine.
Can any video experts comment? Can you provide me with a reference or some more information that would stand up in court? (not that it will get to that)
This is not "everything you wanted to know about codecs." In fact, 3ivx just released 3ivx 5.0 for encoding to MPEG4 a few days ago.
A bit of a bummer that an Australian website missed reviewing an Australian created codec.
FYI, here's the press release. And YES! It does do Linux!. Tux be praised.
http://www.3ivx.com/pr/pr20070607_50.html
Cheers
- Zav - Imagine a Beowulf cluster of insensitive clods...
And so you should describe it as "dividing numbers by two and then multiplying them again"...? In other words, a "simple" description is preferable, despite the fact that it's completely wrong...? Hell, "dividing numbers by two" isn't even an accurate description of quantization, let alone of a DCT.
e s/viewarticle.jsp?id=109739-2
I think I made a pretty decent job of explaining what "frequency space" is, and why it can be used to improve compression, here:
http://digitalproducer.digitalmedianet.com/articl
(scroll down to "The transformers")
It also explains why DCT isn't a form of compression per se, it simply makes it possible to use quantization in a way that does not affect quality as much as it would in "pixel space".
Several "non-techies" have read that and, although they realised the transform itself is not something trivial, they understood what it did and what it was used for. Something that you can't really say about the Atomic article (or its author).
ie the following statement is always true:
H.263 is always MPEG4
However the the folloing statement is not always true:
MPEG4 is always h.263
Not true at all. There are some hardware MPEG4 encoders on the market, but it is for the most part, not included in modern GPUs. For decoding purposes, portions of the h.263 (IDCT to be exact) has been implemented in hardware on video cards for quite sometime. However, combined with programmable shaders, a good deal of h.263 decoding can be greatly accelerated by most modern GPUs (nVidia's PureVideo DirectShow codec is an example of this). ATI's AVIVO XCode app does use a great deal of shaders to speed up the encoding process for several codecs. Even though it's been shoehorned to work with other GPUs, it was intended to work thier X1X00 line of video cards.
Havoc Video
I'd like to point out that 1680x1050 is huge.
[Ahem] The new standard is 1920x1080. Cope.
Can we get a "-1 Wrong" moderation option?
"Print" does not mean stipping out all graphics and ads, but leaving the number of pages the same.
>:(
--Rob
Towards the Singularity.
Are you aware that VC-1 in the SMPTE spec for VC-1? So both codecs have fully publshed specifications, and reference source code for both encoding and decoding.
All the info about algorithms in the video codecs is fully public. The same body, MPEG-4 LA, handles licensing for both technologies, and handling patent issues around them.
Going back to the paleolithic era, Microsoft made the original reference encoder for MPEG-4 (hence the venerable MPEG-4v3 codec). Windows Media Video 7 and later were about going beyond what MPEG-4 was capable of, since we and everyone else started hitting our heads against its architectural limitations. Microsoft was also quite involoved in H.264 as well, including a Microsoft employee who chaired the committe that developed the standard.
That said, we find VC-1 is a better codec for many uses. H.264 was really designed more for an ASIC environment, and uses computationally and bandwidth intensive techniques like CABAC and a really strong loop filter that make it much more expensive for PC playback (in CPU requirements and battery life in a laptop) than a VC-1 encode of equivalent quality and bitrate. Also, VC-1's simpler loop filter design makes it easier for us to preserve textures like film grain at lower bitrates. This lower horsepower needed for decode makes it possible for us to do stuff like software-only decode of HD content inside the Silverlight brower plugin, where we have no access to hardware acceleration.
My video compression blog
The Slashdotting finally eased up enough for me to finally get to Page 4. Earlier complaints about the complete absence of accurate facts in the technical part were dead-on. But in the proceudre, wow, it's hard to know what relevant of the test would be.
40 FRAME clips? The default GOP length of most of these codecs is longer than that! There's no useful test of rate control in there, or keyframe supression popping.
And as far as compression setings, all they say is "we used the defaults, but set it to highest quality". There isn't just ONE defualt in these products. We don't know if they're even comparing CBR and VBR, 1-pass or 2-pass. And there are lots of tweaks appropriate to different kinds of content that would be used in practic - one doesn't compress film source like cel animation!
Sheesh, there's really no useful information here at all. The average reader would probably wind up knowing less about compression after reading it...
My video compression blog
Exactly. I'll copy/paste my response to this highly innacurate article on Digg:
... What? The DCT is a complex algorithm that converts an array or matrix of values into frequency space, producing a set of frequency coefficients that represent respective values of cosine waves at different frequencies along the set. Halving the data has nothing to do with it unless you're using a quantizer of two and a quantization matrix of all ones (or a QM of all twos and a quantizer of one...).
"Some other major inaccuracies:
This site says that motion compensation was introduced in MPEG-4. What? Motion compensation and motion estimation are at the core of every MPEG and most other codecs.
Also, his understanding of the DCT is way off (and no, you don't need a degree to understand it -- I was building JPEG encoders in 11th grade).
"During an encode, every number in a series is simply halved and the remainders thrown away."
This is also wrong:
"Think of a quantisation matrix as a palette of values that controls how the pixels in a macroblock are converted from pixels to a formula."
That's the DCT that he's describing. The quantization matrix simply defines what values the frequency coefficients are divided by. I think he has quantization and the DCT mentally swapped.
Oh also, he acts like QPel and GMC are Xvid inventions. In actuality, most MPEG-4 codecs implement these. Granted, DivX's GMC is inferior to Xvid's implementation (one warp point vs three), but it certainly does have it."
Of course, this got dugg down to hell because my comments about the DCT were mistaken for boasting. Hopefully the same won't happen here.
Almost right, but the "Part"s are descriptive standards or references, not implementations. H.264 is not "MPEG-4 Part 10" - Part 10 describes a standard which is technically the same as H.264, but does not provide an implementation (beyond pointing at the ITU-T's H.264). It's a subtle difference, but important, and Wikipedia is not always clear on this.
It's a bit like reverse-engineering in a cleanroom environment - the various MPEG-4 parts describe exactly how things should work, then you'd pass it off to the developers to re-implement without being tainted by the original. The only real difference between MPEG-4 and what the PC BIOS cloners did (and the wireless / video firmware hackers in Linux / BSD development are doing) is that the MPEG-4 references themselves are covered by copyright and patent law. You can't take the specs and use them to produce an implementation, because that runs afoul of their licencing provisions. You could take an implementation, reverse-engineer it, and produce descriptive specs - but you'd want to be damned sure the descriptive specs you produced didn't look even remotely like the MPEG-4 group's specs...
FWIW, Part 7 is set aside for optimisations to the reference examples given in Part 5 (and I think Parts 2 & 3).
What part of "a well regulated militia" do you not understand?