MPEG interlaced questions

[jsoto]

May be this is not the forum for this kind of questions, but I know there are good MPEG experts here....
I'm a little bit puzzled with interlaced/progressive stuff.

First of all , some simple questions:
a) A picture is a synonym of frame? Or.., may be a picture can be made by one frame or two fields?
b) One interlaced GOP, say 15 pictures (=frames?,) have 30 fields, doesn't it?
c) the fields are "inside" the frames, so, with VObEdit, i.e., you do not see the fields, but the frames

In MPEG headers:
1.- Sequence_extension:
There is a flag called "progressive_sequence"
2.- Picture_Coding_extension:
There is a flag "progressive_frame"
Also, there are other flags/values like:
Top_Field_first
Alternate Scan
Picture structure

More questions:
d) Which are the valid combinations of Progressive_sequence and progressive_frame flags?. Are both related to Interlace/progressive encoding?
e)Does Top_field_first have sense in progressive material?. I've seen this flag at "0" but also at "1" in different progressive material
f) Picture structure: AFAIK it can be frame or field, but what does it exactly mean? Could have both
g) What about the scan method? Alternate and Zigzag. Are they related to Interlace/Progressive?

I've heard somewhere that many times progressive material is flagged as interlaced. This make sense because I've seen many originals where DVD2AVI reports interlaced but there are no interlacing artifacts. So is it really true? In this case, how to detect if a source is true-interlaced or not?

jsoto

[neuron2]

a) A picture is a synonym of frame? Or.., may be a picture can be made by one frame or two fields? A picture is the unit of MPEG encoding. It can contain either both fields of a frame (frame structure) or just one of the fields (field structure).

b) One interlaced GOP, say 15 pictures (=frames?,) have 30 fields, doesn't it? Your phrase "interlaced GOP" is ambiguous. If it has 15 frame structured pictures, then yes, there are 30 fields. It cannot have 15 field-structured pictures, because it is not an even number.

c) the fields are "inside" the frames, so, with VObEdit, i.e., you do not see the fields, but the frames Two fields make up a frame. I don't know what VOBEdit shows.

d) Which are the valid combinations of Progressive_sequence and progressive_frame flags?. Are both related to Interlace/progressive encoding? Best to refer to the MPEG2 video spec for that.

e)Does Top_field_first have sense in progressive material?. I've seen this flag at "0" but also at "1" in different progressive material From the spec:

top_field_first -- The meaning of this element depends upon picture_structure, progressive_sequence and
repeat_first_field.

If progressive_sequence is equal to ‘0’, this flag indicates what field of a reconstructed frame is output
first by the decoding process:

In a field picture top_field_first shall have the value ‘0’, and the only field output by the decoding process
is the decoded field picture.

In a frame picture top_field_first being set to ‘1’ indicates that the top field of the reconstructed frame is
the first field output by the decoding process. top_field_first being set to ‘0’ indicates that the bottom field
of the reconstructed frame is the first field output by decoding process

If progressive_sequence is equal to ‘1’, this flag, combined with repeat_first_field, indicates how many
times (one, two or three) the reconstructed frame is output by the decoding process.

If repeat_first_field is set to 0, top_field_first shall be set to ‘0’. In this case the output of the decoding
process corresponding to this reconstructed frame consists of one progressive frame.

If top_field_first is set to 0 and repeat_first_field is set to ‘1’, the output of the decoding process
corresponding to this reconstructed frame consists of two identical progressive frames.

If top_field_first is set to 1 and repeat_first_field is set to ‘1’, the output of the decoding process
corresponding to this reconstructed frame consists of three identical progressive frames

f) Picture structure: AFAIK it can be frame or field, but what does it exactly mean? Could have both See spec. For a frame picture both fields are included and encoded as one. For a field picture, each field is encoded separately.

g) What about the scan method? Alternate and Zigzag. Are they related to Interlace/Progressive? You can use either scanning order, but alternate works better for interlaced encoding.

I've heard somewhere that many times progressive material is flagged as interlaced. This make sense because I've seen many originals where DVD2AVI reports interlaced but there are no interlacing artifacts. So is it really true? In this case, how to detect if a source is true-interlaced or not?
It's true. Sometimes people don't know better and just accept the default of their encoder. But also, encoding progressive as interlaced is not as serious as the reverse so if you are unsure of the content, interlaced is safer. My standalone DVD recorder uses interlaced for everything. It doesn't try to analyse the input video to see if it is progressive or interlaced. So, if I capture a movie, I'll have hard telecining encoded as interlaced.

