interlaced PAL problem

[PAL sucks]

I have a PAL dvd and the extras have a pattern of 9 progressive 12 interlaced frames at 25fps. I am using:
TFM(d2v="*.d2v")
TDecimate(cycle=25)
and this seems to give me 24fps progressive when I step through it. What pattern is this and is there a better way of dealing with it? (The audio seemed to be too slow when slowing it down with pp=0 to 23.976 so it seems like this is right.)

Also, I have found a way of using PAL menu subpics for a NTSC conversion besides just moving them up with dvdsubedit. From what I read it seems no one can do this successfully yet I found it very easy to do importing a resized external sub-pic bmp with dvdlab pro. I can add further info if this is new to someone who wants to convert PAL menus to NTSC. (This was a motion menu btw.)

And another thing I think I noticed is some aliasing after running a progressive video through dgpulldown when on regular dvds I don't see this (when they are progressive also). Am I being paranoid,could this be a result of reencoding mpeg2 or is dgpulldown wrong about doing what it does?

[jagabo]

Are you sure it's exactly 9 progressive frames and 12 interlaced frames? One method of converting 24p to 25i is to duplicate one field every 12 frames, ie 2:2:2:2:2:2:2:2:2:2:2:3 pulldown. 12 frames becomes 25 fields, 24 frames becomes 50 fields. 23.976p to 25i is similar but every 500 fields another duplicate is added.

DgPulldown doesn't create any aliasing. What probably happening is the program you are using to view the resulting video is performing the pulldown before displaying it to you. VirtualDub does this for instance.

[manono]

What pattern is this and is there a better way of dealing with it?

If you can't figure it out then neither can anyone else without a sample, so we can also see what you're seeing.

The audio seemed to be too slow when slowing it down with pp=0 to 23.976

The post processing has nothing to do with the framerate, and you wouldn't be able to tell the difference in the audio played at 24fps as compared to slowing it to 23.976fps.

From what I read it seems no one can do this successfully

Don't kid yourself.

...could this be a result of reencoding mpeg2 or is dgpulldown wrong about doing what it does?

As jagabo said, DGPulldown doesn't create any aliasing.

[PAL sucks]

http://www.mediafire.com/?9h9ew6kw29r6j2f

This sample might be too short but I didn't want the file to be too big. I could swear the progressive to interlaced pattern is changing depending on the demux, this is a different demux of the original pgc (pgcdemux) with dgindex cutting out of the middle this clip. Would that make a difference with how it is indexed? Would interlacing alternate just because of the way it's displayed with software and avisynth? It says 25fps in dgindex. pp=0 gave me 1 repeat every 25 frames, I think, and that's why I put that cycle25 in there and that seemed to give me 24 sequential progressive frames.

The post processing has nothing to do with the framerate, and you wouldn't be able to tell the difference in the audio played at 24fps as compared to slowing it to 23.976fps.

That is pp=0 (still 25fps) with assumefps ntsc_film after. I stretched the audio with a 24000/1001 / 25 ratio and keeping pitch since it was already at the right pitch. The main movie was pitch corrected but definitely progressive PAL so I thought this was the same but the tempo seems too slow compared with the soundtrack.

DgPulldown doesn't create any aliasing. What probably happening is the program you are using to view the resulting video is performing the pulldown before displaying it to you. VirtualDub does this for instance.

It might be the Vizio high def with a sd player attached to component setup. When I fast forward, I really see it but I have to try it again with a factory progressive dvd to make sure they don't look like that too. It might just be the lack of resolution, which is what I was hoping someone would say. It could be crappy mpeg decoding of the cheap player.

Don't kid yourself.

Well I read a bunch of threads (most up to 7 years old, some recent) about this trying to find a way to do it and everybody was saying "it's better to forget about it because it's too hard" but it was pretty easy to do once you figure out how to tweak the bmp so dvdlab uses it right.

[jagabo]

The sample video is like I described earlier. I can't tell if it should be 24 fps or 23.976 fps.

[PAL sucks]

Could it(aliasing) be my cce settings? Open GOPS, 3/4, top field first, offset line 0, 10 bits DC (zigzag/progressive).

[PAL sucks]

