Log in

View Full Version : Is progresive TFF or BFF?


Mole
18th June 2012, 02:54
Is progressive supposed to be TFF or BFF?

I know technically because it's progressive you can't set it "wrong" like with interlaced material.

For some reason in my head, I always remembers that interlaced are supposed to be TFF, except DV, which are BFF.

Progressive are also BFF.

But then in the CCE FAQ (http://forum.doom9.org/showthread.php?t=53770), it says Progressive material is always top field first

However, in HCEnc FAQ (http://forum.doom9.org/showthread.php?t=130443) it says TFF + progressive is not allowed.
In other words, progressive must be BFF

If I'm creating a progressive video at 23.976 which I'll use pulldown to get 29.97, should I encode the video as TFF or BFF?
What about 24 pulldown to 25?

Then I should also specify the field order used when encoding in pulldown as well, right?

Lyris
18th June 2012, 04:44
When I encode commercial DVDs with CCE SP3, I always use TFF by leaving the "Output top field first stream" checked.

Mole
18th June 2012, 06:21
Yeah, I always do that too, and offset line to 0.

But why then won't HCEnc allow TFF progressive?

Ghitulescu
18th June 2012, 07:57
Progressive has no fields, thus BFF or TFF does not exist. That's why TMPGenc does not allow it. What CCE says for TFF refers strictly to the interlaced source.

mp3dom
18th June 2012, 09:24
Progressive + TFF flag is allowed when Progressive Sequence is OFF (this also allows to switch from progressive to interlaced - and vice versa - encoding in the same stream), it's not allowed when Progressive Sequence is ON (in that case it should be Progressive + BFF and switch from progressive to interlaced - and vice versa - is not possible)

Mole
18th June 2012, 09:36
ahh... I see, thanks for the clarification!

Guest
18th June 2012, 13:08
Progressive + TFF flag is allowed when Progressive Sequence is OFF (this also allows to switch from progressive to interlaced - and vice versa - encoding in the same stream), it's not allowed when Progressive Sequence is ON (in that case it should be Progressive + BFF and switch from progressive to interlaced - and vice versa - is not possible) Strictly speaking, the MPEG2 spec allows TFF=1 with progressive_sequence=1 but it then signals frame pulldown (in conjunction with RFF=1).

Mole
18th June 2012, 13:24
So, if I want to make a progressive stream and then use pulldown say from 24fps to 25fps, is it OK to enable progressive sequence, then set it as BFF?

In DGPulldown, I then also tell it to set as BFF (I think default is Top fiel first, which means I just uncheck that, right?)

What about "Set drop frames"? There is 3 modes I can set it as. Ticked, empty, or grayed out ticked.

Guest
18th June 2012, 13:32
[You are not concise in your statements. E.g., a "progressive stream" can mean the content is progressive or the progressive_sequence flag is set; they are not the same.]

It depends on whether you want to make frame pulldown or field pulldown. DGPulldown does not do frame pulldown.

Frame pulldown: Use progressive sequence=1, RFF=1. Then TFF signals number of frame repeats.

Field pulldown: Use progressive sequence=0, use RFF and TFF in the standard way.

A 24 to 25 conversion will look better with field pulldown.

Please read the DGPulldown documentation for clarification on its usage.

Mole
18th June 2012, 13:40
Yes, of course I want field pulldown.

So, if I want to field pulldown a progressive content from 23.976 to 29.97 or 24 to 25, I should not enable the progressive sequence in the MPEG encoder, and use TFF, is that correct?

Mole
18th June 2012, 13:46
Oh, also, for 24fps which will be field pulldown to 25, would GOP size 15 be too big?

Should I set it to 12 like for 23.976?

Guest
18th June 2012, 14:10
So, if I want to field pulldown a progressive content from 23.976 to 29.97 or 24 to 25, I should not enable the progressive sequence in the MPEG encoder, and use TFF, is that correct? You can use BFF too, it doesn't matter (coordinate it with the setting in DGPulldown).

For considerations on GOP size, please read the file GOPNote.txt included in the DGPulldown distribution.

Mole
18th June 2012, 14:13
Yes, I already read that, but it's a very confusing document.

Also I could not find info about 24->25 only about 23.976->29.97

Guest
18th June 2012, 14:21
Yes, I already read that, but it's a very confusing document. What are you confused about?

Also I could not find info about 24->25 only about 23.976->29.97 You need to apply the same principles to your desired conversion. I'm sorry that I don't have extra time right now to do that for you in the case of creating a PAL DVD, and in any case I do not have access to the PAL DVD requirements. If you are not technically equipped to do that, then just use 12 frames per GOP or do some experiments.

Mole
18th June 2012, 14:27
That's OK. Thanks so far.

I guess too small GOP is better than too big.

mp3dom
18th June 2012, 15:47
15 frames GOP for euro pulldown is too much. Scenarist will refuse it. Stay at 12 frames.

TheSkiller
18th June 2012, 18:13
Progressive has no fields, thus BFF or TFF does not exist. Yes, but the flag that signals TFF/BFF is always inside every MPEG2 video (it has to be), so one has to decide for either TFF or BFF even with a progressive video as weird as it sounds.

Actually, there is only one flag: TFF=true/false.

So, looking at it from that point of view it makes sense not to set this flag for something that is not TFF due to being progressive, but leaving it false which means BFF so to say.


TFF can be set even for progressive video if you do not set any of the two progressive flags, in other words if it's flagged like interlaced video. If you want to flag it properly as progressive by making use of both progressive flags ("frametype progressive" and "progressive sequence"), TFF has to be false otherwise you have an illegal combination of flags for DVD.
You can also set only frametype progressive, which, afaik, is not illegal to use with TFF=true but only as long as progressive sequence is false.

And "progressive sequence" has to be set in conjunction with "frametype progressive" (and therefore with TFF=false).
So, in a nutshell, if you encode progressive and flag progressive properly using both flags, the TFF flag has to be false.



Euro-Pulldown (24 or 23.976 -> 25) will give a stutter twice a second which, depending on the nature of the video, can be annoying.

If you use soft-pulldown the output video will be interlaced so in that case you have to flag the video like interlaced (and afaik pulldown.exe will unset any progressive flags automatically so you don't have to worry about it, this also means that TFF=true/false doesn't matter as it's plain interlaced video generated from a progressive video).


Yes, 15 GOP is too long for such pulldown.

mp3dom
18th June 2012, 18:28
For euro-pulldown it's much better to encode as PAL progressive 23.98 (or 24) and then add the pulldown later with DGPulldown. In this way you can gain some quality due to progressive encoding. The only drawback of DGPulldown is that you can have the last frame flagged as 'repeated' and this creates some problem when muxing with Scenarist (basically, you can't join two videos if the last frame of the first video is flagged as repeated).

Mole
18th June 2012, 18:57
OK, so from now on I'll encode anything which needs to be pulldown as progressive sequence=false and TFF=true.

But true 25fps progressive videos, I'll encode as progressive sequence=true and TFF=false.

I think I understand the logic now.

TheSkiller
18th June 2012, 19:54
But true 25fps progressive videos, I'll encode as progressive sequence=true and TFF=false.Yep, that's it. But you might want to double-check in case of "progressive sequence=true" if you have "frametype progressive=true" as well because progressive sequence alone is not allowed. Restream (http://www.videohelp.com/tools/Restream) allows checking and changing these flags.

However, if you encode strictly as progressive in HCEnc or CCE (any version) then frametype progressive=true automatically (there's no option for it in HCEnc or CCE), but note that CCE never sets the progressive sequence flag. In such case you have to set it yourself using Restream.

Mole
19th June 2012, 01:35
Ahhh.. IC IC! I wasn't aware about these 2 different flags. I've always thought there were only one progressive flag.

OK, so for pure 100% progressive material 25fps (GOP=15) and 29.97 (GOP=18), I'll use
TFF=false, frametype progressive=true, progressive sequence=true

But for progressive material 24fps and 23.976 (GOP=12) which I want to use field pulldown after encoding to 25 or 29.97, I'll use
TFF=true, frametype progressive=true, progressive sequence=false

FUI, I am aware that you usually can't change certain flags with re-stream if the MPEG wasn't encoded that way, so it's important to encode it right first, then I merely use restream to enable the progressive sequence flag only.

ifb
19th June 2012, 02:07
Here are the relevant parts of the spec if you really want something to read.

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.

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.


repeat_first_field – This flag is applicable only in a frame picture; in a field picture it shall be set to zero and does not affect the decoding process.

If progressive_sequence is equal to 0 and progressive_frame is equal to 0, repeat_first_field shall be zero, and the output of the decoding process corresponding to this reconstructed frame consists of two fields.

If progressive_sequence is equal to 0 and progressive_frame is equal to 1:

If this flag is set to 0, the output of the decoding process corresponding to this reconstructed frame consists of two fields. The first field (top or bottom field as identified by top_field_first) is followed by the other field.

If it is set to 1, the output of the decoding process corresponding to this reconstructed frame consists of three fields. The first field (top or bottom field as identified by top_field_first) is followed by the other field, then the first field is repeated.

If progressive_sequence is equal to 1:

If this flag is set to 0, the output of the decoding process corresponding to this reconstructed frame consists of one frame.

If it is set to 1, the output of the decoding process corresponding to this reconstructed frame consists of two or three frames, depending on the value of top_field_first.


picture_structure – This is a 2-bit integer defined in the Table 6-14.
picture_structure Meaning
00 Reserved
01 Top Field
10 Bottom Field
11 Frame picture

kolak
20th June 2012, 01:03
Oh, also, for 24fps which will be field pulldown to 25, would GOP size 15 be too big?

Should I set it to 12 like for 23.976?

As far as I can tell GOP=15 is not allowed for 23.976p+ pulldown. Use 12. GOP has to be <0.606 sec if I'm correct, so 15 is to long for 23.976p.

kolak
20th June 2012, 01:06
For euro-pulldown it's much better to encode as PAL progressive 23.98 (or 24) and then add the pulldown later with DGPulldown. In this way you can gain some quality due to progressive encoding. The only drawback of DGPulldown is that you can have the last frame flagged as 'repeated' and this creates some problem when muxing with Scenarist (basically, you can't join two videos if the last frame of the first video is flagged as repeated).

Well- main problem is jerkiness, which is so annoying.

kolak
20th June 2012, 01:11
.

However, if you encode strictly as progressive in HCEnc or CCE (any version) then frametype progressive=true automatically (there's no option for it in HCEnc or CCE), but note that CCE never sets the progressive sequence flag. In such case you have to set it yourself using Restream.

Yes, because I think it's out of DVD spec (ifb- are you talking about DVD spec?)- even Toshiba encoder does not set progressive sequence flag=1. None of the pro DVD encoders does it as far as I can tell. Carbon Coder use to do it, but not anymore for DVD target. Another reason can be due to fact that eg. CC-SP3 can switch between progressive/interlaced and than this flag can't be 1. On the other hand there is also pure progressive mode, but even than this flag is set to 0.
Frametype progressive=true should be enough.

Mole
20th June 2012, 02:26
Yeah, but the jerkiness is only when viewed with a CRT TV, right?

When viewed on a progressive TV, the repeat fields flag would be ignored and it'll play it progressive, is that correct?

ifb
20th June 2012, 02:30
Yes, because I think it's out of DVD spec (ifb- are you talking about DVD spec?)What I posted is direct from the MPEG-2 spec. I don't have a DVD spec to see what additional (if any) limitations there are.

My guess is that since DVD is a legacy format, progressive_sequence would be false especially since there's no disadvantage to it. It doesn't restrict you from doing pulldown or some other trick to put progressive content into a legacy interlaced format.

mp3dom
20th June 2012, 08:04
Yeah, but the jerkiness is only when viewed with a CRT TV, right?


No, PAL is intended to be at fixed framerate of 50i so on almost every TV you'll see the jerkiness (crt but also progressive tv like LCDs or plasma). You'll not see the jerkiness on PC or HTPC where the mpeg2 decoder simply ignore the soft pulldown flags and outputs true 23.98/24p.

As far as I know, there's no set-top dvd players out there that on a PAL with euro-pulldown applied, ignores the soft pulldown and outputs 23.98/24p.
It's a "strange" cadence for pal and also not very common. It doesn't ever try to reconstruct progressive frames. It's simply played back at 50i.

Different thing for ntsc with 3:2 pulldown. In that case some recent players already outputs 24p via HDMI



When viewed on a progressive TV, the repeat fields flag would be ignored and it'll play it progressive, is that correct?

The standard way is not to remove pulldown, but reconstruct the progressive frames so 60i (with 3:2 pulldown) became 60p

Mole
20th June 2012, 08:14
In other words, the LCD/Plasma TV will receive a 50i signal from the DVD player, it will then think that those repeated fields are actually interlaced, then deinterlace it to get progressive?

Hmm, then I'm starting to understand why most PAL movies nowadays are just sped up 25fps instead of 24fps+repeat field.

mp3dom
20th June 2012, 11:13
In other words, the LCD/Plasma TV will receive a 50i signal from the DVD player, it will then think that those repeated fields are actually interlaced, then deinterlace it to get progressive?

Exactly.


Hmm, then I'm starting to understand why most PAL movies nowadays are just sped up 25fps instead of 24fps+repeat field.

It depends by contents. Horizontal/vertical panning are a problem. Some TVs overcome this jerkyness with some kind of interpolation. You can reduce it to a decent level. Movies suffer more due to the true 24fps, while cartoons/anime suffer less (they're often animated at lower framerate)

Mole
20th June 2012, 11:40
My dilemma is now whether to chose which evils.

1. Use 24fps + field pulldown

2. Force 24fps to 25fps and adjust the audio to match

I'm starting to think that the better solution is 2. On most movies, adjusting the audio may not be as noticeable as the jerkiness. Also for option 1. quality may depend on how good the TV's deinterlace routine is.

If I speed it to 25fps progressive, I can set both frametype progressive=true, progressive sequence=true.

kolak
20th June 2012, 11:51
What I posted is direct from the MPEG-2 spec. I don't have a DVD spec to see what additional (if any) limitations there are.

My guess is that since DVD is a legacy format, progressive_sequence would be false especially since there's no disadvantage to it. It doesn't restrict you from doing pulldown or some other trick to put progressive content into a legacy interlaced format.

Yes- none of pro encoders sets it to 1.

kolak
20th June 2012, 11:52
My dilemma is now whether to chose which evils.

1. Use 24fps + field pulldown

2. Force 24fps to 25fps and adjust the audio to match

I'm starting to think that the better solution is 2. On most movies, adjusting the audio may not be as noticeable as the jerkiness. Also for option 1. quality may depend on how good the TV's deinterlace routine is.

If I speed it to 25fps progressive, I can set both frametype progressive=true, progressive sequence=true.

95% of movies are speeded up.

mp3dom
20th June 2012, 13:01
On most movies, adjusting the audio may not be as noticeable as the jerkiness.

You can notice it for well-known musics. The problem here is both speedup and pitch shift which also makes the human voice sounds 'younger'.
You can overcome the pitch-shift if you do a time stretch (changing the tempo while keeping pitch the same) but here again you can have artifacts. Time stretch algorithms are still not perfects. Some works better on musics, others on voice. In a full movie mix you have both, so some echoes on voice or small drops can be noticeable. With this scenario, having music/effects and voice separated is a plus (you can apply different algorithms to have a perfect result). You need to use a VERY good time stretcher if you need to work on 5.1 mixes. On 5.1 you need to keep the right phase of every channel. A lot of time stretcher are unable to keep the phase of every channel 'fixed' after the time stretch.
This is also the main reason why almost all the speedups doesn't fix the pitch (they just resample it)

Mole
20th June 2012, 13:12
Yeah, I guess the easiest for 5.1 is to simply shift the pitch which should keep every channel still in sync.

Most audio tools such as eac3to simply change the pitch, right?

kolak
20th June 2012, 14:47
You need good pitch correction tool- most of them are crap.
You can use any based on DIRAC technology- these are very good- eg. TimeFactory, which will also keep same phase for 5.1

Mole
20th June 2012, 14:51
What about the one in eac3to?

Guest
20th June 2012, 15:24
This discussion is off topic for the thread. Please start a new one for audio pitch correction.