Help deinterlacing/IVTC'ing VHS material converted years ago from film

[Mini-Me]

I have a lot of VHS home videos, but there are actually 3 of my mom's that were originally converted from film, probably before I was born. I'm not sure what the original film format was. It might have been standard 8mm, it might have been Super 8, or it might even be something entirely different.

Anyway, I captured these from NTSC VHS, so they're interlaced. I'm trying to get the original progressive frames, but IVTC and telecide aren't working right in Virtualdub. I could be misusing the filters, but I'm wondering if it's because they weren't necessarily recorded at 24fps. Apparently, 8mm film could be filmed at 12, 15, 16, and 18 frames per second, and for all I know, different film could have been used for different scenes. Therefore, the pulldown in the VHS could be practically anything.

Generally speaking, the film seems to follow this pattern:
Fields: 1t, 1b, 2t, 2b, 3t, 3b (where the number indicates the apparent original progressive frame, and t/b indicates top/bottom)
Frames: 1t1b, 2t1b, 2t2b, 3t2b, 3t3b...
Therefore, I generally seem to get a pattern of alternating interlaced and progressive frames.

However, sometimes this pattern gets messed up, and there will be two interlaced frames in a row, or a series of frames that seem to alternate between regular interlaced and very, very interlaced (as if some frames contain fields that are a couple frames apart).

Does anyone have any advice for sorting this out?

[jagabo]

For each section:

AssumeTFF() or AssumeBFF()
TFM()
TDecimate(mode=2, rate=?)

Of course, that will leave you with a bunch of clips of different frame rates.

[Mini-Me]

That definitely started me down the right path. I'm ignoring decimating until I can get it right, and I'm using PP=0 for TFM so I can see whatever combing is still there (instead of it being deinterlaced).

I've set TFM to mode=5 for the strongest matching, but it still only does the job halfway: The reason is, the field order seems to be changing in the middle of the scene. More accurately, it's like the field order is oscillating: The TFM filter will be doing pretty well for a series of frames, and then combing will start gradually appearing in the next few frames, and then the combing will get really strong, then recede, and then the filter will do great again. When I switch the field order, the "polarity" of this cycle reverses, i.e. frames with combing in TFF mode are progressive in BFF mode. I haven't timed the cycle exactly or even roughly though.

The transfer from film to VHS was obviously done in real-time, so the oscillations seem to be coming from that. I don't know how to deal with them, though...


Ideas?

[jagabo]

Can you post a sample?

[Mini-Me]

Can you post a sample?

Yes. I know just the scene to use. I've never done it before though: What should I use for hosting, and what format should I encode to?

EDIT: For now, I'm just uploading a 10-second, 66-MB Huffy sample to filefactory...I'll post the link in a few minutes when it's done.

UPDATE: Here is the link:
http://www.filefactory.com/file/b4ce99b/n/WeddingFramerateSample.avi

Note the man walking in front of the camera, then walking back the other way. With TFF, TFM(mode=5, PP=0) will show mostly progressive frames when he's walking one way and combing when he's walking the other way. With BFF, it will be the other way around. If you use PP=1 and an output file, it will return TONS of combed frames and potentially combed frames.

Let me know if you want a longer clip to try sniffing out a pattern with.

[Mini-Me]

OOOOOH.

I just got a MASSIVE improvement by running TFM twice in a row: First I ran it with the top field first, and then I ran it with the bottom field first. Only 13/300 frames were reported as definitely still being combed...which is a looooot better than before.

[manono]

The framerate's 16fps (15.982fps, actually). You can try:

AssumeTFF()
TFM()
TDecimate(Mode=0,Cycle=30,CycleR=14)

But, because of the presence of field blends and all those 'warped' frames, I had somewhat better luck using SRestore:

Yadif(Order=1,Mode=1)
SRestore(FRate=15.982)

And because the decimation to 15.982 isn't perfect and some frames wind up getting lost, you might want to set the framerate a bit higher and put up with some duplicate frames. And don't be afraid to use TIVTC's post processor (deinterlacer) on those frames that don't get matched up properly. It's a good deinterlacer and your source is pretty messed up.

[Mini-Me]

The framerate's 16fps (15.982fps, actually). You can try:

