How can you determine the original FPS of a captured video clip?

[Eldric]

Okay, I've already posted a thread like this on Videohelp.com , so it might seem a bit familiar to those of you who frequent that site. Unfortunately, I haven't gotten much of a response and I'm hoping someone who does video encoding might know the answer to this question. I've been attempting to perform Inverse Telecining on several minute-long test videos I've captured off of cable television - more for practice and filterchain testing than for anything else. Unfortunately, I recently ran into a bit of a problem. The Avisynth script I was using to IVTC video captures back to their original 23.976 fps would normally leave me with a smooth playing video, except for one or two test captures I did of some old "Western" TV programs from the early 60's. You might know what I'm talking about - jerky playback, especially noticeable with actor movement AND horizontal camera panning. Eventually, I was told that the problem was due to the original film being shot at 25 fps, not 23.976 as the majority of the other captures I've dealt with. While I was digging around trying to locate some additional information concerning IVTC and what I could do to solve the jerky movement problem, I ran across some information concerning some of these "Off the Wall" fps.

http://arbor.ee.ntu.edu.tw/~jackei/dvd2avi/ivtc/

The above website was where I found the info, but let me quote you directly what caught my eye.

"Another trouble of Anime is that they are not always pure 24fps. It may be...

* pure 30fps: ToHeart OP, Lain ED, Sakura War OVA2
* pure 60fps: Silent Mobius OP
* hybrid 30/60fps: Dual OP, SolBianca
* hybrid 24/30fps: Lain OP, Kurumi OP, Angel Links OP "

So, my question is - as I stated in the subject line - How can an encoder successfully determine what the original FPS of a given video capture was, in order to correctly Inverse Telecine it back to this original frame rate? Is there a piece of software that will automatically determine the original FPS due to the ratio of interlaced/de-interlaced frames? Is there an Avisynth script that can be used or perhaps a method that a coder can do to figure this out? The only programs I have been using to accomplish encoding have been a combination of VirtualVCR to capture the video, and then VirtualDub and Avisynth to encode and process the video. I hate to admit it, but so far these programs (VirtualDub and Avisynth) have been the most complex ones I've used to capture video. I'm not an expert - far from it in fact, and any detailed assistance would be appreciated. The main reason why I want to know this, besides my own curiosity, is that I plan to eventually convert several old home movies (in various antiquated formats) to DVD or VCD, and since I have family in both the US and Europe, wanted to ensure that family on both sides would be able to view the discs without any problems due to the 29.970/25 fps difference.

So if anybody has a method to detect and determine the original fps of a given video clip, or knows of a piece of software that might be able to do so, please drop me a line.

Thanks in advance,
Eldric :D

[manono]

Hi and welcome to the forum-

I spend a lot of time determining the true framerate on DVDs, as I encode a lot of silent films, which I've seen at everything between 15fps and 26fps. But, I've never captured anything in my life, so my experience may or may not help you.

Since you're familiar with the standard IVTC, then you know that the Telecide(Order=1,Guide=1).Decimate(5) combination reassembles the frames and then removes the one duplicate in every 5 frames to get it from 29.97fps back to its original 23.976fps. Before IVTC, if looking at the raw frames, you see that common 3 progressive frames followed by 2 interlaced frames. It's a 5 frame cycle. If you were to put on just Telecide(Order=1,Guide=1) without Decimate, then you'll see 4 unique frames and one duplicate in every 5 frames. Telecined material has a 5 frame cycle.

Now, you have to determine the cycle. If it was converted from PAL, then there's a 6 frame cycle often. It's more complicated than that, though, because often conversions from PAL involve blending fields, which will then give you blended frames. But one way to handle that is to then add Decimate(6) after Telecide(Order=1,Guide=3). That'll give you back 24.975fps. A better way to handle bad PAL to NTSC conversions is with the RePAL filter which does a reasonably decent job of removing the blends and also returns 24.975fps.

But the first step towards determining the original framerate is to determine the cycle. Once you've done that, then you can determine what Decimate or combinations of Decimate (or SmartDecimate settings) will eliminate the duplicate frames and return the original framerate.

