How do you determine the framerate of a video?

[Chainmax]

Having recently discovered the wonders of Gabest's FLV splitter and enabling FLV1 decoding on FFDShow, I was going to try making watchable versions of a couple of X-Men anime intros on YouTube.

In trying to find out the A/V specs of each file, I used ZoomPlayer and FFDShow's tray icons. The "Playing Information" dialog in Zoomplayer reported the files as having 29.97fps but the FFDShow's "Video Decoder" section reports it as having 25fps. The only other thing I can think of to find out a video's framerate is to open it via AVISource or DirectShowSource (without setting the fps parameter).

So, which method do you trust will give you the real framerate of a video?

[chipzoller]

You could try seeing what MediaInfo reports on the file. It does have some bugs, but I've not seen any in the frame rate reporting aspect of the program.

I would also like to know if there are any trusted apps that will accurately report similar info and in detail like MediaInfo.

[fccHandler]

From what I understand, FLV doesn't have a fixed frame rate. All video and audio samples are simply time stamped.

[Chainmax]

So how can I convert them to DVD compliant MPEG2 then?

[fccHandler]

Sorry, I have no idea. I don't know a whole lot about them. I know that the open source MPlayer will play and decode them, so maybe you could start from there. However you do it though, I fear it may be a very frustrating project. :(

[Chainmax]

Oh, it's very easy to do so as I can open them in Avisynth, the only problem I have is what to set DirectShowSource's fps parameter to (or at all, is it really necessary?).

[fccHandler]

If you're making a PAL DVD, you might try using the "convertfps" flag, for example:

DirectShowSource("movie.flv", fps=25, convertfps=true)

[Chainmax]

I'd rather not do that. If it's VFR, I'd like to find out and then use VFR-dedicated framerate conversion methods.

[Moitah]

fccHandler is correct, there is no frame rate defined in a FLV file, only timestamps on each frame.

EDIT: I had said that the timestamps don't look correct but I was parsing them wrong :P.

[Chainmax]

Is there a way to use that timestamp info to make as good a conversion to DVD-compliant MPEG2 as possible? If not, I'll just treat is as CFR, so which method would you recommend me to trust:

- The "Playing Information" dialog in Zoomplayer?
- FFDShow's tray icon's "Video Decoder" section?

or

- opening it via AVISource or DirectShowSource without setting the fps parameter and check VDUbMod's "File Information" section?

[foxyshadis]

That's a surefire way to hit desync. You can just use

DirectShowSource("x.flv",fps=59.94,convertfps=true)
separatefields().selectevery(4, 0, 3).weave()

to minimize judder. (Or fps=50.) One thought I had was to use a dedup log to check for drop patterns that would indicate vfr video, but it'd take a little coding to make the checking less painful.

Avisynth's vfr capabilities are just too limited to do anything more advanced (mocomp, or even blending) if it is vfr.

[Chainmax]

I still have to know wether to set fps as 59.94 or 50, which depends on wether the source is reported as 25fps or 29.97fps. So, which fps report should I use as a base for that decision? Also, should I include audio=true to the script snippet you posted or does it not affect A/V synch?

[edit] I used your suggestion and I get some sort of interlacing artifacts :confused:.

[foxyshadis]

Well, you said you were going to DVD so I assumed you wanted interlaced. Guess not.

What I meant by the fps is what your destination format is, not whatever the source is. Say, if the source is some combination of 10, 12, 25, and 30, and you're going to 50i, what would you even do with it? There's no way you can convert it properly to 50p once it's inside avisynth, unless you find the ranges, split them up, and process each separately, so you might as well just duplicate frames up to 50p on input and cut down to 50i for DVD. Or 60p/60i.

If you can be sure it's cfr or at least mostly cfr (via dedup logs, ffdshow osd timestamp logs, or mkv timecodes), then you can load at that and use your favorite avisynth-based conversion, of course. Someone's working on a mkv v2->v1 converter that'll make that easy, and I think the ffdshow osd timestamp format can be easily converted to mkv v2.

[Chainmax]

Well, the source is progressive, so keeping it progressive is a better idea, right?

By the way, could you tell me where to find info on checking out if it's cfr or at least mostly cfr via dedup logs, ffdshow osd timestamp logs, or mkv timecodes? I have no idea how to do either.

[Chainmax]

foxyshadis?

[foxyshadis]

Sorry, I've been meaning to come up with a tool to do it, in lieu of a decent explanation, because doing it manually is no fun. But say you import it with Directshowsource at 120fps (fps=119.88,convertfps=true), and use dedup on it (DupMC(log="dedup.txt")). You would scan the log for patterns that indicate its true framerate - most will be 0 difference, the ones that aren't are the important ones.

If there's one non-zero frame every 5 lines, it's 24fps, if it's every 4 lines, it's 30fps, and if it's a pattern of mostly 5s with an occasional 4, it's 25. If it's hybrid some areas will be one and others another. It might even be much lower, like 10 or 12 fps. Raise the import framerate as necessary (try 12000 if you need real precision) to figure out 30 vs 29.97 or 24 vs 23.967 based on the exact numbers of dup frames inserted.

You can see why this is better done with a tool. I have some ideas but it requires modifying dedup.

[Moitah]

I'm releasing a new version of FLV Extract a bit later today that can output a timecode file. It also will tell you the average framerate (frame count divided by duration), and it tries to estimate the true frame rate (ignores timestamp skips).