To detect if a source is truly interlaced, you have to step through the fields and see if there are new pictures (not pulldown) at the field rate.

[jsoto]

Many thanks for your clarifications.

I've got the spec and I found the following points

answer to question d)
progressive_sequence– When set to “1” the coded video sequence contains only progressive frame-pictures. When progressive_sequence is set to “0” the coded video sequence may contain both frame-pictures and field-pictures, and frame-picture may be progressive or interlaced frames.

BTW, after your comments and some spec reading, I'm almost sure VobEdit is showing pictures and their coding type (I, P, B)

Finally, from the spec.

The specification allows either the frame to be encoded as picture or the two fields to be encoded as two pictures. Frame encoding or field encoding can be adaptively selected on a frame-by-frame basis
That means, you can have a GOP including pictures frame based (in my understanding, progressive) and also field based (interlaced).
So, the term "interlaced" or "progressive" has sense in a frame basis. A whole video sequence is progressive if all its pictures are frame based progressive, but a interlaced one can also have frame based pictures.

That makes sense... CCE in example, always uses "progressive_sequence=0" (at least in a few tests I've done). but progressive_frame can be 0 or 1.

EDIT:

progressive_frame — If progressive_frame is set to 0 it indicates that the two fields of the frame are interlaced fields in which an interval of time of the field period exists between (corresponding spatial samples) of the two fields. In this case the following restriction applies:
• repeat_first_field shall be zero (two field duration).
If progressive_frame is set to 1 it indicates that the two fields (of the frame) are actually from the same time instant as one another. In this case a number of restrictions to other parameters and flags in the bitstream apply:
• picture_structure shall be “Frame”
• frame_pred_frame_dct shall be 1


picture_structure Meaning
00 reserved
01 Top Field
10 Bottom Field
11 Frame picture


jsoto

[mpucoder]

a picture may be 1 of 4 types, top field, bottom field, progressive frame, interlaced frame. (why it takes 3 bits to express this is a bit of a mystery). The field pictures and progressive frame should be obvious, the interlaced frame seperates the fields but encodes both as a single picture.

Progressive sequence means the display device is progressive, decoding is done as frames instead of fields, therefore only progressive frame pictures are allowed. Also repeating for framerate changes is done at the frame level rather than field level (rff does not mean repeat first field in a progressive sequence, it and tff form a count of frames to be repeated)

A non-progressive sequence (aka interlaced sequence) can use field or frame pictures, and the frame pictures may be progressive (both fields temporally same) or interlaced. The picture types may be mixed freely to accomplish the best compression. Field pictures are always paired. The only restriction is that pulldown may be applied only to progressive frame pictures.

I know most of what I said is repeating what neuron2 and jsoto have said, but worded differently. One very important point, picture types do not determine sequence type, it is the other way around. Normal NTSC movies are interlaced sequences made up of progressive frame pictures.

[jsoto]

I know most of what I said is repeating what neuron2 and jsoto have said, but worded differently. Well, it may be the same, but now it is crystal clear to me. Thanks for summarizing.
jsoto

[peter100m]

I've heard somewhere that many times progressive material is flagged as interlaced. This make sense because I've seen many originals where DVD2AVI reports interlaced but there are no interlacing artifacts. So is it really true? In this case, how to detect if a source is true-interlaced or not?

This is also true for many commercial authored DVDs. Often master tapes can have progressive video mixed with interlaced (sometimes end credits or small edits are inserted as interlaced on tape). So the authoring houses encodes as interlaced to "protect" themselves from bad encodes, since it is impossible to know beforehand if the video is completely progressive.

[NoX1911]

Is it true that even though a picture is flagged as 'progressive frame' it is (technically) encoded as 2 fields so DVD video streams are always interlaced? Someone's claiming that MPEG2 decoderchip output and DVDs in general are always interlaced (measured with SDI (http://en.wikipedia.org/wiki/Serial_Digital_Interface)).

I don't follow him in this point.

What's right?

[neuron2]

It's not true.

[mpucoder]

Have a look back at my previous post from a few years back. A "progressive frame" is NOT interlaced, although there is such a thing as an interlaced frame. The encoder is free to choose whatever is appropriate for the source and most efficient to encode.

The composite and S-Video outputs of a DVD player will be interlaced, as they comply with NTSC/PAL/SECAM standards (480i or 576i). If the player is equipped with component outputs they may be either interlaced or progressive, and even possibly upscaled.

[NoX1911]

I found this as well:
Recommendation ITU-T H.262 (1995 E) - ISO/IEC 13818-2: 1995 (E)

6.1.1.1 Progressive and interlaced sequences
This specification deals with coding of both progressive and interlaced sequences.
The output of the decoding process, for interlaced sequences, consists of a series of reconstructed
fields that are separated in time by a field period. The two fields of a frame may be coded separately
(field-pictures). Alternatively the two fields may be coded together as a frame (frame-pictures). Both
frame pictures and field pictures may be used in a single video sequence.
In progressive sequences each picture in the sequence shall be a frame picture. The sequence, at the
output of the decoding process, consists of a series of reconstructed frames that are separated in time
by a frame period.
Not sure, but i think DVD elementary stream might be always (progressive_frame=0/1 - progressive_sequence=0) so decoder output should always be interlaced (interlace_sequence) for PAL/NTSC but frames internally can be progressively or field-based compressed.

[jinjin_jp]

First of all , some simple questions:
a) A picture is a synonym of frame? Or.., may be a picture can be made by one frame or two fields?
b) One interlaced GOP, say 15 pictures (=frames?,) have 30 fields, doesn't it?

