Rational Framerate in MP4?

[Zarxrax]

Does the MP4 container support rational framerates? I am a bit confused, because x264 cli appears to support it, but upon examining the output file, it just converted it to decimal, and further, mp4box only seems to support decimal values.

[cacepi]

Does the MP4 container support rational framerates? I am a bit confused, because x264 cli appears to support it, but upon examining the output file, it just converted it to decimal
While I don't know if an mp4 container can support rational frame rates, there is no mention of rational frame rates in the H.264 spec that I have (11/05 revision). Perhaps someone with a newer version of the spec can answer.

[Prettz]

What would be the purpose of using a ratio vs. using a long decimal number? To avoid rounding up at too large of a decimal place?

[foxyshadis]

MP4 doesn't support framerates, it only supports individual frame timestamps and durations. But for all intents the stream-level default duration is the framerate, which is a rational pair of 32 or 64 bit numbers, depending on how fine it needs to be.

x264 appears to support a rational input (--fps 30000/1001, for instance), the code is certainly there, but I haven't actually tried it.

That has nothing to do with AVC, only with the mp4 format.

[akupenguin]

MP4Box only supports decimal argument so the --fps parameter, but as a special case it converts any decimal numbers that are sufficiently close to various ntsc framerates into their exact rational form.
x264cli passes per-frame timestamps to gpac as rational numbers.

What would be the purpose of using a ratio vs. using a long decimal number? To avoid rounding up at too large of a decimal place?
Because 24000/1001 is right, and 23.976 is wrong. N significant digits may be enough for your uses, but why not use the real value which is correct in all cases?

[bond]

to sum it up: mp4 uses rational framerates

there is no need to attach a duration to every frame. you can define that every frame has the same duration (resulting in cfr), but you can also give every frame an own duration (resulting in vfr)

[Zarxrax]

Well, I am not sure that my output is using the correct framerates. I use avisynth to look at the framerate that is stored in the file, and instead of 24000/1001, it will be 10000000/417083.
I guess maybe AviSynth is not an accurate measure for this? I also tried looking at MediaInfo, and that just says 23.978, which I know must be just wrong.
How can I check what the framerate ended up as? I guess it doesn't really matter as long as its pretty close, but I just like it to stay 100% accurate for some reason :D

[Sharktooth]

Maybe it was muxed using the wrong framerate... or it was a result of some rounding errors.

[bond]

Well, I am not sure that my output is using the correct framerates. I use avisynth to look at the framerate that is stored in the file, and instead of 24000/1001, it will be 10000000/417083.
I guess maybe AviSynth is not an accurate measure for this? I also tried looking at MediaInfo, and that just says 23.978, which I know must be just wrong.
How can I check what the framerate ended up as? I guess it doesn't really matter as long as its pretty close, but I just like it to stay 100% accurate for some reason :Dpost your avisynth script plz

whats your source file and how do you know the framerate in it is really 24000/1001?

[Zarxrax]

post your avisynth script plz

whats your source file and how do you know the framerate in it is really 24000/1001?

Source file is an avisynth script like this:
AVISource("test.avi").AssumeFPS("ntsc_film")

To check the output framerate, I use this script:
DirectShowSource("test.mp4").Info()

Now here are a couple different possibilities, all with same output showing the wrong fps:
1. x264.exe --bitrate 1000 --output "test.mp4" "test.avs"
2. Same as above, but include --fps 24000|1001 parameter.
3. x264.exe --bitrate 1000 --output "test.264" "test.avs"
mp4box.exe -fps 23.9760239760 -add "test.264" -new "test.mp4"

So no matter whether i set the framerate through x264 or through mp4box, avisynth reports that it is 10000000/417083.

[bond]

Source file is an avisynth script like this:
AVISource("test.avi").AssumeFPS("ntsc_film")

To check the output framerate, I use this script:
DirectShowSource("test.mp4").Info()what exactly do you write in "ntsc_film"?

what exactly does avisynth output with the info() option?

[foxyshadis]

AssumeFPS("ntsc_film") is valid avsynth 2.5.7 syntax, corresponding to AssumeFPS(24000,1001).

Zarxrax, why 24000:1001? It should be --fps 24000/1001. There's nothing in the code to support a : syntax, it would probably be truncated to float by the default.

You might also be running into DirectShow's limitations - iirc the framerate is only reported to the application as a duration, which is necessarily rounded off somewhere, so the app has to use continued fractions to get it back into rational form.

[Zarxrax]

Zarxrax, why 24000:1001? It should be --fps 24000/1001. There's nothing in the code to support a : syntax, it would probably be truncated to float by the default.

You might also be running into DirectShow's limitations - iirc the framerate is only reported to the application as a duration, which is necessarily rounded off somewhere, so the app has to use continued fractions to get it back into rational form.

Whoops, it was just a typo in my post.
I was also suspecting maybe its a problem with reading it through directshow. Is there any other method that would let me check the framerate more accurately? I'm satisfied to just leave it at this though, as it sounds like the mp4 file itself is fine.

[foxyshadis]

My guess would be to use mp4dump from mpeg4ip, and check the timescale flag. Unfortunately it only reports duration of the full stream, not each frame, so you have to live with only half the info.

[Prettz]

Because 24000/1001 is right, and 23.976 is wrong. N significant digits may be enough for your uses, but why not use the real value which is correct in all cases?
Man, someone is irritable :rolleyes:

And 23.976 isn't "long" at all, in fact, it's really short, only down to the milliseconds. And I was more interested in what Zarxrax needs a rational framerate for, just out of curiosity.

[Zarxrax]

And I was more interested in what Zarxrax needs a rational framerate for, just out of curiosity.

It was just a matter of curiosity mainly, and theoretically for better compatability. With AVI files, I have seen particular software *cough*AdobePremierePro*cough* import stuff with slightly incorrect framerates (enough to actually make a difference) if the rational value of the framerate is not set exactly to certain values. Of course, Adobe Premiere doesnt even support mp4 files, and mp4 files wouldn't be good for editing anyways, so I really DON'T need it to be a perfect framerate, I guess.

I just tend to think about weird things like "what if someday i need to do something with this file, but the framerate is a little off and causes it to screw up somehow". Of course I guess the obvious solution would be to just remux it at that time :p

[bond]

My guess would be to use mp4dump from mpeg4ip, and check the timescale flag. Unfortunately it only reports duration of the full stream, not each frame, so you have to live with only half the info.yes, using mp4dump is an option

check the value in the timescale flag and the value in the stts atom. they together form the framerate