[zigzag]

I'm thinking of buying a TV card, and in looking at the options was confronted with a bunch of acronyms and such about video formats and codecs and the like, but most of it is over my head. I use iMovie and understand that it uses the DV format and that it can export to QuickTime and then be compressed for Web use, and that's about the extent of my knowledge.

Can anyone recommend a resource that explains these things in plain English? The different formats, the different codecs, how they interact, why they work the way they do, and their relative merits? I'd really like to make sense of it all, but the resources I've looked at always seem to assume prior knowledge.

Thanks much in advance.

[bmedina]

I can't think of any links off the top of my head, but if you ask questions, I'll do my best to answer.

[zigzag]

Originally posted by bmedina:
I can't think of any links off the top of my head, but if you ask questions, I'll do my best to answer.

Thank you, I very much appreciate it. However, I'm afraid I need a general education, which wouldn't be feasible here. I've been searching the Web, and there are some write-ups on video formats and compression technologies here-and-there, but they tend to be incomplete and out-of-date. However, if I piece them together I should be able to get a handle on things so I can can discuss them intelligently and ask better questions as they come up.

Failing that, I'll look for a book, although the ones I've seen so far aren't quite what I'm looking for.

Thanks again!

[Uncle Skeleton]

Originally posted by zigzag:
I need a general education, which wouldn't be feasible here. there are some write-ups on video formats and compression technologies here-and-there, but they tend to be incomplete and out-of-date.

Cutting edge video compression is constantly changing as new improvements are developed. So nobody is going to sit down and write an in-depth analysis that will be out of date in a month. If you want up to date information this is really the best medium to learn it.

To get the ball rolling, there are 3 basic aspects of a codec you want to look at. Compression, Compatibility and Ease of Use.

Compatibility is the easiest so I'll start there. MPEG-1 is really the only option that plays everywhere. Second best is 3ivx or Apple's codec because both play in a standard QT6 install. DivX in avi is worth mentioning only because there exist set top players that play them. It's also worth knowing things like 3ivx are compliant with MPEG-4 specifications so any compliant decoder can decode them, and things like divx and xvid enjoy exploring cutting edge buzzword-intensive features that sometimes increase compression and often reduce compatibility and increase playback requirements (hardware speed).

As for Compression performance, image quality is by its nature highly subjective, so you really have to try each codec and see for yourself how you like it. It's not a waste of time, everyone does it and it's probably even going to be the best thing to teach you how things work. As a rough guide, the top tier for compression performance include 3ivx, divx, xvid, WMV9, RM10 and any mpeg4 codec besides Apple's. Middle tier includes Sorenson, Apple's MPEG-4 and Indeo (don't ask). Low tier is things like MPEG-1 and MPEG-2. Everything else (unless I've forgotten something) is an editing format (DV, Animation, {M,J}PEG, Component, those kind of things). editing formats have good decoding speeds and bad compression ratios. It's also important to remember that everyone who knows enough to answer questions in this industry is biased towards one product or another. This makes it even more important to try everything out for your own edification.

Ease of use include things like compatibility with QT (for encoding and decoding), encoding speed, price (encoding and decoding), things like that. For me, 3ivx is the clear winner here. MPEG encoding options are abysmal. AVI decoding is as well. You can put DivX and XviD in mov as well, but they are slower (to decode) than 3ivx, and to use them at decent compression they need to use advanced features that prevent (for example) the standard QT6 decoder from decoding them (unlike 3ivx). WMP and Real are obviously unusable in OS X (see? biased).

Lastly, when you do your tests you'll want to know some basic pointers for all codecs. For example, always keep your dimensions to even multiples of 8, 16 if possible. If your source has black or muddy borders, crop them off before encoding. If you don't know what Interlacing is, find out and always deinterlace before encoding (if your material is interlaced). QT's deinterlacing function doesn't seem to do anything in my experience. If your encoding app doesn't have its own deinterlacer, try JES deinterlacer. Also be aware that 2-pass algorithms sound cool but their only purpose is to hit an exact bitrate; don't give them undue importance.

[stevesnj]

http://www.videohelp.com/

[zigzag]

Thanks very much, folks. Much of the terminology is still over my head but I'm absorbing as much as I can. Thanks again.

[Uncle Skeleton]

Originally posted by zigzag:
Much of the terminology is still over my head

well ask then. you're probably not the only one. but I don't know what terminology you're talking about until you ask.

[zigzag]

Originally posted by Uncle Skeleton:
well ask then. you're probably not the only one. but I don't know what terminology you're talking about until you ask.

Thanks, Uncle. Part of the problem is not even knowing where to start. I had to read your post about 5 times before it started to sink in, not because it isn't an informative post, but because it's like learning a foreign language. I'm still trying to sort out what the basic terms mean and how they relate to each other. For example, you seem to refer to MPEG-4 as a codec in and of itself, but you also refer to "any MPEG-4 codec," which suggests that MPEG-4 comes in different flavors, and I feel like a dunce for not understanding what seems to be common knowledge for everyone else. That's why I need a reference that assumes no prior knowledge - I still need to figure out what all of these things are and how they fit together. It would be swell if I could find a table or flow chart that sorted it all out and defined the terms.

