Interlacing and Bitrate

[bugster]

In this thread it was suggested that, all other things being equal, an interlaced video requires more bitrate for the same quality when encoding to mpeg than a progressive source, assuming of course that source = destination with respect to interlace settings.
Can any one confirm or deny this as it is something I have not considered before and I am not yet convinced by the explanation given.

[SaSi]

I assume we discuss MPEG-2 compression. Please bear with me while I provide some "background".

MPEG-2 addresses interlaced video mainly with two "features".

First, it allows field encoding, i.e. each frame broken into the odd and even scan line fields.

Second, it offers two macroblock scanning sequences: the original, as used in MPEG-1 and a new one, invariably called "other" or "alternate" scanning order.

This other scanning order takes interlace into account. When encoding progressive video, i.e. compressing frames, the original scanning sequence must be used. When compressing interlaced video, then the other scanning sequence must be used.

This is not to say that you can't "ignore" this fact and encode with the "wrong" scanning order. The result is that the quantisation will be less efficient and thus, more bitrate will be required.

Of course, how efficient the compression of interlaced material is, depends solely on the algorithm used by the developers of each MPEG-2 encoder. Not all of them were made equal.

CCE offers the alternative scanning mode. Additionally, it offers a separate set of quantization matrices that are optimised for lower bitrates offering much better image quality compared with the standard MPEG-2 matrices (for low bitrates).

Mainconcept also allows the user to modify the scanning sequence, goes even further than CCE allowing precice control on I, B and P frames separatelly (the usefullness of which is questionable), but then fails badly (in strict German tradition) by totaly hiding these controls under a tree of options in Advanced Video Settings. I was unable to comprehend these settings before I studied the MPEG-2 video specification document.

Tmpgenc doesn't have an explicit selection in scanning order. I have no idea if the scannning order is automatically selected depending in the encode settings (interlaced vs. progressive) as - frankly speaking - it makes absolutely no sense to have to select interlace or progressive and then also select a series of "obvious" additional settings the encoder could select by itself.

Now that the background on interlaced compression and an overview of the three main encoders is presented, I think people can decide for themselves.

For what it's worth, in the past, I used to think that interlaced video required more bitrate (because it was more complex). I even de-interlaced video before encoding. But I didn't actually know the technicalities of encoding back then.

I now believe that it doesn't make a difference. Even if it does make some, several other parameters have a much higher effect in quality and bitrate.

[bugster]

So, if I understand you correctly what you are saying is that, for mpeg-2, done correctly, interlaced video does not require more bitrate than progressive. However, if the encoder, or the user, uses the wrong settings (scanning order) extra bitrate is used/required.

Does that about sum it up?

[SaSi]

IMHO, yes.

[FOO]

I think encoding 2 fields must take more bits than 1 frame.
Consider a film frame , 480 lines all from the same instant in time.
You make a field from this by taking every other line.
Adjacent lines in this new picture are not related to each other as
well as adjacent lines in the original. MPEG2 compression relies on
spatial redundancy. I suggest that is reduced in a field picture.

If 4 fields were made by taking every 4th line, for example,
it becomes obvious that those fields would have considerable
artificial vertical complexity,

[Gazorgan]

Now I'm curious. I smell a test encode coming up.

Intuitively interlaced or non-interlaced should produce the same results. Other than the overhead for 59.98 fileds per second versus 29.97 frames per second (very very small %), mathematically it shouldn't matter.

I have a few HDTV progressive test clips to play with. Will TMPGEnc do Prgressive MPEG2 encoding? It's never come up before for me :P

[SaSi]

I think encoding 2 fields must take more bits than 1 frame.
Consider a film frame , 480 lines all from the same instant in time.
You make a field from this by taking every other line.
Adjacent lines in this new picture are not related to each other as
well as adjacent lines in the original. MPEG2 compression relies on
spatial redundancy. I suggest that is reduced in a field picture.

If 4 fields were made by taking every 4th line, for example,
it becomes obvious that those fields would have considerable
artificial vertical complexity,

This is why the MPEG-2 committee introduced an alternative scanning pattern for field encoding.

For frame encoding, zig-zag is used. It first goes to the right then diagonally down-left, then right then diagonally up-right, and so on.

For field encoding, it goes down 3 pixels then up again to the the top and then - words cannot describe the complexity of the motion...

I cannot challenge the reasoning behind either scanning order (or any other compression algorithm used for that matter).

FOO,

I can understand the logic behind your reasoning about loosing spatial uniformity by skiping lines and encoding odd or even fields by themselves.

However, the main "engine" behind MPEG compression, is NOT spatial redundancy. It's temporal redundancy. Each macroblock "extracted" from a field or frame is searched in the next one and a motion vector tells the decoder where the previous macroblock has moved to (in any direction up to 16 pixels far). As the macroblock colour content will have changed a bit, the difference is encoded and the macroblock for the P or B frame is encoded as :
Take the previous macroblock, position it (e.g.) x pixels to the right and y pixels below, and apply the difference to the resulting image.

I agree with you that if the fields were composed of lines 4 or 10 rows apart, spatial redundancy would be non-existent - almost. But this is not the case.

In any case, the whole issue is theoretical. If the source is interlaced, then it has to be encoded in fields. One could de-interlace it, however if the source is DV footage and the camcorder takes 50 fields per second, then combining 2 fields would produce a comb effect. If the source is film, in which case each frame is "scanned" and split into two fields, then theroretically de-interlacing would produce a viewble result.

One thing one of us (with time) can do is the following:

take a portion of a DVD video with high quality and little motion.

De-interlace it with VirtualDUB.

Use constant quality encoding with Tmpgenc to encode first the interlaced clip and then the de-interlaced clip at the same settings.

Check the resulting file sizes.

[ronnylov]

The only software encoder I know is able to encode field based interlaced is Canopus Procoder, but standalone DVD players seems to have some problems playing this field based encodings from Procoder. So for best compability interlaced is encoded as frames but using the alternate scan order. But field based encoding may be more effecient.

The frames of frame based encoding will have interlace combing which is harder to compress than progressive frames. My experience is that interlaced encoding needs more bitrate for the same quality. But maybe this is caused by sharper and more noisy sources when encoding interlaced? DV cameras are often more noisy than DVD movies.