And sometimes the cycles are complicated. For more information, check the PAL to NTSC and Silent Film sections of this document (http://www.doom9.org/ivtc-tut.htm#IVTCForNTSC).

[Eldric]

I hate to ask, but would you know of a webpage that has a record of the various interlaced/de-interlaced patterns and cycles and their corresponding frame-rate? You mentioned that there would usually be a 6 frame cycle, but does that necessarily mean that the film would have 4 frames de-interlaced, with 2 frames interlaced, or would it be some other combination? Sorry for the trouble, but I was hoping to try to understand what patterns I should be looking for - especially with some of the more unusual non-23.976 fps patterns - so I could better understand how to differentiate or recognize the film's true frame rate.

Eldric :)

[manono]

Hi-

PAL to NTSC DVDs have a 6 frame pattern. But I've seen 4 progressive followed by 2 interlaced frames exactly once in my life. Usually you'll get 3 or 4 or 5 out of the 6 frames in the pattern as interlaced. But the giveaway that it came from a PAL master, and can be more or less successfully returned to PAL framerate, is that at least one of the 6 frames is progressive (clean). I have seen instances where they're all interlaced for awhile, but elsewhere in the DVD you'll find the 6 frame pattern. So, start counting frames. If 0=progressive frame, and 1=interlaced frame, and you have 011111 011111 011111, then it's another lousy PAL to NTSC conversion.

No, there's no webpage about it. There is a sticky on the subject here on this site:

http://forum.doom9.org/showthread.php?s=&threadid=30709

And it's often real difficult to determine the true framerate by just looking at the raw frames. It becomes easier if you do something like Telecide(Order=whatever,Post=0)

Another pretty guaranteed way is to do a SeparateFields(), and then resize it. Then count how many unique (not duplicate), unblended frames there are in a 60 frame cycle.

[Guest]

You'll mislead yourself if you think there is always a "true frame rate".

Consider a hybrid with sections of 24fps pulled down to 30fps, and sections of pure 30fps. You can't say the frame rate is "truly" 24fps, or "truly" 30fps. Indeed, you can recover the progressive frames with Telecide but you're in a pickle for setting a final frame rate. If you want 24fps, you'll have to decimate the 30fps sections, making them jerky. If you want 30fps, you'll have to leave duplicate frames in the 24fps sections, causing stuttering.

Now, manono is right about the silents, because they have a consistent pattern, not different sections as for the hybrids I just described.

Another mess-up of those early films you mentioned is covered here:

http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?t=429

You'll also be able to experience my celebrated grumpiness there. :)

[manono]

Hi neuron2-

Eldric has reason to believe that it was originally 25fps, and I was trying to help him find out if that was true. Most do have a 6 frame cycle when converted to NTSC, and I didn't want to complicate things unnecessarily by pointing out that the cycle sometimes averages 6 frames, with some at 5 and others at 7. But in my experience that happens rarely.

And if it's some sort of a hybrid, then, of course, all bets are off. And as I mentioned at the beginning, all my experience is with DVDs. I have no idea what can go on with broadcast films or with captures, especially if frame drops are involved.

Now, manono is right about the silents, because they have a consistent pattern,

Actually, I've seen 2 examples of silent films where the framerate changes from time to time, and I know of another one that has 3 different framerates during different parts of the movie. As you may or may not know, silents were sometimes cranked at different speeds for different parts of the film. This happened often with comedies, as it was thought that speeded up action was funnier. Or if they were cranked at the same speed, instructions were sent along with the reels of film for the projectionist to show different portions at different speeds. I can even show you a vob sample of a silent with 2 different framerates, if you're at all interested.

The main problem with the bad PAL to NTSC DVDs is not so much the framerate, which is easy to determine with experience, but the fact that they are field blended. I know you're real busy with DVD2AVIdg these days, but one of my personal wishes, and one that I know is on your to-do list (although I don't know how high on the list), is for you to come up with a way to unblend these things. And not just the PAL to NTSC "talkies", but the silent ones even more. Those things are nearly impossible to straighten out. Silent films are being restored a lot these days, but most of that restoration work is being done in Europe. They then use the PAL master to make the R1 NTSC DVD, and they look just awful. And many of these films are from the US to begin with.

Here's an in-depth technical discussion of the R1 restored DVD of the Chaplin film, The Great Dictator. But the author is much more upset by the 4% PAL speedup than he is with the blended/ghosted frames (he calls it frame overlap):

http://www.dvdscan.com/chaplin.htm

Thanks for dropping in, neuron2. The thread gained gravitas, just from your mere presence. :)

[Eldric]