More questions:
f) Picture structure: AFAIK it can be frame or field, but what does it exactly mean? Could have both

I've examined about picture, frame, and field.
Here is the figure which I posted in Japan before.
http://yaki2fan.hp.infoseek.co.jp/cgi-bin/bbs/img/2596.png
Sorry that it is Japanese.
Figure is described from top;
(1)Picture(GOP structure)
(2)Picture(replaying order)
(3)Field(2 or 3 field devided from 1 picure, there converted to 30fps(NTSC) from 24fps(cinema) by 2:3 pull-down)
(4)Frame(2 field convined to 1 picure).
(half upper is when closed GOP, half lower is when open GOP.)
I confirmed (1) by ReMpeg, (2) by Cutterman, and (4) by MPG2JPG with using actual VOB files.
Purple frames of (4) were interlaced. They are Zigzag.

Does it related with what is discussed here?
Sorry it is not.

Regards.

(edit)
Sorry above figure can't link correctly.
Please click figure in this post (http://yaki2fan.hp.infoseek.co.jp/cgi-bin/bbs/wforum.cgi?no=2596&reno=no&oya=2596&mode=msgview).
(edit)
Above can't link correctly, too.
I'll insert figure directly.
http://img510.imageshack.us/img510/2696/imagegopdoom9ew1.th.png (http://img510.imageshack.us/my.php?image=imagegopdoom9ew1.png)http://img510.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

[NoX1911]

I've played with the 'progressive_sequence' bit by creating an ES with CCE and 'progressive frame' option set. Since the bitstream had no 'progressive_sequence' bit set i did it manually with restream. Theory was, the samples would be streamed progressively (from decoder framebuffer) instead of field-wise. To get a proper output on interlace systems i vertically stacked the fields (instead of interleave) so you actually see two separated fields at once by watching the whole frame. I've tested two standalone players on standard 50Hz CRTs. Both showed the stacked fields nevertheless so either the players/decoders ignore the bit, the bitstream needs to be altered even more or the bit is intended for something else.

Picture_structure is defined by 2 bits (not 3 bits like stated before) and 3 states (not 4) but if you differ 'Frame Picture' between 'progressive_sequence' '0' and '1' there are indeed 4 ('framebased interlace' and 'progressive').
http://img509.imageshack.us/img509/9393/picturestructurehb3.png
For my encoding CCE should have picked the right one 'Frame picture'. BitrateViewer and MediaInfo show 'picture structure=frame' and 'frame type=progressive'. ReStreams did change a 'bit' in every GOP/sequence indeed but i didn't checked that against the official syntax.

The only encoder i've found so far that actually sets the 'progressive_sequence' bit is Hank's encoder when setting to 'progressive' mode (not sure about 'auto' ) so many ppl have tested this bit already before and if it would have resulted in a sequential sample output someone would have told so already i think.

My understanding about the 'progressive_sequence' bit is that by setting to '1' the decoder framebuffer will output the samples frame-based (at 1/25s) not field-based (at 1/50s) but i'm not sure on that.
7.12 Output of the decoding process
When a progressive sequence is decoded (progressive_sequence is equal to 1), the luminance and
chrominance samples of the reconstructed frames are output by decoding process in the form of
progressive frames and the output rate is the frame rate.

[mpucoder]

Picture_structure is defined by 2 bits (not 3 bits like stated before) and 3 states (not 4)
See "progressive_frame" bit in picture coding extension (6.3.10), also the definition of the progressive_sequence bit in section 6.3.5 which reads

progressive_sequence - When set to '1' the coded video sequence contains only progressive frame-
pictures. When progressive_sequence is set to '0' the coded video sequence may contain both frame-
pictures and field-pictures, and the frame-picture may be progressive or interlaced frames.

Why did you stack the fields vertically? That would be the way an interlaced frame would get encoded, and unless your source is able to indicate to the encoder that its frames are not normal progressive frames the encoder will assume the input is progressive frames. Since that is the desired encoding the encoder will make no changes to line order. No manipulation of the frames prior to encoding is needed.

[NoX1911]

Yep, makes sense. 'Picture_structure' (2bit) and 'progressive_frame' (1bit) = 3bit (4 states = 1 progressive, 1 framebased interlace + 2 field modes). I focused on 'picture_structure' only before.

My vertical stack was intended to fix the (experimental) scan order if the 'decoder output' would be real progressive. By this the upper 288 lines should have been the first field (and the second 288 lines bottom field) on final PAL display. By remaining strict timings just the scan order should have been changed (interlaced output = lines 1, 3, 5 - progressive output = lines 1,2,3). But it didn't work out yet.
7.12 Output of the decoding process
When a progressive sequence is decoded (progressive_sequence is equal to 1), the luminance and
chrominance samples of the reconstructed frames are output by decoding process in the form of
progressive frames and the output rate is the frame rate.
There's at least one more logical processing stage following (decoding_process -> display_process) that may brake it into fields again or the decoder doesn't output progressive at all. I'm barely sure on all that though.

[meRobs]

Hi all. I realise my question in not exactly on the topic, but, having you experts (almost) on tap I am hoping one of you would respond!

My intention is to routinely use Progressive video as the only means of avoiding flicker when Adobe Premier Pro exports a Timeline of Stills (scanned slides) as PAL M2V. On exporting with Field order = 'None (progressive)', Adobe Encore will burn it to DVD without transcoding. Hence it will still be Progressive! As a rough check I opened the M2V and a VOB in Gspot - it read them as 'PROG'.

1) My Pioneer DV-400 player accepted the DVD and output it as progressive through HDMI to my Plasma TV. It played with no flicker (not possible for interlaced video from Premiere without anti-flicker filter). May I assume that any other progressive scan DVD player will also accept and play a progressive DVD without change?