The sample video is like I described earlier. I can't tell if it should be 24 fps or 23.976 fps.

It was long enough though? I have to think about what you wrote earlier (what would the pattern be?). From what I'm seeing there is no set pattern of p/i. A later clip in the multipgc title has a different pattern and that clip has a different pattern than what I saw yesterday.

[jagabo]

Open it with AviSynth and apply AssumeTFF().Bob(). You'll see two repeats of each film frame (ie two fielsds). Except every 12th frame you will get three repeats. Ie, 12 frames becomes 25 fields, 24 frames becomes 50 fields. From the short sample you can't tell for sure if it's 23.976 fps or 24 fps.

[PAL sucks]

Are you sure it's exactly 9 progressive frames and 12 interlaced frames? One method of converting 24p to 25i is to duplicate one field every 12 frames, ie 2:2:2:2:2:2:2:2:2:2:2:3 pulldown. 12 frames becomes 25 fields, 24 frames becomes 50 fields.

Would that read as 50fps in dgindex? This says 25i (or it was converted to that?).

[manono]

As jagabo speculated, you don't count so well. Yes, it's one fairly rare way used to convert film to PAL and your original script works well on it.

Would that make a difference with how it is indexed?

No.

That is pp=0 (still 25fps) with assumefps ntsc_film

I was mixing up TIVTC's PP with Decomb's Post, which control the post processing (deinterlacing of remaining interlaced frames) for the respective IVTC filters. I can find no mention of PP in Decomb. What's it do? It's your assumefps ntsc_film that's changing the framerate. In my opinion it changes it so little as to not be worth it. In addition, after doing it, reencoding of the audio is required. I'd suggest just leaving it at 24fps and applying DGPulldown afterwards for 24->29.97.

Well I read a bunch of threads (most up to 7 years old, some recent) about this trying to find a way to do it

To use the original PAL menu subpics in an NTSC DVD? Extract them, resize them for NTSC, and reauthor the menus. None of that is very difficult.

[manono]

Are you sure it's exactly 9 progressive frames and 12 interlaced frames? One method of converting 24p to 25i is to duplicate one field every 12 frames, ie 2:2:2:2:2:2:2:2:2:2:2:3 pulldown. 12 frames becomes 25 fields, 24 frames becomes 50 fields.

Would that read as 50fps in dgindex? This says 25i (or it was converted to that?).

No, it's 25 frames per second, but also 50 fields per second. DGIndex shows the frames per second.

[PAL sucks]

Open it with AviSynth and apply AssumeTFF().Bob(). You'll see two repeats of each film frame (ie two fielsds). Except every 12th frame you will get three repeats. Ie, 12 frames becomes 25 fields, 24 frames becomes 50 fields. From the short sample you can't tell for sure if it's 23.976 fps or 24 fps.

This is what I'm getting. (Were you asking me to do that for me or you to be able to tell what's going on here with the interlacing?)

[PAL sucks]

No, it's 25 frames per second, but also 50 fields per second. DGIndex shows the frames per second.

Oops, that's right. I got it straight now.

[PAL sucks]

As jagabo speculated, you don't count so well. Yes, it's one fairly rare way used to convert film to PAL and your original script works well on it.

I was mixing up TIVTC's PP with Decomb's Post, which control the post processing (deinterlacing of remaining interlaced frames) for the respective IVTC filters. I can find no mention of PP in Decomb. What's it do? It's your assumefps ntsc_film that's changing the framerate. In my opinion it changes it so little as to not be worth it. In addition, after doing it, reencoding of the audio is required. I'd suggest just leaving it at 24fps and applying DGPulldown afterwards for 24->29.97.

Now I'm mixed up. I was using TFM (TIVTC) with the pp=0 option for interlaced PAL where every frame is split so I went to slow down the audio because I was going to slow down the video too. The tempo seemed too slow for that. Then I checked the video again and noticed one duplicate every 25 so I put in TDecimate(cycle=25) and that killed the duplicate giving me 24 and the audio now stays the same (tempo is not slowed and sounds right the way it is anyway). Can you tell if this is the right thing to do from that small of a sample? Is there another test I can put the footage through to know for sure what it is?

[PAL sucks]

