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?
+ Reply to Thread
Results 1 to 26 of 26
Last edited by Mini-Me; 23rd Dec 2010 at 07:55.
For each section:
AssumeTFF() or AssumeBFF()
Last edited by jagabo; 23rd Dec 2010 at 08:51.
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...
Last edited by Mini-Me; 23rd Dec 2010 at 11:47.
Can you post a sample?
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:
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.
Last edited by Mini-Me; 23rd Dec 2010 at 12:41.
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.
The framerate's 16fps (15.982fps, actually). You can try:
But, because of the presence of field blends and all those 'warped' frames, I had somewhat better luck using SRestore:
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.
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?
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:
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:
# Match fields:
TFM(field = 1, mode = 5, PP = 1)
TFM(field = 0, mode = 5, PP = 1)
TFM(field = 1, mode = 5, PP = 1)
Yadif is a special case. It doesn't auto load like other filters. You have to use:
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.
Last edited by jagabo; 23rd Dec 2010 at 17:53.
Ahhh...that would be why. Thanks!
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.
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?
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.
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)
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:
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:
Last edited by manono; 24th Dec 2010 at 04:20.
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).
Last edited by Mini-Me; 28th Dec 2010 at 20:33.
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'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.
Last edited by Mini-Me; 29th Dec 2010 at 22:06.
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.
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.)
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.
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.
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.
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.
Last edited by Mini-Me; 30th Dec 2010 at 05:17.
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.
Last edited by jagabo; 30th Dec 2010 at 08:22.
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)