program sequence flag and program frames flag - always same?

[LisaB]

They can be marked interlaced or progressive, but would there ever be a case when the program sequence is marked differently than the program frames? Or...does the sequence marking depend on the source and the frames depend on the encoding? In other words, a standard mpeg2 source uses field-based encoding, but may be from either interlaced or progressive source....So maybe for 29.97 mpeg2 of film source, the sequence would be progressive, but frame-type would be interlace?...does this make any sense?

[adam]

Sure they can be different, its different on nearly ever commercially released NTSC DVD on the market. Probably so with PAL DVDs too, but I don't have experience with those.

The sequence flag is always set to interlaced for DVD. Its required in the DVD standard. The frame flag is set to either progressive or interlaced depending on whether you encoded with field or frame pictures, basically whether you set the output in the encoder to progressive or interlaced.

Most commercial NTSC DVDs are encoded with frame pictures, so the frames flag is set to progressive and the sequence flag is set to interlaced.

[BJ_M]

frame based encoding is standard for dvd ...


progressive 29.97 encoding is playable on just about any dvd player (i havent found one that it isnt) -- the dvd player will spit out interlaced though .. it will look not as smooth though - ussually ... some other factors also ...

[LisaB]

so, the sequence flag is kind of a pointless flag, since it means nothing, and can be applied willy-nilly to any mpeg?

from your description, the frames flag should be set depending on whether field- or frame-based encoding is used. but the sequence flag means nothing...it is just required to be there for the dvd standard. Well, that would explain why TMPGEnc DVD Author changed the sequence flag from prog to int when it authored an mpeg of mine.

I ask this question because I have 2 MPEG2 files....after authoring to DVD with DVD Author, one makes my standalone DVD choke (jerks, freezes, audio-synch) and the other looks just fine. Using Restream, the one that makes my DVD choke looks like:



while the good one looks like:



when I demultiplex the VOB authored from the bad mpg and check with ReStream, I notice that TDA has switched the sequence label from prog to int. furthermore, when playing the VOB on the computer, it exhibits the same bad behavior. However, by just remultiplexing the VOB with TMPGEnc, the bad VOB can be turned into a good MPG...

I've authored lots of sVCD to DVD using DVD Author, and this is the first time that I've seen something like this. I think the flags are just wrong in the first place...but I don't know the best way to fix it. If I take the bad mpg, change both frames and sequence to interlace, and *then* author with DVD Author, I get a VOB which plays well on the computer (don't know about the standalone yet). In fact, just changing the sequence does the trick. But why? Maybe you think the sequence tag is meaningless, but DVDAuthor certainly does something differently, depending on its state.

[FOO]

Look at the "fields coded" . It's not right

[LisaB]

what is not right about the "fields coded"?

i see the TFF flag alternating every 2 frames. this is standard for a MPEG2 stream which has had 3:2 pulldown performed, right? I don't know what this implies about the sequence and frame tags, though. You can't apply 3:2 pulldown to a frame-based encoding, right?

And as a related question, I'm still not sure when you should mark the sequence as interlace and the frames as progressive.

[FOO]

You may be right , I have an older version of Restream.
It needs to show the RFF "repeat first field" flag also so we can see what's up.

Here is a point of confusion I might be able to clear up.

Some of the flags refer to Storage of frames and some refer to Playback
you can have Progressive storage and Interlaced playback.

The "progressive flag" changes meaning if there is pulldown.
It is required to be set to enable the TFF/RFF flags to be decoded.
This is counter intuitive to me but it's in the rules .

If you look at "mixed" NTSC / FILM you will see the normal
00 01 11 10 TFF RFF sequence WITH the progressive flag set.
when it changes to FILM the Progressive flag goes away and RFF is zero

I suggest getting ISO 13818 and reading it . I had this figgered out a year
ago , but I have dropped bits in the memory

[SLK001]

I always set PROGRESSIVE SEQUENCE I, because I had the same jerkiness as you. In fact, I don't even check the box on my pulldown GUI.

I had always assumed that the PROGRESSIVE SEQUENCE was for some of the HDTV display modes.

[BJ_M]

example of what correct pulldown looks like in restream

[adam]

LisaB, if anything, I would say that the problem occurred not because you used interlaced sequence, but because you let TMPGEnc DVD author change it. Try running the source through pulldowne.exe with prog_seq set to interlaced, and then set the prog_frame flag accordingly.

SLK if you don't check anything in pulldown than you probably will end up with prog_seq set to interlaced. This seems to be how most encoders output video since it is required in the DVD standard, and probably SVCD standard as well.

Taken from DVD Demystified.