EDIT: Done, see my site or my thread in A/V containers.

[Chainmax]

I'll use your program and compare it to foxyshadis's once it's released. Thanks for the answers :).

[Chainmax]

This is strange, the first file shows this report:

http://img82.imageshack.us/img82/1429/1hj2.png (http://imageshack.us)

So I guess I can use DSS("",fps=29.97,convertfps=true,...)



The second file shows this report:

http://img50.imageshack.us/img50/1414/2jc0.png (http://imageshack.us)

I guess I could use fps=23.976,convertfps=true, but it's strange that it reports different things than the first one since they are two intros from the same show. If you want to take a look at the timecodes, I uploaded them to RapidShare:

http://rapidshare.de/files/27275749/X-Men_Anime_Intro_N_1.txt.html
http://rapidshare.de/files/27275754/X-Men_Anime_Intro_N_2.txt.html

[Moitah]

Looks like my calculation method didn't work so well on the second one. This is how the timestamps are in the timecode file you uploaded:

time delta # of frames
33 ms 1025
34 ms 388
67 ms 515
66 ms 23
100 ms 46
101 ms 15
134 ms 4
133 ms 3

The 66/67 ms frames slip into the frame rate calculation because there are so many of them (> 10% which is the current threshold). I'll see what I can come up with.

[Chainmax]

foxyshadis, what do you make of the two timecodes files?

[Chainmax]

Looks like my calculation method didn't work so well on the second one. This is how the timestamps are in the timecode file you uploaded:

time delta # of frames
33 ms 1025
34 ms 388
67 ms 515
66 ms 23
100 ms 46
101 ms 15
134 ms 4
133 ms 3

The 66/67 ms frames slip into the frame rate calculation because there are so many of them (> 10% which is the current threshold). I'll see what I can come up with.


- 1000/33 and 1000/34 are very close to 29.97 (+1.1% and -1.8% respectively)

- 1000/66 and 1000/67 are very close to 14.985 (+1.1% and -0.4% respectively)

- 1000/100 and 1000/101 are very close to 9.99 (+0.1% and -0.9% respectively)

- 1000/133 and 1000/134 are very close to 7.4925 (+0.4% and -0.4% respectively)

So, each set of frames is less than two percent away from an exact fraction of 29.97fps. After reading the Avisynth documentation, I came up with this:

The fractions of 29.97 that appear are 1/2, 1/3 and 1/4. The smallest common multiple of 2,3 and 4 is 12 and 29.97*12=359.64, so I could use DSS("",fps=359.64,convertfps=true,audio=true) and then use TDecimate to go back to 29.97fps. Would you guys be willing to compare motion fluidity between the original and an encode made this way?

[foxyshadis]

Actually, that's exactly equivalent to just starting from 29.97.

Say you had some 30 fps frames and some more 15 fps frames (just picking round numbers). You load this in at 60 fps, being the least multiple of the fractions. What happens? All 30 fps frames are doubled to 60 fps, all 15 fps frames are quadrupled. Then you decimate to remove every other frame, leaving 15s duplicated and 30s left alone. Now, if you were to load them at 30 from the start, the 15s would also be duplicated to reach 30, and the 30s left alone. DirectShowSource does the hard work.

In other words, you only need to change the input fps if they aren't 1/x multiples of each other, because the least common multiple is the largest number (1*30 = 2*15 = 3*10 etc). When you start getting framerates not even close to single fractions, that's when you start multiplying across the numerators.

Oh, and about your other question, I'd say using Moitah's timecode extractor, converting them to v1 with tritical's avi_tc, and see what framerates show up - the distribution for most will be cfr or look like this, because it's cfr with drop frames, where the largest framerate is the "real" rate. Only a rare few will be hybrid (probably converted from 120 fps sources, as I don't yet know of a vfr flv converter).

[Chainmax]

That's would be exactly equivalent to just starting from 29.97 if the source fps were exactly 1/x fractions of 29.97, but they aren't. My reasoning was that "upsampling" to 359.64fps and then using TDecimate would make those <2% discrepancies be less noticeable than just loading it at 29.97fps. Am I wrong thinking this?

[foxyshadis]

Mmm, it might work if the real internal timecodes suffer from Moitah's ms roundoff, but flv timecodes can be greater than μs resolution, most of the frames should actually be 33.366667 ms or something near it if they weren't badly quantized first. If they were, then yeah.

Still, it can't hurt anything, it'll just take a lot longer to run.

[Moitah]

Timestamps in FLV are stored in a 32 bit unsigned integer as milliseconds. FLV Extract doesn't do any rounding of timestamps.

[Chainmax]

Mmm, it might work if the real internal timecodes suffer from Moitah's ms roundoff
...
Timestamps in FLV are stored in a 32 bit unsigned integer as milliseconds. FLV Extract doesn't do any rounding of timestamps.

So the upsampling method won't work then. Besides, after converting the timecodes to v1 (what is the Assumed FPS paremeter in there for anyway? It doesn't seem to do anything), both FLVs showed framerates very close to 29.97fps or 1/x fractions of it, so I'll just use DSS("",fps=29.97,convertfps=true). Thanks for all the advice and patience guys :).

[Chainmax]

VDubMod's "File Information" dialog when opening the script shows the audio as having 4 channels and being stereo, isn't that a contradiction? It also lists it as WAV, isn't it supposed to be MP3?