Okay, I'm just guessing here - but with Hybrid, would you process the film/slice up the capture, so that each section correctly gets the IVTC process it should get and then join them at a later date? I have yet to come across anything like that in my experimenting with film, but I'm just guessing here. I was wondering just now how you would actually detect if a piece of film is hybrid (by counting duplicate frames) since the only way you could (as I see it) would be to be lucky enough to select a piece of the film to examine, where this sort of FPS crossover is present. If you're examining a 60 frame segment, it would be noticeable if you're getting a 23.976 fps pattern and suddenly it stops. :D

[Guest]

@manono

Yes, you had the reply for Eldric well in hand; I was just adding a few caveats for the conceptual scheme he was building up in his head. And I certainly defer to your authority and expertise in dealing with silents!

@Eldric

Originally posted by Eldric
Okay, I'm just guessing here - but with Hybrid, would you process the film/slice up the capture, so that each section correctly gets the IVTC process it should get and then join them at a later date? I have yet to come across anything like that in my experimenting with film, but I'm just guessing here. You can do that, but after you join them, what frame rate do you set for the combined movie? Therein lies the dilemma. E.g., think of trying to append a 24fps progressive clip to a 30fps progressive clip. What frame rate will you set for the resulting clip?

I was wondering just now how you would actually detect if a piece of film is hybrid (by counting duplicate frames) since the only way you could (as I see it) would be to be lucky enough to select a piece of the film to examine, where this sort of FPS crossover is present. If you're examining a 60 frame segment, it would be noticeable if you're getting a 23.976 fps pattern and suddenly it stops. It's always most reliable to examine fields rather than frames. You do this by separating the fields in Avisynth and then stepping through them in VirtualDub. Now let's suppose I use a letter for each field and I change the letter when the picture in the field changes. Then for video I have a field sequence like this:

a b c d e f g h i ...

For progressive I have this:

a a b b c c d d e e ...

For 3:2 pulldown I have this:

a a a b b c c c d d e e e f f ...

Etc. Of course, you may not want to do that for the entire movie! So you use some tricks. Here are some of these tricks:

If the movie is from a DVD, you can examine the RFF flags from the MPEG syntax. My parsing tool for D2V files marks film and non-film sections, for example.

You can sample representative scenes throughout the movie.

You can use Telecide's metrics.

You can render as if it is not hybrid and then look for sections that play at the wrong speed or jerk/stutter. Then home in on those for detailed inspection.

One of my long-standing goals is to write a video analysis tool that performs an automatic analysis and outputs the results and recommendations for processing.

[Eldric]

Okay, I'm still playing around with this test video clip(which is pretty much why I haven't replied back after Mr. Graft's post). Now, following the advice given, I've split the video frames into fields - top field first of course, and then went on to examine the clip for duplicate fields in Virtualdub. I've gotten a pattern, but it is a bit confusing. The pattern is as follows:

ABBCDDEEEFFGGGHHIIIJJKKKLLMMMNNOOOPPQQQRRSSSTTUUUVVWXXYYYZZ1112233344555667778899900

Now, this is just an analysis of the first 84 fields in the clip, and I've attempted to identify each duplicate field in the series. I know, from prior experience and help from other encoders, that this clip was probably originally 25 fps (as I was eventually able to IVTC it to a smooth playing 25 fps file) and then was commercially telecined to the 29.970 fps format. From what I've been told, this particular procedure was probably a badly done telecine job, especially since the source of the video was shot in the US. Now, before I have my post torn apart by any members, let me just say that I'm EXTREMELY stupid when it comes to some of this stuff, and that is why I find that I have a hard time trying to understand some of the explinations I get posted back to me. It's not so much that I'm not trying to understand, it's just that I'm not familiar with a few of these concepts (but I'm trying to LEARN!). That being said, let's move on:

From the pattern - it appears to be primarily a 3:2 pulldown (as Mr. Graft stated in the previous post), but you see orphaned fields within this pattern - A,C, and W. Let's first disregard A, since that was the first field in the capture and the capture was taken from the middle of a television program that had already started. This leaves us with fields C and W. There are approximately 47 fields between these two orphaned fields. Alright, if we include one of the orphans, and divide by 2 since we're dealing with fields, we get a total of 24 fps. I've already attempted to encode this clip to 23.976 fps (and got the jerky playback problem) so I know encoding it to 24 fps won't work.