AssumeTFF()
TFM()
TDecimate(Mode=0,Cycle=30,CycleR=14)

But, because of the presence of field blends and all those 'warped' frames, I had somewhat better luck using SRestore:

Yadif(Order=1,Mode=1)
SRestore(FRate=15.982)

And because the decimation to 15.982 isn't perfect and some frames wind up getting lost, you might want to set the framerate a bit higher and put up with some duplicate frames. And don't be afraid to use TIVTC's post processor (deinterlacer) on those frames that don't get matched up properly. It's a good deinterlacer and your source is pretty messed up.

Thanks for the reply. Exactly how did you determine that the framerate should be 15.982 though, and how sure are you?

Interestingly enough, running TFM three times in a row with alternating fields results in fully progressive output! Some frames are repeated once, some are repeated twice, and the first frame of the sample is repeated 3 times. As it turns out, there are only 153 unique frames in the sample clip, assuming TFM didn't throw any source frames out by mistake. That would mean that the framerate is closer to 15 FPS than 16 FPS. Running TDecimate(mode=1) brings the clip down to 153 frames as well, with no duplicates. Running TDecimate in several other ways (14 in 30, 112 in 240, or mode 4 then mode 2 with metrics file) gives me a 160-frame result with 7 duplicates. However, that's only because those modes essentially dictate ahead of time that the framerate should be 16 (or 15.982/15.984) FPS.

When I run TDecimate(mode=1) three times on the whole two hour movie (after three TFM's), it similarly gives me a clip that would run at just about 15.34 FPS, assuming the original video's runtime was correct in the first place.

It seems there are three possibilities here:

• My clip was filmed as 15 FPS, and the VHS transfer resulted in a bit of a speedup.
• My clip was filmed at 16 (or 15.982/15.984) FPS, and the VHS transfer resulted in a larger slowdown (by about twice as much).
• My clip was filmed at 16 (or 15.982/15.984) FPS, and all of the source frames are present in the VHS transfer, but TFM is throwing out about 4.375% of the frames or so.

What's the best way to determine which is the case?

[jagabo]

I agree the blending in the video means SRestore() will work better than TDecimate(). I think the frame rate is closer to 15 than 16. I assumed Mini-Me's 153 unique frames was right then used 30000 / 1001 * 153 / 300 to get 15.285. The following script works pretty well:

ffmpegSource2("WeddingFramerateSample.avi")
AssumeTFF()
Yadif(order=1,mode=1)
SRestore(15.285)

The version of HuffYUV I'm using is crashing if I use AviSource() so I used ffmpegSource2().

[Mini-Me]

Thanks for the continued help, guys. I can't get Yadif to work without an error (it's in my plugin directory and everything), so I can't check that for comparison, but the following overcomes the insanity of the interlacing and gives a series of only progressive frames:

Avisource("WeddingFramerateSample.avi")
# Match fields:
AssumeTFF()
TFM(field = 1, mode = 5, PP = 1)
TFM(field = 0, mode = 5, PP = 1)
TFM(field = 1, mode = 5, PP = 1)

The only thing I'm uncertain of at this point is exactly how to decimate. It seems that I eliminate almost all duplicates with three rounds of TDecimate(mode=1), without eliminating non-duplicates, but then the framerate is ~15.3. It would seem as though that's the real framerate of the source, yet I can't help but think that it should be 16 (or 15.982/15.984), and TFM is just skipping over some of the source frames. Is that possible? Under certain circumstances, will TFM skip?

[jagabo]

Yadif is a special case. It doesn't auto load like other filters. You have to use:

Load_Stdcall_plugin("C:\Program Files\AviSynth 2.5\plugins\yadif.dll")

I have that in an AVSI file so it automatically loads every time an AVS script is opened.

