Compressor's 25p and 25i mpeg-2

I have a 720x576 50p prores project and wish to make an SD DVD. 50p crunches nicely to either 25p or to 25i (which I prefer to call 50i, but use Apple's terminology here). In Compressor, when making the MPEG-2, in the second tab of Inspector, with SD DVD chosen for Stream Usage, Frame Rate 25, there are the progressive and interlaced options.

So Compressor believes that both 720x576 25p and 720x576 25i are supported formats for an SD DVD. The DVD Studio Pro 4 Help file disagrees. It shows 720x576 25i supported, but not 720x576 25p. The wikipedia article on DVD-Video repeats this.

Anyhow I made both MPEG-2 compressions: 720x576 25p and 720x576 25i from my 50p source file. I looked into the m2v files' binaries and verified that they are quite different. However, when I played the two files using either MPEG Streamclip or QuickTime they showed absolutely no differences. Both viewers allow single framing, and they revealed no differences even in high speed actions between the 25p and the 25i files.

Single-framing through quick actions in the 50p source showed that both the 25p and the 25i files, as played with MPEG Streamclip or QuickTime, were missing every other frame of the original. This is as expected for the 25p but not for the 25i. Did the 25i really get a field from each of the original frames? If there are 50 fields per second in the 25i file, do the players just skip half the fields? And if they do, and deinterlace (although deinterlace was turned off for QuickTime) then the 25i wouldn't look as detailed as the 25p.

The little utility "MediaInfo" says the 25p is 25p and the 25i is 25i. The little utility "GSpot" agrees and even says that the 25i has 50 fields/second. But half the frames of the 50p original are completely missing from the 25i. What did Compressor make?

Dennis Couzin
Berlin, Germany

Answer to question what Compressor made: The 25i MPEG-2 is indeed 25i but of a bogus kind. Compressor in effect reduced the 50p prores source to 25p, ignoring every other frame, and then split each of the 25p frames two fields. So the 25i MPEG-2 contains the same spatial information as the 25p MPEG-2, and a player could display them identically. The 25i MPEG-2 is bogus because it contains false temporal information.

I caused this silly thing by setting Field Dominance: Top First in the Video Format menu while leaving Frame Controls: Off. The greyed Frame Controls menu showed Output Fields: Same as source. With Frame Controls: On, and Output Fields: Top First, Compressor made a proper 25i MPEG-2, containing information from each frame of the 50p prores source.

Next to make DVDs from the three different MPEG-2 compressions -- 25p, bogus 25i, and 25i -- and see how they look with commercial players.

Dennis Couzin
Berlin, Germany

Yes. Same as source means that your incoming format is taken as a progressive image and your outgoing source is progressive, so it will drop every other frame.



www.strypesinpost.com

Great stuff. Thanks for this

Michael Horton
-------------------

strypes, the input format is progressive. The output format is interlaced according to the Field Dominance setting in the Video Format menu. Then there are two surprises. (1) With Frame Controls off, the greyed out settings in that menu are nevertheless operative. (2) Despite progressive input and interlaced output, Output Fields can still be set "Same as source".

It would make sense if the Frame Controls tab is understood as applied before the Encoder tab. Then the 50p is converted to 25p before it is interlaced (leading to what I called the bogus 25i). But the tabs aren't applied in that order since the Frame rate selection used by the Frame Controls tab comes from the Encoder tab.

Regardless of Apple's funny language and logic it is useful that the 50p has two different 25i conversions. When played with the Mac DVD Player, the DVD made from the "proper" 25i MPEG-2 shows extreme aliasing, while the DVD made fom the "bogus" 25i MPEG-2 is much smoother spatially. I can't see the difference between the latter DVD and one made from the 25p MPEG-2.

Dennis Couzin
Berlin, Germany

I made a little 50p test video to study interlacing. Each frame consists of alternating black and white video lines. Also the frames alternate between black at top and white at top. So a "proper" 25i conversion of this 50p will be all black or all white depending on whether the interlace is top first or bottom first. The test video can be downloaded here.

Dennis Couzin
Berlin, Germany

The Mac DVD player has a deinterlacer, and as computer displays go, they do not display interlacing (playing back alternating fields in 50 or 60 hz), so you need to be careful when monitoring in DVD player.

The order of how Compressor works is a little misleading, since the order of the processes is not clearly or easily understandable, but this is necessary to prevent conflicting double entry of processes.

From my understanding:

From a 50p source,
With encoder set to interlaced, and footage detected as progressive (this can be toggled by clicking on the clip instead of the setting and changing the "native field dominance" in inspector), and with frame controls set to "same as source", you will get what is essentially a psF image (there is no official psF format in SD, but this will essentially be a progressive image in an interlaced stream, thus psF).

With encoder set to progressive, with the footage detected as progressive, and frame controls set to same as source, you will get a progressive stream.

With encoder set to interlaced, with footage detected as progressive, and frame controls set to upper or lower field first, you will get an interlaced stream.

However, if encoder setting is set to progressive and frame controls is set to interlaced, the output would be flagged or even encoded as an interlaced image, which would not be an issue in most cases since analog systems in SD are usually interlaced, but it may result in combing on a playback system that actively reads the flags and deinterlaces only progressive streams.



www.strypesinpost.com

It may seem like the processes are not done in order, but it is probably done that way to minimize processing hits in cases where conflicting double entry is defined by the user. Codec compression can only kick in at the end of the image processing pipeline, not before. This is what I believe is the image processing pipeline in Compressor in order:

-Footage decoded to uncompressed at full frame rate.

- processes from the frame controls tab is applied. The input source type (progressive or interlaced source) is derived from "native field dominance" settings of input clip. If "same as source" is set in frame controls, it will assume the variable defined in "native field dominance" of input clip, dropping every other frame of the source image to make a 25fps progressive stream (output fps derived from frame rate setting in codec settings). If source clip is set to progressive, and frame controls is set to bottom first, the fields will be taken from alternate frames, creating an interlaced stream. And so on.

- footage is then compressed to user defined codec, with appropriate flags (variables such as PAR may be derived from the geometry tab) and compression schemes.

This essentially rules out conflicting double entries by the user. Eg. Setting an interlaced format for codec and setting progressive in frame controls, which will decode the stream and pull fields from alternate frames (based on setting in codec setting), before going on to the frame controls tab and deinterlacing that image. This may result in artifacts caused by the interpolation in the deinterlacing algorithm, that is next to giving it an unnecessary processing hit.

(If input clip is defined as interlaced, I'm wondering if the clip will be treated as 100hz.)



www.strypesinpost.com

strypes, it's hard work reconstructing the logic in this do-it-all program.

The encoder pane offers a "Video Format" tab with a "Field Dominance" choice only for the MPEG-2 file format. For each other file format it behaves differently. For the QuickTime Movie format, field dominance may or may not be selectable within the Video Settings window. With ProRes compression it is entered after checking Interlaced. With Uncompressed it is not selectable.

This might be due to a deep difference between how ProRes and Uncompressed handle interlaced video. ProRes probably does its compression on each field separately and also stores each compressed field separately. Uncompressed stores two consecutive fields together in the same form as it stores a progressive frame.

When interlacing with Uncompressed 50p in Compressor, the frame rate will be set at 25 in the Video Settings window and Output fields will be set either Top First or Bottom First in the
Frame Controls window. This yields nearly the proper 25i interlace. I discovered that when the 50p has an even number of frames, Compressor ignores the penultimate frame of the 50p and makes the last two fields from just its last frame. Bad Apple!

Compressor makes the same error when the frame rate is set to 25 in the Video Settings window and Output fields is set to Progressive in the Frame Controls window. It makes a 25p by discarding the 2nd, 4th, etc. frames. But when it comes to the last frame to keep, which is the penultimate frame of the even length 50p, it takes the last frame instead. In fact if you want Compressor to make a clean 25p the trick is to turn Frame Controls off.

I think Compressor is too much cobbled together, and too sloppy, to have a logical structure.

Dennis Couzin
Berlin, Germany

Compressor is not too elegant with end frames. There was once when you'll get a white flash. On optical flow, the last frame may be a static frame.

>I think Compressor is too much cobbled together, and too sloppy, to have a logical structure.

Agreed. As much as I like it for it's overall quality and versatility, i find the software can do with a ground up rewrite as it has gotten too bloated over the years- droplets crash fairly often when you have a large amount of footage to transcode, and it's use of multiple processors can be further improved.



www.strypesinpost.com

>ProRes probably does its compression on each field separately and also stores each compressed
>field separately.

Yep. DCT compression on interlaced formats is less efficient. If you use the wrong type of DCT compression, you may get a bit of smearing or ghosting, eg. Using pjpeg on interlaced formats instead of Mjpeg.



www.strypesinpost.com