Your post did lead me to this glossary, which I've been studying and has helped: http://www.3ivx.com/support/video_glossary.html

So, if you're prepared to provide a from-the-ground-up tutorial, by all means do so, but I would never expect you to. Either way, I very much appreciate your help.

[Uncle Skeleton]

Ah yes, good question. First, the MPEG (Motion Picture Experts Group) group is a consortium of companies with an interest in defining video standards. I don't know what qualifies a company to be in the group. Anyway, they get together and (after a long time) produce a document that specifies what constitutes an MPEG file. This document I'll call "the spec." You may know of their previous inventions: MPEG-1, MPEG-2, and MPEG-1 Layer 3 (mp3); now they have MPEG-4. The thing is, the spec is just the rules of what qualifies as an MPEG file, not any code on how to produce such a file or how to decode it. To try to simplify the situation, if it were the Odd group, the document might say "in order to be qualified as an Odd number, it must not be evenly divisible by 2". Then it's up to the software developers to come up with some code that produces a file that fits that specification.

Well the confusing part is that the spec describes parameters for both a codec and a file format, and each of them (plus the spec itself) is referred to as "MPEG-4." So you have to keep that in mind and take the term in context. Technically, only the file format should be called "mp4," so if you see that it's a clue that it means the file format, but that won't stop people from using it incorrectly either. So to recap, you could say "the MPEG-4 spec" and mean the document that describes what qualifies as an MPEG-4 file. Or you could say "an MPEG-4 codec" and mean any of a number of implementations of things that conform to that document. Or you could say "an MPEG-4 file" and mean a file that meets the conditions of the file format portion of that document.

So. Chances are you don't know the difference between a codec and a file format either. A file format describes things like where in the actual file you put things like headers and sync information, and where you put the actual media data (audio, video, text, etc). Here and here are some examples of pictures (from other formats) that describe the ways a file format might be layed out. The codec describes how you actually compress the data and then how to decompress it (CoDec = COmpressor/DECompressor). The data the codec produces (that will be stored in the file) is often called the bitstream. If we return to our Odd analogy, the Odd file format might be "All Odd files start with '1', then the number that meets the Odd spec." Then you might have a file that looks like this: 13457, and using the spec for the file format you would know that '1' is the header and '3457' is the bitstream. For the codec part, the spec might say "the bitstream will have the digits of the original number in reverse order" (this would be a very stupid spec). Then you'd take your '3457' found in the file and write some code to 'decode' it into '7543' which would be your raw video frame again.

An interesting side note about quality. Obviously different implementations of the spec for the encoder will have different levels of success for compressing the data. What you might not realize is that different file formats are also more compressed than others (for the most part you can mix and match codecs with formats, so you can store content compressed with mpeg-4 codecs in an avi, mov or ogm file format). For example, AVI as a file format specifies a certain (unbelievably large) quantity of "junk" data. This junk data has been hacked to store subtitles I believe (as in, your software puts the subs in there, everyone else ignores it because it's junk data, but your software can retrieve the subs when it's time to play back the file). Anyway, so if you just open any old avi file and transfer the movie data to a mov file (the QuickTime file format is called mov, and confusingly enough QuickTime is also an application "QuickTime Player" and a programming API), your file will become roughly 1% smaller in the mov form than the avi form, with exactly the same encoded data in it.