After your triple TFM() script (I don't really understand why it works) try TDecimate(mode=7, rate=15.285). Or whatever rate you think is right.

[Mini-Me]

Yadif is a special case. It doesn't auto load like other filters. You have to use:

Load_Stdcall_plugin("C:\Program Files\AviSynth 2.5\plugins\yadif.dll")

I have that in an AVSI file so it automatically loads every time an AVS script is opened.

[/QUOTE]
Ahhh...that would be why. Thanks!

After your triple TFM() script (I don't really understand why it works) try TDecimate(mode=7, rate=15.285). Or whatever rate you think is right.

Hehe...that's the hard part of course, figuring out what rate is right. The story seems to be a bit different when it comes to the whole video vs. the 10 second sample.

I don't know exactly why multiple TFM calls (with alternating fields) work either, but I have a hazy idea, which is why I thought of it in the first place: The effectiveness of TFM seems to phase in and out throughout the video, and depending on whether you seek matches for the top field (field = 1) or bottom field (field = 0), it will be effective at opposite times. After swapping back and forth and getting frustrated, I just tried doing one after another...and miraculously, it actually worked. Doing two alternating calls in a row leaves just a few minor combed frames, and the third call cleans up the rest...a fourth doesn't seem to do much, since there's nothing left to do.

[jagabo]

I don't know exactly why multiple TFM calls (with alternating fields) work either, but I have a hazy idea, which is why I thought of it in the first place: The effectiveness of TFM seems to phase in and out throughout the video, and depending on whether you seek matches for the top field (field = 1) or bottom field (field = 0)

I guess the blended fields are confusing it. By using TFM with alternating field orders you're essentially matching the least blended fields with the nearest neighboring least blended field. In the end weeding out all the blended fields.

[Mini-Me]

That sounds about right.

Onto the next step though: I have two target formats, computer files and DVD. The files will stay progressive (thank God), but I'm ironically going to have to re-telecine the movie in some manner to get it back on DVD. For the progressive copy, I've tentatively decided to decimate to 15.984 FPS. My best guess for DVD conversion is to hard-telecine a 44433444 field pattern, which will create 30 fields out of 8 frames (and repeating it will create a full second of 60 fields out of 16 frames). Do you know what program, Avisynth filter, or Vdub plugin I can use to do this?

[jagabo]

AviSynth can do that. But I'd just slow the frame rate down to 14.985 fps, duplicate each frame, then encode at 29.97 fps.

AssumeFPS(14.985)
ChangeFPS(29.97)

You could try doubling the frame rate with motion interpolation. I think you'll find it gives too many artifacts though. Sample attached.

#discussion: http://forums.guru3d.com/showthread.php?t=288017

function DoubleFPS2(clip source)
{
super = MSuper(source, pel=2, hpad=0, vpad=0, rfilter=4)
backward_1 = MAnalyse(super, chroma=false, isb=true, blksize=16, searchparam=3, plevel=0, search=3, badrange=(-24))
forward_1 = MAnalyse(super, chroma=false, isb=false, blksize=16, searchparam=3, plevel=0, search=3, badrange=(-24))
backward_2 = MRecalculate(super, chroma=false, backward_1, blksize=8, searchparam=1, search=3)
forward_2 = MRecalculate(super, chroma=false, forward_1, blksize=8, searchparam=1, search=3)
backward_3 = MRecalculate(super, chroma=false, backward_2, blksize=4, searchparam=0, search=3)
forward_3 = MRecalculate(super, chroma=false, forward_2, blksize=4, searchparam=0, search=3)
MBlockFps(source, super, backward_3, forward_3, num=2*FramerateNumerator(source), den=FramerateDenominator(source), mode=0)
}

[manono]

Exactly how did you determine that the framerate should be 15.982 though, and how sure are you?

Use TFM alone or SRestore set for 29.97fps output. Count the average number of duplicate frames in every 30 frames. The remaining number of unique frames is the framerate. That's one way. And jagabo's right - I didn't do enough counting and the framerate's less than 16. I'm getting 15.318 this time (in every 30 frame cycle, done 3 times there are 15 dupes twice and 14 once (in a 90 frame cycle there are 44 dupes), or:

Yadif(Order=1,Mode=1)
SRestore(FRate=15.318)

But there weren't enough frames in the sample for me to be absolutely positive (no, don't upload more ). You can't hard telecine such a low framerate without introducing duplicate frames in addition to the dupe fields. Plus, all that interlacing drains the available bits and isn't very compression efficient. For DVD I'd also do it as jagabo suggested and keep it fully progressive, with a ChangeFPS command either on the 15.318fps video or, for absolute smoothness, by slowing it first to 14.985fps.

Another way is to introduce light blending to bring it to 19.98fps, also progressive, and then to encode for DVD with 19.98->29.97fps pulldown afterwards:

Yadif(Order=1,Mode=1)
SRestore(FRate=15.318)
BlendFPS(19.98,aperture = 0.4)

It uses the Motion.dll and introduces 4 or 5 blended frames per second. That's more than is optimal, though. I've done it myself with good results using 18fps material, and a good silent film company, Flicker Alley, uses a similar method on some of its retail DVDs. Here's a DVD compliant sample:

[Mini-Me]

Thanks, guys. After analyzing some more clips, it turns out that the 15.2847 FPS framerate is almost certainly correct. It may or may not have been filmed at 15 flat, or even 16, but it must have been played back at 15.2847 FPS during capture from film to VHS. I'm not sure what the exact cycle length is, but almost every 300 frame sample includes 153 progressive source frames. Occasionally a window of 300 VHS frames might have 154 film frames (and maybe 152), but I think those are just fence-post issues of sorts.

Now that I'm confident about the framerate, I agree with both of you guys about the best option:

• Restore progressive frames and eliminate blended frames with TFM (twice/three times )
• Decimate to 15.2847 FPS. I haven't really learned how to configure srestore yet, but TDecimate seems to work perfectly in mode 0, removing the most similar 147 out of every 300 frames. The long cycle length seems appropriate, since the frequency of the "blended frames wave" seems so low. Heck, it might even be better to go longer, but whatever.
• Slow the framerate to 14.985 FPS (keeping the same frames).
• Either duplicate each frame once for DVD or possibly double the framerate with motion interpolation (iffy).

The DVD standard wouldn't include a way to "soft-duplicate" the frames, would it? It'd be nice to double to effective bitrate, but I get the feeling I'll have to hard-duplicate the frames (assuming I don't go with motion interpolation).