Are you sure it's exactly 9 progressive frames and 12 interlaced frames? One method of converting 24p to 25i is to duplicate one field every 12 frames, ie 2:2:2:2:2:2:2:2:2:2:2:3 pulldown. 12 frames becomes 25 fields, 24 frames becomes 50 fields. 23.976p to 25i is similar but every 500 fields another duplicate is added.

Ok if it's one of these it's gotta be the first, right, since I'm getting 3 repeats every twelve 2 with the bob? But
TFM(d2v="*.d2v")
gives me 24 with one repeat at 25. Although I could swear I got a couple at like 12 and 13 a couple times but this isn't happening every time.

[manono]

Now I'm mixed up.

And I'm responsible. I apologize. Without actually scrolling back up to have a look at the script I assumed you were using Decomb. But you were using TIVTC, so the original statement holds - the PP setting has nothing to do with the framerate. You know that PP=0 disables the post-processing, right?

Can you tell if this is the right thing to do from that small of a sample?

I already said your script is OK. It gives you a 24fps result. You changed the framerate though, if you added AssumeFPS("ntsc_film") (changed it to roughly 23.976fps), which then necessitates reencoding the audio.

[PAL sucks]

And I'm responsible. I apologize. Without actually scrolling back up to have a look at the script I assumed you were using Decomb. But you were using TIVTC, so the original statement holds - the PP setting has nothing to do with the framerate. You know that PP=0 disables the post-processing, right?
I already said your script is OK. It gives you a 24fps result. You changed the framerate though, if you added AssumeFPS("ntsc_film") (changed it to roughly 23.976fps), which then necessitates reencoding the audio.

Now that I thought about what you guys wrote (instead of replying first) I understand that I am dealing with 2:2:2:2:2:2:2:2:2:2:2:3 pulldown and stepping through it gave some progressive frames and some interlaced depending on which fields were paired in the display without bobbing. And am supposing that is what is being confirmed that cycle=25 is designed to ivtc that pattern.

I was using pp=0 cause I thought it might be 2222 pulldown, splitting every frame evenly which is the way manono said to deal with that in another thread somewhere around here. This is very new to me, PAL pulldown. I didn't know about the other patterns although I think I just read that is a rare form of pulldown (2:2:2:2:2:2:2:2:2:2:2:3). I am slowing it to ntsc_film cause I have a finicky panasonic player that will not play if the littlest thing is out of dvd spec and also will slow the audio by that small fraction since I am doing some other things to it anyway.

Thanks for this thread and all the other ones I found that helped me find out how to fix something, 9 times out of 10 it being something that manono wrote.

[manono]

I am slowing it to ntsc_film cause I have a finicky panasonic player that will not play if the littlest thing is out of dvd spec...

You can handle it however you like, of course, but it's well within spec, and is perfectly DVD compliant. If for some reason you're having trouble playing anything that's not standard 3:2 pulldown, I'd bet dollars to donuts you did domething wrong somewhere along the way.

[jagabo]

Are you sure it's exactly 9 progressive frames and 12 interlaced frames? One method of converting 24p to 25i is to duplicate one field every 12 frames, ie 2:2:2:2:2:2:2:2:2:2:2:3 pulldown. 12 frames becomes 25 fields, 24 frames becomes 50 fields. 23.976p to 25i is similar but every 500 fields another duplicate is added.

Ok if it's one of these it's gotta be the first, right, since I'm getting 3 repeats every twelve 2 with the bob?

