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."
..any of the codecs the porn..i mean video sites i visit ask me to install before i get to see the videos..
this is just a placeholder till i send back my real sig from the future.
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
I've found the best way to highly compress movies on OS X is to use the ASCII Movie Player codec to display the video in Terminal.app, capture that to a text file using a pipe, and then zip it all up.
God, I've just read his description of DCT. It's even worse. He seems to think that DCT consists of "dividing numbers by two" (he doesn't even use the word "quantization", that probably has too many syllables). And people complain about Wikipedia...
e s/viewarticle.jsp?id=106309
e s/viewarticle.jsp?id=109739
e s/viewarticle.jsp?id=125089
Time to shamelessly plug my articles about compression. Some parts are simplified (they're aimed at "end users") but, compared to this Atomic article, anything is flawless:
Lossless (data, image, audio)
http://digitalproducer.digitalmedianet.com/articl
Lossy + Hybrid (image, audio)
http://digitalproducer.digitalmedianet.com/articl
Video (lossless, lossy)
http://digitalproducer.digitalmedianet.com/articl
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