The solution given to me was the one that was provided in the link to the Neuron2.net site (previous found in this thread). The Avisynth script converts the clip to 25 fps and there is no jerky motion playback. Problem is I don't understand WHAT the script is actually doing. If I had a larger working knowledge of video editing and a firmer grasp of both Avisynth and Virtualdub, it seems to me that the solution here would be to duplicate fields C and W (2x each) in order to correct the 3 dupe/2 dupe pattern. Once that is done, you run a "Weave" script to join the fields back together and then you'd be able to run the telecine/decimate script and convert the film back to 23.976 fps.

Normally, in a straight-forward NTSC (29.970 fps) capture, I'd run this script:

LoadPlugin("decomb511.dll")
AVISource("capture.avi")
Telecide(Order=1,Guide=1)
Decimate(cycle=5)

In this script - I've identified the film source as being NTSC (order=1) and that the script is supposed to go by the top field first (guide=1). Additionally, the script is supposed to decimate every 5th frame as that will be a duplicate after the telecide process (cycle=5). As I said, this is fairly straight forward, and a not very complex script. The script for THIS particular clip however, is a bit more complex:

import("intellibob.avs")
LoadPlugin("kerneldeint140.dll")
loadplugin("avisynth_c.dll")
loadCplugin("SmartDecimate.dll")
AVISource("capture.avi")
assumetff()
x=kernelbob(6)
smartdecimate(1250,2997,bob=x)