23.976p to 25i is exactly the same except for every 500th field. Did you really check 500 fields? What it the missing duplicate happened to fall in a still shot. Do you think you would notice? So you'd have to look at much more that 500 fields. Probably thousands. Even if you notice a problem after examining thousands of fields, are you sure it's not because of a dropped frame? A cut after being telecined? An error on the part of TFM (it's not perfect)?

But
TFM(d2v="*.d2v")
gives me 24 with one repeat at 25. Although I could swear I got a couple at like 12 and 13 a couple times but this isn't happening every time.

Let's work it out:

Here's a sequence of broadcast fields after 2:2:2....2:3 pulldown;

1t 1b 2t 2b 3t 3b 4t 4b... 11t 11b 12t 12b 12t 13b 13t 14b... 23t 24b 24t 24b 25t 25b 26t 26b...

Note film frames 12 and 24 are repeated for 3 fields, not 2. Also note that the field sequence must always alternate between top and bottom fields. After pairing fields as frames:

1t1b - 2t2b - 3t3b - 4t4b... 11t11b - 12t12b - 12t13b - 13t14b... 23t24b - 24t24b - 25t25b - 26t26b...

Note how the first 12 frames look progressive because both fields come from the same film frame. Then the frames look interlaced for a while because pairs of fields come from different film frames. Finally, we go back to progressive looking frames as the cycle repeats itself.

Now what does TFM do? It starts with one field of a frame and tries to find the matching field. Let's say it always starts with the top field. Ie, to build progressive frames it looks at each of the top fields then tries to find a matching field from the two bottom fields that surround it. Starting with the list of frames again:

1t1b - 2t2b - 3t3b - 4t4b... 11t11b - 12t12b - 12t13b - 13t14b... 23t24b - 24t24b - 25t25b - 26t26b...

At 1t it looks at the two fields that surrounds it and sees that the field after it, 1b, is the matching field, at 2t it examines the two fields around it and sees that 2b is the matching field. When it gets to the first 12t it sees the next field 12b is the matching field. When it gets the second 12t it sees that the field before it, 12t, is the matching field. We now have one duplicate, film frame 12. When it gets to the first 23t it sees that the field before it is the matching field. When it gets 24t it pairs that with either of the 24b's that surround it. Note that there isn't another 24t, so the next field it looks at is 25t. Which gets paired with the 25b after it. Etc. So there isn't a second duplicate frame within the 25 frame cycle, just the one.

[PAL sucks]

23.976p to 25i is exactly the same except for every 500th field. Did you really check 500 fields? What it the missing duplicate happened to fall in a still shot. Do you think you would notice? So you'd have to look at much more that 500 fields. Probably thousands. Even if you notice a problem after examining thousands of fields, are you sure it's not because of a dropped frame? A cut after being telecined? An error on the part of TFM (it's not perfect)?

Since I was getting the 3 repeats every 12 fields I assume it's not the every 500 one. (Unless you're saying that the 500 one involves 3 repeats every 12 plus an additional one at 500, I don't quite understand this one). If I ever came across that I would assume it was 2:2 pulldown cause I wouldn't have the patience and besides it was only a small trailer. But now I know about it anyway and if it was a movie I might check for that if the tempo sounded fine how it was. I understood the rest before you explained but maybe someone searching would find it helpful anyway.

I am assuming that even though dgindex says interlaced (the main movie), if I don't see interlacing, it's progressive and can just be slowed down by assumefps. I just read another pal thread where you and manono were writing about these same issues and that was written.

You can handle it however you like, of course, but it's well within spec, and is perfectly DVD compliant. If for some reason you're having trouble playing anything that's not standard 3:2 pulldown, I'd bet dollars to donuts you did domething wrong somewhere along the way.

I thought I read long ago that it had to be 23.976 but I guess you're saying as long as it's pulled down to 29.97 the player is supposed to be able to read that no matter what the progressive frame rate. I bet the panasonic would reject it, it has firmware written by the dvd police. So far it rejected one where I had an illegal jump from vmg to a vts menu, it won't play smaller than 200kb menus (like the still ones produced by vobblanker), and it wouldn't play a disc I put a 16:9 menu for a letterboxed 4:3 movie on. It says err cannot play disc. Another player was happy to play all of them.

I never tried any pulldown other than from 23.976 but I always wanted to make a 24p disc so maybe I will soon.

[jagabo]

Since I was getting the 3 repeats every 12 fields I assume it's not the every 500 one. (Unless you're saying that the 500 one involves 3 repeats every 12 plus an additional one at 500, I don't quite understand this one).

The latter is what I meant. To make up for the difference between 23.976p and 24p requires that one more field be added every 500th frame. So you see the same field repeat pattern as 24p but one additional repeated field every 500th frame. If you really understood the rest of what I wrote that would have been obvious. And you wouldn't have been wondering why TFM() was giving you one duplicate frame out of every 25 frames.

Mpeg2 pulldown flags allow for any frame to repeated for up to 3 fields. So any progressive frame rate from 19.98 to 29.97 can have pulldown flags added to create the required 59.94 fields per second.

If DgIndex report a PAL video is interlaced but you see no interlace comb artifacts that means a progressive video was encoded in interlaced mode. Yes, you can just slow the frame rate with AssumeFPS(). You should also handle the interlaced chroma channels properly or you'll get screwed up colors.

[PAL sucks]

The latter is what I meant. To make up for the difference between 23.976 fps and 24 fps requires that one more field be added every 500th frame. If you really understood the rest of what I wrote that would have been obvious. And you wouldn't have been wondering why TFM() was giving you one duplicate frame out of every 25 frames.

It sort of was but I didn't want to think about it too much since I'm trying to get this disc ready to burn. I was wondering about that (TFM) last night before I thought about it hence the think before replying comment I made about my posts. It's all clear now. I'm not a video expert and it's great to be able to author a disc with the movie playing at the right speed. Usually I search for a long time to find the solution since you guys have answered these questions in the past. I should have searched about PAL pulldown although I still can't find anything about the every 500 method. Now I'm starting to want to go back and bob the whole clip. Thanks a lot.

I just found out the menu audio is sped up so I'll be able to slow that down and use all the frames without choppy playback from windvd maker.

You should also handle the interlaced chroma channels properly or you'll get screwed up colors.

Oh no, this is for other filters, right? I resized and slowed it down and it looks the same on the computer screen. I did it for another pal that reported interlaced like this one and that looked right (even using tweak on it). When I bobbed it the fields looked identical.

Edit: I just read another post by you and I think you mean this:
ConvertToYUY2(Interlaced=True)

And manono said this a few years back:

Just know that it's perfectly OK and "legal" to encode progressive material as interlaced. It's true for the vast majority of PAL DVDs. But if they are movies, you can almost bet that they're really progressive. You already saw what I'm talking about, and as you examine more and more retail PAL DVDs, you'll see it more and more often. Most PAL DVDs that are encoded as interlaced, shown to have been encoded as interlaced by such apps as DGIndex and Bit Rate Viewer, really contain progressive content.

[jagabo]

You should also handle the interlaced chroma channels properly or you'll get screwed up colors.

Oh no, this is for other filters, right? I resized and slowed it down and it looks the same on the computer screen. I did it for another pal that reported interlaced like this one and that looked right (even using tweak on it). When I bobbed it the fields looked identical.

Sorry, I wasn't thinking straight. With progressive frames encoded interlaced the difference between handling the interlaced chroma channels as interlaced vs progressive is extremely subtle in real world video. It's not worth worrying about. The real damage is done by encoding interlaced in the first place. But there's nothing you can do about that. Here's a site that describes whey interlaced encoding is bad for progressive frames:

http://www.hometheaterhifi.com/the-dvd-benchmark/179-the-chroma-upsampling-error-and-t...a-problem.html

See the section entitled "4:2:0 Interlaced: Fundamentally Broken".

[manono]

I bet the panasonic would reject it, it has firmware written by the dvd police. So far it rejected one where I had an illegal jump from vmg to a vts menu, it won't play smaller than 200kb menus (like the still ones produced by vobblanker), and it wouldn't play a disc I put a 16:9 menu for a letterboxed 4:3 movie on.

1. I bet it wouldn't reject, for example, a DVD with 25->29.97fps pulldown. The 'DVD police' would find it perfectly legal. Do you have a DVD-RW? If so I'll make you a short one for you to test.
2. An illegal jump is something else entirely. Some players can recover from something like that in one way or another. Apparently others can't.
3. I don't know anything about too-small menus, but it sounds peculiar since many retail DVDs have ones smaller than 200KB.
4. There are plenty of retail DVDs (Warner Home Video does it as a matter of course) where there are 16:9 menus for 4:3 movies.

Have you considered that your beloved Panasonic might be at fault, refusing to play 100% compliant content? Have you considered that the way you're creating these DVDs, rather than what they contain, might be at fault. You've said nothing about how you author anything, although it isn't really relevant to the main subject of this discussion