2) The same DVD fed to an older interlaced-player resulted in a change. Some flicker was introduced and small changes occured in image properties. I took this to mean it converted to interlaced?

3) When I placed an interlaced M2V and a progressive M2V on the same timeline in Encore, they played as expected in the progressive player. This suggests there was a flag set on each file or even on each frame to indicate whether progressive or not?

4) thus, exporting as Progressive is the simplest way of avoiding flicker in Stills and without downgrading image quality. Provided, one will always be able to obtain a progessive scan DVD player!

Are these comments correct?
Thanks

[NoX1911]

The 'decoder_process' of DVD Players always has interlace output. Its unclear if 'progressive_sequence' changes that. Nevertheless, seems that your "new" DVD Player has its own 'progressive scan' conversion in the 'display_process' whereas your "old" DVD Player transports (via analog) the interlace signal directly to your TV that has its own 'progressive scan' conversion method that seems not to be as good as the one of your DVD Player. Not sure though...

There is another chance that your MPEG2 encoder doesn't really encode every frame strictly progressive. You might want to check other encoders like CCE, TMPGENC or HCENCODER for testing purpose.

Maybe you can find a tool that is able to analyze MPEG2 bitstreams for specific flags on a framebase. I'm searching for something like that as well.

[meRobs]

NOX1911, I cannot follow your reasoning!
First of all, the evidence suggests to me that my progressive M2V is in fact progressive. Adobe claims that the setting I used in Premiere Pro would give progressive output (this App is designed to handle, in and out, progressive) and the encoding time is only 60% as long as it takes to export interlaced M2V (probably quicker to encode single full frames). Yet you suggest this file is interlaced, so, lets call it psuedo-prog.

