"Interlaced" Flag

[manolito]

Please can someone enlighten me how a PAL standalone interprets the interlaced flag?

I live in PAL country, my standalone is a Cyberhome 402 connected to a standard CRT TV via SCART. The standalone has no "progressive scan" output (and my TV set would not be able to handle it).

When I play a DVD I created from an analog TV capture where the movie itself is purely progressive, but the end credits are interlaced, these end credits look very different depending on whether the stream is flagged as progressive or as interlaced. The whole DVD is encoded as progressive (Zigzag scan), the only difference is the flagging. (I used "Restream" to change the flags from "progressive" to "interlaced TFF"). With the interlaced flag the end credits look good, with the progressive flag they look jagged and the vertical movement is jerky.

Why?

I thought that a standalone connected to a standard CRT TV always has to separate the frames into fields and send them to the TV one field after another, no matter how the stream is flagged. Or does the player change the timing somehow depending on the interlaced flag? Or is it the field order? For progressive content the correct field order should not matter, right? Could it be that my player outputs the fields BFF when the stream is flagged as progressive?

Any thoughts?

Cheers
manolito

[Si]

I'd re-capture the DVD output and compare the frames/fields with the original to get some more info on as to what's happening.

regards

Simon

[SeeMoreDigital]

...When I play a DVD I created from an analog TV capture where the movie itself is purely progressive, but the end credits are interlaced...I very much doubt your analogue PAL captured source will have been transmitted (and therefore captured) "progressively"!

[Kika]

I very much doubt your analogue PAL captured source will have been transmitted (and therefore captured) "progressively"!

Why?
If you have doubt's - no problem, but an explanation might be much more helpfull than posting "i have doubt's"!

I have a lot captures from analogue PAL Source with a true progressive picture-structure (also from PAL DVB-S).

[manolito]

@ SeeMoreDigital

Sounds like terminology confusion to me...

You seem to say that an analogue TV capture has to be "interlaced" by definition. Of course the TV station sends out fields (not full frames), and my analogue TV also displays fields instead of full frames. If you call that "interlaced" then you are certainly right.

But here in this forum term "interlaced" is mostly used differently. When we say "interlaced" it means that it is "not progressive". It all comes down to analyzing if the reassembled full frame shows combing artifacts on horizontal movements or not. If my analogue captured AVI file does not show any combing, then it is "progressive". Which means that the source was optical film shot at 24 full frames per second, and that it was converted to 25 fps PAL without duplicating fields.

In this case my capture file is considered "Progressive" and can and should be encoded as "Progressive". The problem I had was that the source was "hybrid" (movie = progressive, credits = interlaced). Of course I could just encode the credits separately, but I would still like to find out why my standalone messes up the interlaced credits (encoded as progressive) if the stream is flagged as progressive, but displays the credits without artifacts if the same stream is flagged as interlaced.

Cheers
manolito

[bREAkDoWN]

Or is it the field order? For progressive content the correct field order should not matter, right? Could it be that my player outputs the fields BFF when the stream is flagged as progressive?

Any thoughts?

Cheers
manolito

I would say it's a problem of field order.. There are also differences in the encoding process between progressive and interlaced contents, but since you only need to change the flag without reencoding to make the credits look good, i think that the artefacts come from the field order used by the player for progressive reproduction; while the artefacts coming from having encoded interlaced contents in progressive mode aren't visible.

[Si]

Another thing is that TMPGEnc 2.54 and above didn't use to pay any attention to the field order flag setting if encoding progressive. You could have the same "bug" with your encoder.

I emailed Mr Pegasus but our mutual lack of common language prevented any progress in getting this "bug" removed.

Since then, I 've always stuck with using TMPG 2.53 (which does pay attention to field order flag) for MPEG-2 encodes.

regards
Simon

[manolito]

@ bREAkDoWN and Si

Yes, you are both right, it is the TFF flag and not the "Interlaced" flag which is causing my confusion.

Up to now I was under the impression that for a progressive encode the TFF flag is irrelevant, and that a standalone player should not evaluate the TFF flag if the stream is progressive. But obviously this is not the case for my standalone.

I did a few test conversions using all the encoders I have installed (CCE 2.67, HC 0.17, QuEnc 0.62 Alpha5, FreeEnc 0.31), and I found that for a progressive encode CCE does also set the TFF flag while all the others do not.

This does explain the behavior of my interlaced end credits. Normally they should look terrible when they were encoded as progressive no matter how the stream is flagged. But in this case there is no horizontal movement so no combing artefacts are visible. But my player obviously sends out the fields as BFF because QuEnc did not set the TFF flag which explains the jerky vertical movement.

So what do the DVD specs say about the TFF flag for a progressive stream? Should the encoder set the TFF flag or not? I think I'm going to ask the gurus in the MPEG2 thread... :D

Cheers
manolito

[bREAkDoWN]

@ bREAkDoWN and Si

So what do the DVD specs say about the TFF flag for a progressive stream? Should the encoder set the TFF flag or not? I think I'm going to ask the gurus in the MPEG2 thread... :D

Cheers
manolito

I'd guess that it is undefined, because if the content is progressive there is no sense in setting something about fields, since they don't exist in a progressive context.
The matter is that if a stream is flagged as progressive, it shouldn't contain any interlaced parts. If it does, you have already found a sort of solution/workaround.

[dragongodz]

i have made my comments about this here
http://forum.doom9.org/showthread.php?p=813888#post813888

i will comment on here on this statement though
TMPGEnc 2.54 and above didn't use to pay any attention to the field order flag setting if encoding progressive. You could have the same "bug" with your encoder.
please learn the difference between progressive and interlaced encoding before calling things bugs. it isnt. progressive does not encode fields at all but frames so specifying field order is redundant except in 1 specific case, which i mention in the link above.

[Si]

please learn the difference between progressive and interlaced encoding before calling things bugs.

Please learn the difference between bugs and "bugs" before commenting again.

Simon

[dragongodz]

Please learn the difference between bugs and "bugs" before commenting again.
please learn if something is an actual bug or your not knowing how something works before commenting again. and please dont bother to comment at all if you just want to try and play word games.

[Si]

I'm very sorry.

There's obviously some language difficulties here.

When someone uses a word such as say garden and they put it in quotes as in "garden" it means that the thing they are refferring to is not quite a garden and could even be a rubbish tip.

So If I say version 2.54 of TMPGEnc has a "bug" then I believe I am saying it is not actually a bug.

Thereby showing that I know a little bit about the subject and that I don't need learning.

Although I'm sure you would agree that we can all do to learn more in life.

Such as actually helping the OP in his quest to find out why his end credits look bad on a TV.

regards

Simon