To pulldown or not to pulldown

[Xesdeeni]

Almost none of the DVD work I've done has dealt with film source, so perhaps someone can enlighten me.

I have four HD 23.976 Fps clips that I have tried to convert to DVD resolution. I used TMPGEnc and Cinema Craft Encoder to encode the clips progessively at 23.976 fps.

Using TMPGEnc set to "3:2 pulldown on playback," the videos appear to play correctly on my DVD player and interlaced NTSC TV. Freezing the videos gives me full vertical resolution, not one field. And stepping through, every frame looks great.

But CCE has no such setting. So I assumed from reading here and on DVDR.com that I had to apply pulldown.exe to the resulting progressive 23.976 Fps file, so I did. But viewing those clips shows some problems. The videos are a bit unstable, jumping up and down. I believe this is the same effect in real time as when I pause the video and step through the frames. When I do this I appear to get one or two full resolution frame, and then a frame or so with a replicated field (I can't recall the exact order).

So I'm wondering if I shouldn't have applied pulldown.exe. I'm guessing that if I had encoded the clips as 23.976 interlaced Fps, that I would have had applied pulldown.exe, but since I encoded the video progressively, I shouldn't have.

Is that right, or am I totally off base?

Xesdeeni

[int 21h]

What commandline did you use with pulldown.exe? I think most people use something like...

pulldown source.mpv target.m2v -prog_frames p

[Xesdeeni]

Ah well, I just used:

pulldown in.m2v out.m2v

Was there supposed to be an argument to enable pulldown?

Xesdeeni

[int 21h]

No, but I'm not sure what it marks your frames if you don't supply anything... I know with the above commandline it will mark all your frames as progressive (which is what you want)...

[Xesdeeni]

So you are saying that I should have run pulldown on the progressive 23.976 Fps stream. Any idea then why the video played incorrectly, then? And does the "3:2 pulldown on playback" setting in TMPGEnc do exactly the same thing?

Xesdeeni

[int 21h]

(1) Yes.

(2) Maybe the wrong frame flags or something...

(3) Yes.

[Xesdeeni]

So, just out of curiosity, what would most DVD players do with the video if it didn't have the flags set by pulldown? I'm assuming some would still play it correctly, right?

Also, do you have any suggestion about how I can test whether I've set the flags correctly before authoring and burning a test DVD and testing the video on my DVD player and TV?

Xesdeeni

[slk001]

Originally posted by Xesdeeni
So, just out of curiosity, what would most DVD players do with the video if it didn't have the flags set by pulldown? I'm assuming some would still play it correctly, right?

No authoring tool should even accept a video file at 23.976 fps. It has to be 29.97 fps. 29.97fps is the DEFAULT in PULLDOWN.EXE, so if you don't ask for another, 29.97 will be what you get.

If your video is jerky after pulldown, then you have a field order problem (most probably). If this is a true PROGRESSIVE source, then I am wondering where your field order got changed. Tell us where your source originated. There is an option that tells PULLDOWN to change the order. It is best to use the GUI for PULLDOWN, as it keeps your preferences, and gets rid of that commandline stuff. (GUIGUY.WMINDS.COM)

[Xesdeeni]

No authoring tool should even accept a video file at 23.976 fps.Ahh. Good point. If your video is jerky after pulldown, then you have a field order problem (most probably). If this is a true PROGRESSIVE source, then I am wondering where your field order got changed. Tell us where your source originated.They are some commercials from the Super Bowl in transport streams captured over-the-air from the HDTV transmission. They are actually 1280x720 @ 59.94 Fps, but they use a 3:2 pulldown similar to NTSC, where one film frame is shown for 3 video frames and the next is shown for 2. I used a couple of different tools to separate out the MPEG stream from the transport stream into a format that I could load into AVISynth. Then I decimated the extra frames down to 23.976 Fps and scaled the results to 720x480. I then fed this into TMPGEnc and CCE to encode as progressive.There is an option that tells PULLDOWN to change the order. It is best to use the GUI for PULLDOWN, as it keeps your preferences, and gets rid of that commandline stuff. (GUIGUY.WMINDS.COM)I'll try that when I get home if you think that makes sense.

Xesdeeni

[slk001]

You are forging a path in relatively uncharted territory. First off (just out of curiosity) what are you using to capture at 1280x720 at 59.94fps? Secondly, since this is a commercial, it was probably shot at the full 29.97fps rate, thus when you convert to 23.976fps, you get the jerky video (you are actually dropping video information). Create an .AVS script for the video at this framerate (23.976fps) and view the result using Virtualdub. If this is what is causing the jerky video, it will show up here. I believe that this is what your problem is - NOT field order.

I would try just a simple 2 to 1 decimation in AVISYNTH and then view the results to see if they were acceptable.

Hummm, but you say that the video is like XXXYYXXXYYXXXYY. If you are able to recover the XYXYXY video, is the result jerky? Probably not. If the XXXYYXXXYY pattern is consistant throughout the video, then a SELECTEVERY(5,1,4) command should recover the XYXYXY pattern.

Give that a try.

[Xesdeeni]

First off (just out of curiosity) what are you using to capture at 1280x720 at 59.94fps?I didn't capture it myself. A friend who is into HDTV got them via the AVSForum from someone who used an HD digital card for the PC to capture them off the air during the broadcast. This is the actual digital transport stream that was broadcast.Secondly, since this is a commercial, it was probably shot at the full 29.97fps rate, thus when you convert to 23.976fps, you get the jerky video (you are actually dropping video information). Create an .AVS script for the video at this framerate (23.976fps) and view the result using Virtualdub. If this is what is causing the jerky video, it will show up here. I believe that this is what your problem is - NOT field order.Three of the four commercials are for films (Bad Boys II, Matrix 2 & 3, and Daredevil). As I mentioned, they are 23.976 Fps film, so they were probably taken directly from film trailers. They were broadcast at 59.94 progressive Fps (HD broadcasts don't change format on-the-fly...at least today) in a way similar to NTSC telecine...i.e. repeate one film frame for three video frames and the next for two.