My 'new' DVD player is set to deliver 1080p output via HDMI. You suggest that it converts my psuedo-prog file to progressive while at the same time removing flicker (how would it know this is unwanted?). Yet when a default export from Premiere (interlaced and no attempt to remove flicker) is fed to this player via the DVD it leaves the flicker intact!

Moreover, my 'old' player (composite output, and therefore interlaced) accepts an interlaced M2V with flicker removed in Premiere and does not modify it (no added flicker, etc) and accepts an interlaced with flicker not removed and leaves the flicker as is and has no affect on image qaulity. Yet, it treats my psuedo-prog file differently. It adds some flicker, which it didn't do to the interlaced files, lowers image quality a little and moves subtitles (added to identify my settings)! It seems this interlaced player did nothing to the truly-interlaced files, yet did some work on my psuedo-prog file. Why?

Clearly, the psuedo-prog file is different from interlaced M2Vs. And since it was much quicker to encode and contains no flicker how can it be anything but progressive?
??
Now I am really confused!

[NoX1911]

'Progressive_frame' is not a global state, its a frame state and the flag 'progressive_sequence' is sequence based (most of the time one gop). In short, you can't make sure by simple analyzers (that very likely only check the first sequence/gop) if your frames are really progressive unless you check every frame or trust the encoder blindly. There is still a chance that some cheap encoders decides to encode non-progressive frames in specific situations. That's why i recommended to test several encoders.

Progressive frames are internal states. When the decoding process is finished it always sends the pictures field-based (interlace_sequence only). The next processing stage (display_process) takes this fields and converts it to specific output signals. That could be PAL/NTSC (with pulldown on demand) or more complex standards like DVI/HDMI that would require additional rebuilding of progressive scan pictures.

I don't know if the 'display_process' can rely on metadata (like 'progressive_frame' flags) from the 'decoding_process' to help decide if the fields have to be combined or not (on newer DVD players with progressive scan output) but sure is that once the signal passes an analog way (like SCART, Composite or Y/C) that information is gone reliably and the TV has to decide itself when and what to combine to progressive pics.

That's my theory...

[Biggiesized]

Great thread, guys! Highly technical yet easy to follow along.

I have one simple question after reading all of this: is 'progressive_sequence = 1' allowed on DVDs for film content? Or are all commercially encoded film content DVDs flagged as 'progressive_sequence = 0' with progressive or interlaced frame-pictures?

[Koutsoubos]

I have one simple question after reading all of this: is 'progressive_sequence = 1' allowed on DVDs for film content?


Any definite answer to this deceptively simple question?


Cf. DVD FAQ #3.4: http://www.dvddemystified.com/dvdfaq.html#3.4 where it says: "MPEG-2 progressive_sequence is not allowed".

However, a couple of other aspects in that paragraph are not entirely accurate. So I'm still holding out for somehow who can say for certain.

[Koutsoubos]

From this piece of info it appears that Prog_Seq=1; Prog_Frame=1; TFF=off is allowed:

<Description of disc problems>
The "progressive_frame" of all frames is equal to "0", although the "progressive_sequence" is equal to "1" in the "Sequence_extension."

<Phenomena of playback problems>
Some players judge the recorded data as an error, and the picture does not appear since the player performs the skip operation during the playing back.

<Requirements for production of discs>
When the "progressive_sequence" is equal to "1" in the "Sequence_extension," only the "progressive_frame" is necessary to be equal to "1" in this sequence.
(Refer to "6.3.5 Sequence Extension" of MPEG Specifications.)




[http://www.dvdforum.org/booksub/fvn0014.htm]