Once again, we're showing that the clip is in NTSC format with the line "assumetff()". From there the script goes WAY over my head (but I'm attempting to figure it out, so cut me some slack please.) Okay - I know that "x=kernelbob(6)" is a processing method, and that the smarthdecimate routine has tagged that the source is 29.97 (from the number 2997 in the smartdecimate line). Most of the script's processes are actually being imported from another AVS (found on Doom9's forum in this post (http://forum.doom9.org/showthread.php?s=&threadid=74271) ) and seen in the "intellibob.avs" line. However, I'm still not getting what precisely is being done here. Can somebody explain what is being done here or perhaps another simpler method of performing the same process (that I could understand).

Yours in confusion,
Eldric (really out of his league here) :confused:

[scharfis_brain]

that intellibob-thread is very old and Outdated. I need to update some things, but haven't got the time jet.

go to the "restore24 revisited" thread and DL the archive. Inside you'll find intellibob.avs, too.

kernelbob is an avisynth function that gives bobbing abilities to kerneldeint.

instead of DLing the restore24 package, you may try to use this script:


function kernelbob(clip a, int "th",bool "mask")
{ mask=default(mask,false)
th=default(th,5)
ord = getparity(a) ? 1 : 0
f=a.kerneldeint(order=ord, sharp=true, twoway=false, threshold=th,map=mask)
e=a.separatefields.trim(1,0).weave.kerneldeint(order=1-ord, sharp=true, twoway=false, threshold=th,map=mask)
interleave(f,e).assumeframebased
}

LoadPlugin("kerneldeint140.dll")
loadplugin("avisynth_c.dll")
loadCplugin("SmartDecimate.dll")
AVISource("capture.avi")
assumetff()
x=kernelbob()
smartdecimate(1250,2997,bob=x)


read this http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?t=429
thread, for more information.
(or http://forum.doom9.org/showthread.php?s=&threadid=70035&highlight=batman , too)

this seems to be a common problem for NTSC-Users, so that should be made sticky or placed somewhere else (maybe capture faq/guide)

[Eldric]

I'm still not understanding what precisely smartdecimate is doing - or more precisely what the settings for it are accomplishing. As I stated, I know that the number 2997 is telling the script that the capture file was originally captured at 29.970 fps.

According to Kevin Atkinson's explination of Smart Decimate (found here (http://kevin.atkinson.dhs.org/tel/SmartDecimate.html) ) he describes the numbers following the smartdecimate function as follows:

The numerator and denominator are for the decimation ratio for the video after it has been separated into fields. The default is 24 and 60 for "numr" and "denm" respectfully.

Now, from what I'm seeing here - you're setting the numr at 1250 and the denm at 2997. It is this that I'm having a hard time trying to figure out precisely what you're doing. Like I said, I figure that you're getting 2997 = 29.97 fps, but where are you getting the 1250?

Also, is this typical for PAL formatted video or (like I stated) is this due to some screw up on the part of engineer who telecined this material? Bit tired atm (since it's 4 AM) so now I'm starting to doubt myself.

Eldric

[scharfis_brain]

- this is not a PAL failure, it is the PAL -> NTSC process,that made that source crappy.

- smartdecimate(25,60,bob=x) would have been worked too, but that would return 24,975 fps instead of 25 fps, because
25/60 * 59.94 fps = 24.975 fps
where 59.94 is the fieldrate of NTSC.

a ratio of 1250/2997 will return exactly the needed 25 fps.

as you can see, num and denum only represent the decimation ratio.

bob=x returns a smartbobbed video to smartdecimate.

smartdecimate can handle up to three input streams

last -> for decmation detection
bob -> is used if only a single field of a progressive frame is present
weave -> if two (or more) fields of a progressive frame are present

[Eldric]

Would appear that now I have run into yet ANOTHER problem concerning orphaned fields. I'm experimenting with a BBC broadcast (25 fps) that was tweaked for broadcast in the US (29.970 fps). Typically, with PAL formatted programs, you'd have the same 2:2 pulldown correct? well, after I split the fields, I'm getting the following field pattern:

AABBCDDEEF etc. - in other words, 2 Dupes of field A, 2 dupes of field B, and an orphaned field C.

Scharfi, would your script be able to correctly convert this to it's original format and deal with the orphaned fields?

[scharfis_brain]

jes, as I said several times before here and in mentioned threads.

smartdecimate can handle orphaned fields correctly.

the only thing to do, is to count the original framerate 'by hand' and then set up the decimation ratio

[Eldric]

okay, I THINK I'm starting to get a handle on what my problem is with understanding what is going on here. I'm sorry I'm so slow, but it's taken me a while to understand what precisely I'm looking at here with some of the scripts. I think the main problem I'm having is understanding how to go about setting the decimation ratio given what I'm seeing in the original framerate. This is what I've come up with so far:

smartdecimate's default setting is 24/60 - now, this is typically what is used for the telecide/decimate functions used to IVTC a piece of film captured in NTSC broadcast standard (29.970 fps) with an original film rate of 23.976 fps. Instead of using these numbers in it's equation, smartdecimate's default actually rounds up - so instead of 23.976 fps, we get 24 fps. Additionally, instead of 59.94 fields per second (taken from 29.970 - the captured fps format, and then multiplied by 2 since there's 2 fields per frame), smartdecimate uses 60 fields per second.

Now, let's look at both ratios - if we were to use smartdecimate's default, we get 24/60 = .4 . We get the exact same ratio number if we use 23.976/59.94 = .4 .

Now then, let's take a look at the numbers provided in the smartdecimate script in this thread. We got 1250 and 2997, the question is where do these numbers come from? Well, let's first multiply both numbers by 2, this gives us 2500 and 5994. Move the decimal point 2 spaces to the left and you get an original film fps of 25 fps, and a total fields per second of 59.94 for the original capture, showing that it was captured at 29.97 fps. As Scharfi showed in one of his previous posts, (2500/5994)*59.94 = target fps of 25 fps.

So, in my "New" problem of a PAL encoded program that's been found to have 5 interlaced frames in a 6 frame pattern, we examine what we know. 1) The show is from the UK (a PAL broadcast region) and therefore was originally shot at 25 fps. 2) it was captured off a broadcast done in the NTSC broadcast region, so it has a captured fps of 29.97 (or 59.94 fields per second). In order to revert the film back to it's original fps, the ratio I have to use is the same ratio as in the one above - 2500 (or 1250)/5994 (or 2997).

I THINK I have a grasp of what's going on now in the script - but if anybody sees anything I've missed or misunderstood, please let me know.

Scharfi, I'd like to thank you for all your help with this problem, especially since I've been exceedingly slow when it comes to understanding how some of these functions work and why some of the settings were used, were used by you. I'd PM you this message, unfortunately I couldn't due to your mailbox being full. Thanks again, and if I have any other questions, I will be sure to let you know.

Eldric :thanks:

[scharfis_brain]

one mistake here: smartdecimate does not round

24/60 is just the ratio, no rounding here.

because of this 25/60 will result in 24.975 and not in 25 fps :)

you could even do a totally doubtful assumefps(710,536) before applying smartdecimate(24,60). and it would decimate the video perfectly :) smartdecimate isn't interested in any framerate. it is only interested in the decimation ratio.


it is like decimte(5)

a decimation cycle of 5 means:
4/5 decimation ratio on half framerate:
4/5 * 29.97 = 23.976

or decimate(6)
5/6 * 29.97 = 24.975
(and now you know why decimate isn't that good at rePALing NTSC video)

or general:
the decimation ratio of decimate can be calulated this way:

decimate(x)
ratio = (x-1)/x