[geeks] Whee! Lightning strikes, AGAIN!

[Joshua Boyd]

On Wed, Jul 29, 2009 at 05:53:26PM +0300, gsm at mendelson.com wrote:
> On Wed, Jul 29, 2009 at 10:22:17AM -0400, Joshua Boyd wrote:
>
>> Not quite.  The chroma sampling is often reduced, so while each pixel
>> has its own luma sample, adjacent pixels may share chroma samples.
>> 4:2:2, which is NTSC, uses half the chroma samples.  4:1:1 and 4:2:0 use
>> 1/4th the chroma samples.
>
> Also, MPEG encoding is based upon the key-frame concept. A key frame is
> fully encoded. The next frames until it is time for a new key frame,
> only encodes the difference. A really smart encoder would be able to
> determine that the difference is so great that it should abandon the
> last key frame and start a new key frame. I don't know if they exist
> or how they do it. 

I'm not sure what this has to do with why YUV potentially requires less
bandwidth than RGB.

Also, I feel like you skip massive important details like motion
compensation and macroblock compression.

That said, a really smart encode is still limited by how stupid many
decoders are, and as such, a fixed pattern of I frames (key frames) and
non I frames is often required (called a group of pictures, GOP).

Also, I believe that non I frames are always smaller than I frames.  It
isn't just about which frame is smaller, there are also quality
considerations, since the size of either frame is adjustable by either
adjusting the number of macroblocks included in the P or B frame, or by
adjusting the results of the DCT (zeroing the higher frequency
coefficients, which will then fall out in a later encoding step) in any
type of frame.  

Certainly you can do better with extra smarts like you suggest, and
MPEG2 allows that, but in the real world if you take that very far you
get video that only be played back by a limited subset of PC based
decoders.  

> The easiest way would be to encode it twice and compare the output
> size. This would really slow down compression but signifcantly reduce
> output size. It may be an option on some encoders. It would not be
> worth it, IMHO for on the fly video recording, but it would be worth
> it for professional production. 

If by professional production you mean disc encoding, then sure.  Most
professional usage of MPEG2 in production is on the fly encoding.
HD-SDI goes into disk recorders that compress to MPEG2.  The playback
servers read the MPEG2 and output HD-SDI again.  This goes through
several stages before it hits the transmission stage where it is
recompressed to MPEG2 and then that is encoded for DVB or ATSC.  Then,
again it is decompressed, either for your TV, or it is again
recompressed for cable or satalite (where it may or may not be MPEG2
this time, and quite possibly is being compressed at a lower bit rate
than it was from the network).

I only point this out to say that professional production can be really
gross, and obviously top quality isn't always required.

> Once the data is encoded, compression is applied. MPEG-1 was designed

Since several of the steps along the way to this point are throwing away
data, I would argue that data is already being compressed.  

> MPEG-4 included an advanced audio codec (usually called AAC, not MP4 audio)
> which is able to produce the same quality as an MP3 stream of twice the
> bitrate. 
> Outside of video encoding, it has been used by the iTunes store.

AAC was actually introduced in MPEG2 Part 7.

Both MPEG2 and MPEG4 have been extended to carry numerous audio types
other than just MP3 or AAC.  Also extensively used are AC3, AC3+, DTS,
and Dolby E.