[jagabo]

The DVD standard wouldn't include a way to "soft-duplicate" the frames, would it?

No. The most you can go with pulldown flags is 1.5 times the frame rate. So you'd have to speed your video up to 19.98 fps and use 3:3 pulldown flags. I'd give it a try but that much of a speedup might not be acceptable.

It'd be nice to double to effective bitrate, but I get the feeling I'll have to hard-duplicate the frames (assuming I don't go with motion interpolation).

Duplicate frames don't cost much.

[manono]

If you check out my sample, I kept it the same length but added a few blends to bring the framerate up to 19.98fps, after which I applied 3:3 pulldown. I'm not saying I recommend doing it that way necessarily, but it allows you to keep it at the same speed and the audio doesn't have to be stretched. I don't think actually speeding it up to 19.98fps (AssumeFPS(19.98)) is a viable solution.

[Mini-Me]

If you check out my sample, I kept it the same length but added a few blends to bring the framerate up to 19.98fps, after which I applied 3:3 pulldown. I'm not saying I recommend doing it that way necessarily, but it allows you to keep it at the same speed and the audio doesn't have to be stretched. I don't think actually speeding it up to 19.98fps (AssumeFPS(19.98)) is a viable solution.

I agree that speeding up to 19.98 FPS and applying 3:3 pulldown is not viable. For one thing, the speedup would be too large and result in unrealistic motion. Plus, the 3:3 pulldown would unnecessarily reintroduce dirty frames on playback, whereas a mild slowdown to 14.985 FPS would keep fully progressive (fake interlaced) playback for modern HDTV's. If duplicate frames don't cost much in terms of bitrate, there seems to be no reason whatsoever to pick 19.98 FPS and 3:3 pulldown over 14.985 FPS and doubled-up frames.

I'm not a fan of reblending either though. If I really wanted the smoothest possible motion even at the expense of combing, I might have just left the VHS capture as it was. After going through all that trouble to get rid of combing and blended frames and restore the original film frames, the last thing I want to do is start blending everything together all over again.

It's probably best to keep playback speed close to the VHS, but I don't think it's reasonable to make large sacrifices just to maintain the exact same speed either. Common 8mm film formats are 12, 15, 16, and 18 FPS. That is to say, the movies could have been filmed at either 15 or 16 FPS...or maybe even somewhere in between, if the equipment was inexact. It seems they were captured from film to VHS at 15.2847 FPS, but I have no guarantee that they weren't filmed at a slightly different rate anyway. Without such a guarantee, reblending fields just to maintain the exact same playback rate seems a little silly, since that playback rate may be slightly incorrect in the first place (in either direction).

Instead, I'd much rather keep the frames as clean as possible. I now have one and only one of each progressive frame (or so it seems), so slowing down to 14.985 FPS and duplicating frames seems by far the cleanest solution. As long as the motion seems realistic, I have no way of knowing the slowdown isn't actually a correction back to the original framerate. Audio sync is a non-issue, since it's a silent movie, and the entire audio track is just hiss anyway.

[manono]

Plus, the 3:3 pulldown would unnecessarily reintroduce dirty frames on playback, whereas a mild slowdown to 14.985 FPS would keep fully progressive (fake interlaced) playback for modern HDTV's.

I can't argue with your decision to slow it to 14.985fps and then repeat each frame. Assuming the slowdown isn't too much and movement is natural looking, as it probably will be. However, I'm not entirely sure what you mean by 'reintroduce dirty frames'. At 14.985 doubled to 29.97fps, each frame gets played 4 times (4 4 4 4 4) for smooth playback on a 59.94Hz hi-def TV set. At 19.98fps with 3:3 pulldown, each frame gets played 3 times (3 3 3 3 3), also for smooth playback. I'm not sure where the reintroduction of 'dirty frames' takes place, or even what a 'dirty frame' is.

Both methods result in smooth playback and will be noticeably smoother playing than traditional 23.976fps film played back in the usual 3 2 3 2 3 2 pattern.

[Mini-Me]

I can't argue with your decision to slow it to 14.985fps and then repeat each frame. Assuming the slowdown isn't too much and movement is natural looking, as it probably will be. However, I'm not entirely sure what you mean by 'reintroduce dirty frames'. At 14.985 doubled to 29.97fps, each frame gets played 4 times (4 4 4 4 4) for smooth playback on a 59.94Hz hi-def TV set. At 19.98fps with 3:3 pulldown, each frame gets played 3 times (3 3 3 3 3), also for smooth playback. I'm not sure where the reintroduction of 'dirty frames' takes place, or even what a 'dirty frame' is.

Both methods result in smooth playback and will be noticeably smoother playing than traditional 23.976fps film played back in the usual 3 2 3 2 3 2 pattern.

At 19.98 FPS with 3:3 pulldown, each frame is not displayed 3 times. If it were, we'd end up with a framerate of 59.94[p] instead of 29.97, which is what we need. Instead, 3:3 pulldown means each frame has one field selected from it 3 times. Let's say you have frames A, B, C, and D, and you perform 3:3 pulldown to multiply the framerate of 19.98 FPS by 1.5 to achieve 29.97 FPS. I'll list the output frame, source frame for the top field, and source frame for the bottom field:

Output frame 1: Top field is from A, bottom field is from A.
Output frame 2: Top field is from A, bottom field is from B.
Output frame 3: Top field is from B, bottom field is from B.
Output frame 4: Top field is from C, bottom field is from C.
Output frame 5: Top field is from C, bottom field is from D.
Output frame 6: Top field is from D, bottom field is from D.

In every group of three frames, the middle frame will be "dirty," in the sense that it will contain fields from different frames. Progressive displays will have to do their best to deinterlace such frames. This is actually very similar to the dirty frames in 2:3 pulldown (here's Wikipedia's diagram), and it might even have a hint of judder.

In contrast, 14.985 FPS means each frame is displayed exactly twice. It does have a 4:4 pulldown pattern, but the 4's refer to the number of times each frame has a field taken from it. (Output frame 1 has the top and bottom fields from source frame A, and so does output frame 2. Output frame 3 has the top and bottom fields from source frame B, and so does output frame 4.)

[manono]

You should know what you're talking about before lecturing people. Most of what you wrote is utter nonsense. I told you I can't object to you doing it for 14.985 doubled, but the reasons you gave for not doing it at 19.98fps are misguided at best.

If it were, we'd end up with a framerate of 59.94[p] instead of 29.97, which is what we need.

You brought up 'modern HDTVs', so I was assuming you have a Hi-Def TV set, one that plays frames (not fields) and one that's 59.94Hz, and not 120 or 240Hz. So, all that field explanation goes out the window. Your output framerate is 59.94 frames per second. With an old-fashioned CRT TV set, it's 59.94 fields per second. A progressive display plays full frames. So, a 19.98fps video outputs each unique frame three times so the output framerate is 59.94 frames per second. Your 14.985 video has each frame repeated so it's stored on DVD at 29.97fps, and each unique frame is therefore played 4 times at 59.94fps to a progressive display at 59.94Hz. Yes, DVD players output 59.94 fields per second, but with progressive scan turned on those fields are reassembled into their component frames and then output at 59.94 frames per second.

With standard 23.976fps movies, what do you think the 3:2 means for a progressive display? One unique frame is repeated 3 times, the next twice, the next 3 times, the next twice, and so on. In a second of video this 3/2 cycle is repeated 12 times for 60 frames per second (actually 59.94 frames in a second). That's why that 3:3 pulldown one (with some allowance for the blended frames I created for your video) and your doubled 14.985fps videos will play with absolute smoothness, more smoothly than regular movies with 3:2 pulldown.

In every group of three frames, the middle frame will be "dirty," in the sense that it will contain fields from different frames. Progressive displays will have to do their best to deinterlace such frames.

There shouldn't be any deinterlacing at all going on, not for 3:3 pulldown, not for 3:2 pulldown, not for anything progressive. 3:3 pulldown doesn't add any judder at all; 3:2 pulldown definitely does. And if you have a decent DVD player, and let it do the 'heavy lifting', the display doesn't do anything at all except output the frames sent to it by the player. It won't have to deinterlace or anything else. I have a good player, so everything gets done by it.

[Mini-Me]

You should know what you're talking about before lecturing people. Most of what you wrote is utter nonsense. I told you I can't object to you doing it for 14.985 doubled, but the reasons you gave for not doing it at 19.98fps are misguided at best.

I'm sorry if I came off as lecturing or condescending. You're far more knowledgeable about video than I am for sure, but I was thinking [mistakenly] that you were momentarily confusing pulldown issues, so I tried to lay out my thinking as clearly as possible. I really didn't mean to sound patronizing or anything, and I'm sorry that I did.

I do think you're being a bit harsh, though. I made a mistake in my thinking, but it wasn't all nonsense...just a train of thought following from the false assumption that progressive scan DVD players were never invented. If you pretended that they really never were invented, my post would actually make sense.

You brought up 'modern HDTVs', so I was assuming you have a Hi-Def TV set, one that plays frames (not fields) and one that's 59.94Hz, and not 120 or 240Hz. So, all that field explanation goes out the window. Your output framerate is 59.94 frames per second. With an old-fashioned CRT TV set, it's 59.94 fields per second. A progressive display plays full frames. So, a 19.98fps video outputs each unique frame three times so the output framerate is 59.94 frames per second. Your 14.985 video has each frame repeated so it's stored on DVD at 29.97fps, and each unique frame is therefore played 4 times at 59.94fps to a progressive display at 59.94Hz. Yes, DVD players output 59.94 fields per second, but with progressive scan turned on those fields are reassembled into their component frames and then output at 59.94 frames per second.

You're right. When DVD players send out an interlaced signal, they perform pulldown on individual fields as I was saying before, but I never considered how progressive scan DVD players changed this and can actually perform pulldown on full frames.

With standard 23.976fps movies, what do you think the 3:2 means for a progressive display? One unique frame is repeated 3 times, the next twice, the next 3 times, the next twice, and so on. In a second of video this 3/2 cycle is repeated 12 times for 60 frames per second (actually 59.94 frames in a second). That's why that 3:3 pulldown one (with some allowance for the blended frames I created for your video) and your doubled 14.985fps videos will play with absolute smoothness, more smoothly than regular movies with 3:2 pulldown.

Right. I was still thinking in terms of old school DVD players sending out 29.97 FPS (with 3:2 pulldown of individual fields), with the assumption that a newer progressive display would simply display each of those frames twice (unless the HDTV had its own fancy processor built in). In that case, there would be "dirty" frames in addition to judder, as shown in the Wikipedia diagram. As far as I know, this is still how an old non-progressive DVD player and new HDTV would interoperate though.

There shouldn't be any deinterlacing at all going on, not for 3:3 pulldown, not for 3:2 pulldown, not for anything progressive. 3:3 pulldown doesn't add any judder at all; 3:2 pulldown definitely does. And if you have a decent DVD player, and let it do the 'heavy lifting', the display doesn't do anything at all except output the frames sent to it by the player. It won't have to deinterlace or anything else. I have a good player, so everything gets done by it.

With respect to 3:3 pulldown and judder, I still think there might be a slight bit if you use a non-progressive DVD player though. On such a player, the player would output the pattern I wrote in my previous post, and the repeated series of two clean frames followed by one dirty frame (referring to frames 3, 4, and 5) might result in some unevenness. As you pointed out though, it's a moot point for progressive scan players, since there won't be any dirty frames in the first place, and each frame will actually be repeated 3 full times.

All that said...a properly working progressive scan DVD player is the best case scenario. It's been a while since I've seen them, but according to HQV benchmarks and DVD player reviews, a lot of poor progressive scan and upscaling DVD players screw up certain pulldown patterns anyway. They end up outputting interlaced frames when they shouldn't. I may be mistaken, but IIRC the Xbox 360 is among them (that said, I think the 360 is only unable to detect the right cadence on improperly flagged content). Of course, that may not be commonly used as a DVD player or anything, but it's not the only bad one either.

[jagabo]

Some additional information that may help:

Keep in mind that the MPEG2 and DVD specs were put together when players were expected to be very dumb devices. They were designed to put out one thing: 59.94 fields per second interlaced video. They weren't expected to figure out how convert progressively encoded frames to 59.94 fields per second on their own. 59.94 fields per second is the only thing that old style interlaced TVs could display. Those TVs wouldn't know what to do with a "frame" of video if you gave it to them.

An analog interlaced signal (what travels over a composite or s-video cable, or old style analog broadcast) is a series of fields, not frames, 59.94 fields per second. When you see these on an interlaced display you see one field at a time. On interlaced TV you never see an entire frame. Fields always alternate top, bottom, top, bottom...

If you encode progressive with pulldown flags the frames remain progressive. The pulldown flags are simply a few bits per frame that tell the DVD player how to produce 59.94 fields per second from those frames.

When putting out an interlaced signal (RF, composite, s-video interlaced component) the player just follows the pulldown instructions to produce the 59.94 fields per second output. There are no "dirty" (I assume you mean frames with one field from one frame and another field from another frame, ie, an interlaced frame) frames because there are no frames in the signal, only fields.

When putting out a progressive signal (progressive component, DVI, HDMI) the DVD player uses those flags only to determine the length of time each frame should be displayed. With 59.94 Hz output and 23.976 fps progressive frames 3:2 pulldown flags tell the player to display some frames for 3/59.94 second, others for 2/59.94 second. So frames are repeated 3 times or 2 times. No "dirty" frames are sent to the TV.

If you encode at 19.98 fps progressive with 3:3 pulldown flags, a player putting out a 59.94 fps progressive signal will repeat each frame 3 times, no "dirty" frames. When putting out an interlaced signal each frame is sent as a sequence of 3 fields -- no dirty frames because the signal doesn't contain frames. There is some question about what a progressive TV might do with those fields. They have to be turned into progressive frame to be displayed. Many of them will simply "bob" the signal -- fill all the empty scanlines of each field with data interpolated from the scan lines above and below. Others will try to be smart and restore the original film frames -- joining two fields together to produce a frame. Since they are expecting normal 3:2 pulldown and you are sending 3:3 pulldown they may get confused and display some "dirty" (interlaced) frames. Whether that happens or not depends on how smart the TV is. This is a large part of what the HQV benchmark tests -- the ability of the TV to recognize various different pulldown patterns and display proper progressive frames.

[lordsmurf]

This has been a useful thread.

I'd never thought of stacking TFM. But that works quite well for old 8mm converted to VHS.

TFM(field = 1, mode = 5, PP = 1)
TFM(field = 0, mode = 5, PP = 1)
TFM(field = 1, mode = 5, PP = 1)