As Pi... to 100 Places
You might not have noticed that objective measurements have gone the way of NTC-7. I ain’t sure if that’s good or bad, but it surely does leave a big hole in equipment specs.
NTC-7 and RS-250 were pretty handy back in the days when you could measure a problem, call up the phone company, tell them what the problem was and have them fix it. Okay, so maybe they wouldn’t fix it, but at least you’d be in agreement on what the problem was.
If the frequency response was off, your pictures could be dull looking. If there was periodic low-frequency noise, you’d see bars rolling vertically through the picture. You could go through differential gain and phase and all the other parameters, and by the time you were done, you could have a danged-fine analog system.
With digital, as everyone knows, everything’s perfect all the time, except when it ain’t. The phone company might make an effort to deliver some agreed-on error rate, but telling them what the differential gain is ain’t going to help them identify why the bits aren’t getting through. And then there’s compression.
Whoa! Let me back off for a bit (or byte). I don’t want to leave you with the impression that information compression is something new to the digital era. It ain’t. The first NTSC standard used compression, and so did the second.
Methinks I’d better define information compression.
It’s more like sleeping-bag stuff-sack compression than like audio-level compression. With audio-level compression, you make a determination about how best to squeeze too much dynamic range into a narrower distribution, recording, or listening channel. Then you do it, and the audio is—except for some strange consumer expanders—compressed from then on.
Information compression is different. You squeeze information into a narrower distribution or recording channel, but you always expect it’s going to be decompressed before it gets seen or heard. If all goes well, there ain’t any difference at all between the original and the decompressed (lossless compression), or at least there’s no difference anyone can tell (perceptually lossless compression).
Now then, you might think that there ain’t any difference between lossless compression and perceptually lossless compression. If so, you’d be wrong, on account of people maybe not being the only thing decompressed signals hit. They could also hit an image compositor or another compressor, and those boxes might take a dimmer view of perceptually lossless compression than a person would.
Where was I? Oh, yeah, NTSC. So the first NTSC declared that what should have been 60 frames per second could be squeezed into 30 through the compression miracle of interlace. The second declared that what should have been three video channels (one for each color primary) could be squeezed into one through the compression miracle of subcarrier-frequency interleaving. There were more compression tricks—vestigial sideband, chroma filtering, etc.—but I’ll stick to those two to make my point.
Most of the time, interlace seems to work pretty well, but when there’s an electronically generated horizontal edge in just one scanning line, it twitters wildly, and when stuff rolls through the picture at an odd multiple of one line per frame, it loses half its resolution. Those are just a couple of “for instances.”
A COLORFUL MOIRÉ
Likewise, when a host wearing a striped shirt walks out on stage, those stripes erupt in a colorful moiré pattern that ain’t in the original, and nice sharp edges between saturated colors can go dotty. But most of the time, NTSC color works pretty well.
Now then, if your pictures ain’t got fine horizontal edges or problematic motion, interlace ain’t going to be much of a problem, and, if you ain’t got fine vertical detail or saturated colors, neither will the color subcarrier. Moral of the story—compression problems are usually related to program source material.
So now I’ll talk about bit-rate reduction, also known as digital information compression. Not counting Internet streaming and downloading, DV and MPEG-2 are in widest use today; the proprietary systems in Digital Betacam, HD D-5, and HDCAM are pretty significant in TV technology, and H.264, JPEG2000, and VC-1 are coming on strong.
BETTER THAN PERFECT?
“So, Mario, which one is best?”
I figured someone would ask me that. The only honest answer is, “No one knows.”
Look, an uncompressed digital signal could be considered to have a compression ratio of 1:1. Compressed signals will have higher ratios. But for most program material, there will be a compression ratio or data rate where the system is either lossless or at least perceptually lossless.
If it’s operating at a lossless ratio, it’s no different from uncompressed. If it’s no different from uncompressed, it’s perfect. If it’s perfect, how can anything be better? Moral of the story—at high-enough data rates (or low enough compression ratios), all compression systems are perfect.
“But, Mario, what about higher ratios or lower rates?”
I figured someone would ask me that, too. This time the only honest answer is, “It depends.”
It depends on what you want. At 1 Mbps, no compression system I’ve ever heard of is going to deliver flawless HD. Maybe one will deliver blocky pictures and another one soft pictures. Which one do you like better?
Maybe one seems to need a higher data rate but offers award-winning multigeneration performance, and another seems to need a lower data rate but falls apart after a few generations. Which one of those meets your needs better?
One might have a very nice failure mode. One might offer multiresolution decoding from a single bitstream. One might offer cheaper decoders, another cheaper encoders.
Maybe one ain’t best at any of those things, but draws the least power. That could be a big plus in a camcorder.
Long-GOP encoding improves compression efficiency but can make compressed-domain editing a pain. You pay your money, and you make your choice.
Think MPEG-2 is dying and we’ll have a single compression standard? How touching.
Thank you for signing up to TV Tech. You will receive a verification email shortly.
There was a problem. Please refresh the page and try again.