The other (for ESPN-HD) was a horrible mixture of stuff, with lots of post-processing. One clip even had weave-like motion artifacts, while also appearing to be telecined film. Ech!

But I always preview the video in VirtualDub so I know for sure. :)Hummm, but you say that the video is like XXXYYXXXYYXXXYY. If you are able to recover the XYXYXY video, is the result jerky? Probably not.Nope. And as I said, the TMPGEnc looks fabulous. I'm just trying to figure out how to get the same from CCE, which of course encodes much faster.If the XXXYYXXXYY pattern is consistant throughout the video, then a SELECTEVERY(5,1,4) command should recover the XYXYXY pattern."Great minds think alike." That's the method I used for decimating the video, after verifying whether the three or two repeat occurred first.

Unfortunately, I haven't had a chance to experiment with it yet. I'll let you know. I was just hoping someone with more film DVD experience knew off the top of their head why I was seeing the problem I described.

Xesdeeni

[patja]

I do some encoding of 720p HD material as well. I find that avisynth selecteven() and decomb.dll decimate works well to take it from 59.94 to 23.976

SelectEven()
Decimate(cycle=5,mode=0,threshold=0)

[Xesdeeni]

SelectEven()
Decimate(cycle=5,mode=0,threshold=0)I've seen this combination used instead of SelectEvery() several times on this board. Why are these two calls preferable to the one SelectEvery(). Is it faster?

Xesdeeni

[slk001]

These two command scripts will do basically the same thing. Take, for instance, this frame sequence:

AAABBCCCDDEEEFFGGGHH

Now, select every even frame, to get:

ABCCD EFGGH

As you can see, out of every five frames, there is a duplicate, which DECIMATE(cycle=5,mode=0) will discard. This script has the advantage that it can start anywhere in the sequence and still do what is intended. For instance, take the same sequence, but start anywhere but at the beginning:

ABBCCCDDEEEFFGGGHHIII

Again, select every even frame, to get:

BCCDE FGGHI

Again, there is only one dup for every 5 frames - easily decimated. However, compared to the other script, this one is slow - VERY slow (but it probably is still worth using). Also, if there is a sequence change somewhere mid-stream, this command script would most likely be able to adapt and recover. For instance, let's say editing cut the original sequence to this:

AAABBCCCDDHIIIJJKKKLL

Select every even frame:

ABCCD IIJKL

DECIMATE can handle the change in position of the duplicate.

To get the proper result, the SELECTEVERY(5,1,4) command requires that it start exactly at frame 1. The video also has to maintain the same structure throughout (unlikely). But this sequence will BLAZE through your video file.

I would opt for the slow method because of DECIMATES ablility to adapt to the the changes in the sequence.

[Xesdeeni]

That makes sense now. I guess for these short clips (30-60 sec), I don't have to worry about them getting out of sequence, so the SelectEvery() method is fine.

I have noticed that broadcast TV edits video after telecining in many cases, so I'm sure Decimate() is a better choice then. But for full-length films, say on DVD, is it really likely that they will alter their pattern in mid stream?

Xesdeeni

[slk001]

It depends on where (or when) they actually do the editing. I do a lot of IVTCing on my video streams and I see the sequence change all the time. So much so, that the SELECTEVERY command would have to be "hand fitted" to every change of pattern - not something that I would entertain in doing.

When I say "slow" I mean that it would run at 25-35% of the SELECTEVERY command (it is actually the DECIMATE command that slows things down).

[Xesdeeni]

It surprises me that they would edit the film after it has been converted to video for a DVD (but it doesn't surprise me that they would do this for TV). I would have assumed it would be edited as film before the encode. But then again it surprised me to learn that many DVDs of progressive film are actually encoded as 47.952 interlaced fields per second instead of 23.976 progressive frames per second. You never know with Hollywood types. :)

Xesdeeni