Coded frame rates of 24 fps progressive from film, 25 fps interlaced from PAL video, and 29.97 fps interlaced from NTSC video are typical. MPEG-2 progressive_sequence is not allowed, but interlaced sequences can contain progressive pictures and progressive macroblocks.

There's enormous confusion about whether DVD video is progressive or interlaced. Here's the one true answer: Progressive-source video (such as from film) is usually encoded on DVD as interlaced field pairs that can be reinterleaved by a progressive player to recreate the original progressive video.

[LisaB]

After running the source through DoPulldown, with all options at NoChange/Off (i.e., default), the resulting stream was marked as interlaced frames and interlaced sequence. In other words, I guess BJ_M is correct that soft-telecined film will have both frames and sequence marked interlace.

Adam, I didn't even have to set prog_seq to interlaced...just leaving it "NoChange", it ended up changing from prog to int during pulldown.

Foo, it doesn't seem that progressive flag is required for soft telecine. DoPulldown doesn't output it that way, and BJ_M's example isn't set progressive, either.

I should add that the standalone DVD player that chokes is a nice one that has built in 3:2 pulldown.....my other DVD player (also progressive) did just fine with the "progressive sequence".

[FOO]

OK , Damn , now I have to go look it up .

[BJ_M]

some films are a real pickle as they got all sort of things all mixed together ... i do this also as i mix raw mpeg from different sources ..

see here for a good example

http://vektor.theorem.ca/dvd/tech/

[SLK001]

SLK if you don't check anything in pulldown than you probably will end up with prog_seq set to interlaced.

Correct. The default is "INTERLACED".

[FOO]

Some quotes from ISO 13818-2
note there are TWO different "progressive" flags

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.

[LisaB]

Thanks Foo!

In the end, I found that the problematic mpeg was fixed by simply running it through DoPulldown with all options set to default. The only difference I could tell between the original and fixed versions was that the prog_seq and prog_frame was set to interlace (before, both were progressive). Authoring a DVD from the resulting mpegs yielded a DVD that worked perfectly in all 3 of my DVD players, and on the computer.

I only wish it didn't take so much work to author these SVCD's to DVD. I have to:

1. rip to hd using ISOBuster
2. demultiplex with TMPGEnc
3. run the elementary video streams through DoPulldown, creating yet another copy of the video on my hd!

So, each 800 Mb SVCD ends up taking up 2400 Mb on my hd before I can even begin the authoring process!

If only I could rip the SVCD directly to elementary streams...
or
If only there was a program which could do pulldown on program streams...preferably modifying the original instead of creating a new file...like the way DVDPatcher works on sequence headers...

[I_AM_CANADIAN]

This topic is similar to one Ive been banging my head on for many days. Adam, I think you may be able to help me based on your original reply to this post, Posted: Apr 30, 2004 05:10.

Heres my question, originally posted here, but no replys! https://www.videohelp.com/forum/viewtopic.php?t=218935&highlight=

Anyways, my questions:

I use vStrip, DVD2AVI and TMPGEnc Plus. All my DVD's ripped are Progressive 29.97fps, which I dont know if is normal? When a encode to SVCD, am I suppose to encode interlaced or non-interlaced? Im just looking for the best format that will work on the majority of at-home DVD players.

Also, it seems to me that if you want it non-interlaced, it seems there are 2 ways to this: a) use Force Film in DVD2AVI, or b) use the 3:2 pulldown in TMPGEnc ... is this correct?

I hope you can help me!
Thanks, Brennan

[mazinz]

WOW, i think its fate that i just happen to see this post now. I am going insane trying to fix a problem and this post describes it. In my case i have a ripped dvd (backup obviously), and i have some raw mpeg2 clips. The dvd is optically censored so i was just going to put the uncensored footage in its place and remake the whole stream with mpeg2vcr. But it seems that the uncensored footage was in a different field base. The dvd said top, my stuff said bottom. to add more misery vob_01_2 of the same title claimed that the bottom field was being used!!!!

Either way each time tried this, the footage i added came up jerky on the homedecks, but smooth on the pc.

I then ended up telling tmpg (after doing various other test) that the source was progressive. I did a quick edit with womble and everything played smooth on the homedeck. So now im trying to get all the footage back into the film and im still having the same issue as before.

I guess i wll try Resteeam and see what that tells me. This is driving me nuts

[LisaB]

I_AM_CANADIAN,

if dvd2avi says your source is FILM, then definately use ForceFilm in DVD2AVI when you create your d2v file...this way, tmpgenc only sees the progressive frames. ff is more reliable than tmpgenc.