Lastly, the difference between MPEG-4 codecs. Just like mp3, mpeg-4 specifies conditions under which a file would be compliant with the spec, but it doesn't specify how you might create such a file. There have been a number of different algorithms that encode a file to meet the mp3 spec (you might have hear of them, Xing is very fast and used in a lot of Windows encoders, but not very high quality. LAME is very slow and high quality and used in most open-source apps. Fraunhofer is about in the middle and is what iTunes uses). Likewise there are a number of different algorithms used to compress video to meet the spec for MPEG-4. 3ivx, DivX, XviD and Apple's "MPEG-4" codec (the quotes indicate that that's all they call it, not that it's not really MPEG-4) are all MPEG-4 codecs, which means they create bitstreams that comply with the MPEG-4 spec. This means that their output is all interchangeable...almost. It turns out that there are different degrees of the spec. Apple's codec conforms to something called "Simple Profile" mpeg-4. Divx and Xvid conform to "Advanced Simple Profile" and 3ivx conforms to "Simple Profile" unless you enable one specific option and then it's "Advanced Simple Profile." Also, video coding is complicated, and Divx and Xvid produce a number of bugs that have to be specifically recognized and worked around. 3ivx complies closest to the spec, and it even has code in its decoder to recognize the bugs from the other 2 and work around them. When encoding with 3ivx (if you don't use the one feature, "MPEG Quantizer," that makes it be Advanced Simple Profile), the bitstream can be decoded by any other codec, including Apple's, without modification.

Simple enough eh?

[zigzag]

Thanks so much - that's exactly the sort of "assume nothing" instruction I've been looking for. You even anticipated another question I was struggling with: Why QT is variously referred to as an app, a file format, a compressor, the basis for MPEG-4, etc.

Oddly enough, I've used both QT Pro and Cleaner to compress DV for the Web, but it was mostly guesswork - I'd pretty much just hit a button and hope things came out OK. I'm trying to develop a better understanding of the technology. I've found some sporadic guidance on the Web but yours is the most helpful so far.

My immediate motivation for learning this stuff is to choose a TV/DVR card - I'm trying to sort out the relative merits of M-JPEG, MPEG-2 and MPEG-4 and how they interact with iMovie, iDVD, Toast, QT, etc. It can be very confusing - you might have seen my post in the Peripherals forum.

Many thanks - I'll pose further questions after I've had time to digest it all. I hope others find it helpful as well.

[Uncle Skeleton]

Originally posted by zigzag:
Why QT is variously referred to as an app, a file format, a compressor, the basis for MPEG-4, etc.

it's actually not a compressor

I'm trying to sort out the relative merits of M-JPEG, MPEG-2 and MPEG-4

MJPEG is the best quality and MPEG-4 is the smallest file size. MPEG-2 has two advantages; one is that it's (usually) compatible with DVDs, so you don't have to re-encode (this is a HUGE advantage if you intend to use this card and burn DVDs more than for a one-time project); two is that (most) devices that capture to MPEG-2 do the encoding in hardware, so you're not dependent on your CPU while capturing. MPEG-2 also has a great compromise between compression and quality.

If you have cable TV I would also look into asking your provider for an HDTV cable box with firewire output (which they are legally obligated to provide). This probably won't have a good DVR solution included, but it has the distinct advantage that it's only $7 a month, and provides perfect quality HDTV captures. (this is also in the MPEG-2 camp)

[zigzag]

Originally posted by Uncle Skeleton:
MJPEG is the best quality and MPEG-4 is the smallest file size. MPEG-2 has two advantages; one is that it's (usually) compatible with DVDs, so you don't have to re-encode (this is a HUGE advantage if you intend to use this card and burn DVDs more than for a one-time project); two is that (most) devices that capture to MPEG-2 do the encoding in hardware, so you're not dependent on your CPU while capturing. MPEG-2 also has a great compromise between compression and quality.

If you have cable TV I would also look into asking your provider for an HDTV cable box with firewire output (which they are legally obligated to provide). This probably won't have a good DVR solution included, but it has the distinct advantage that it's only $7 a month, and provides perfect quality HDTV captures. (this is also in the MPEG-2 camp)

I managed to grasp the different formats(?) pretty easily, but I'm still trying to sort out how they all interact with Quicktime and iMovie. The various TV cards record to either MJPEG, MPEG-2 or MPEG-4. I mostly want to know which one(s) will allow me to make simple edits in QT Pro or iMovie without requiring lengthy conversions (it would be nice to understand the whys and wherefores as well). DVD functionality would be secondary.

Thanks for the FW cable modem tip - I'll look into it.

[Uncle Skeleton]

QT works with everything except MPEG-1 and MPEG-2. iMovie only works with DV. I would avoid iMovie unless you need to add effects (text, transitions, etc). It's designed for home videos, and for everything else it's really not suitable.

Here's what I've decided after years of capturing TV. If you can, capture in MPEG-2; then you have the option to go to DVD, or to compress using any of the DVD ripping apps that have developed over the years. If you can't capture in MPEG-2, capture in DV. The quality/size compromise is good and it's fast to encode and decode. You can convert MPEG 1 or 2 to DV, and edit them without recompressing, with MPEG StreamClip. If you're going to be going to DVD in the end, you really really want to avoid converting to something besides MPEG-2, because it takes a looong time, and it will reduce quality, twice. This is another reason to look at MPEG StreamClip, it lets you cut out commercials from MPEG-2 source without having to re-encode everything just to do the simplest edit and re-encode back to MPEG.

[bmedina]

If you want to make edits to your shows, avoid capturing in MPEG of any flavor. They are made for distribution and archiving, not for editing.

Try either MJPEG or Pixlet (i.e. something without interframe dependencies) for the capture. Do your edits, then compress to MPEG at the final stage.

If all you're doing is simple edits (like cutting out commercials), and you're happy with the quality of your signal, MPEG2 and Streamclip is reasonable.

[zigzag]

Originally posted by bmedina:
If you want to make edits to your shows, avoid capturing in MPEG of any flavor. They are made for distribution and archiving, not for editing.

Try either MJPEG or Pixlet (i.e. something without interframe dependencies) for the capture. Do your edits, then compress to MPEG at the final stage.

If all you're doing is simple edits (like cutting out commercials), and you're happy with the quality of your signal, MPEG2 and Streamclip is reasonable.

The logic of it is starting to sink in: MJPEG lends itself to editing because it only uses intraframe compression; MPEG doesn't lend itself as well to editing because it uses interframe compression, and is therefore more suitable for distribution and archiving than editing.

Thanks - that helps me understand more of the whys and the wherefores. You guys are great.