x264 changing framerate of 23.976024 sources

[turbojet]

According to eac3to and DGAVCIndex x264 changes the framerate of all 23.976024 sources to 23.975986. Adding --fps 23.976, 23.976024 or 24/10001 outputs 23.976043 fps.

x264 doesn't change the framerate of 25, 29.97030, 50, 59.940060 fps sources.

DivX H.264 encoder doesn't change the framerate of 23.976024 using the same sources and avs files.

Can an x264 developer look into this?

[Dark Shikari]

OPT("fps")
{
if( sscanf( value, "%d/%d", &p->i_fps_num, &p->i_fps_den ) == 2 )
;
else
{
float fps = atof(value);
p->i_fps_num = (int)(fps * 1000 + .5);
p->i_fps_den = 1000;
}
}

[roozhou]

x264 internally uses fractions, which is accurate, instead of decimals. Either 23.976024 or 23.975986 will be converted to 23976/1000 which is inaccurate.

[turbojet]

I tested --fps <input fps> to no --fps on 25, 29.97, 50, 60 sources and they were all bit identical.

I also tried --fps 5000 and it outputted the input framerate but it wasn't bit identical to using --fps <input fps>. Out of curiousity what does --fps do?

[J_Darnley]

It sets the framerate for raw video.

[turbojet]

It sets the framerate for raw video.

Is it something only scenarist can use?

I see differences in the 264 files but tsmuxer, dgavcindex, eac3to still sees it as input fps no matter what number I put for --fps and mkvmerge sees no framerate with both. Only exception is when the input is 23.976024 then everything gets weird.

[J_Darnley]

Huh? An x264 option has nothing to do with what scenarist does. By raw video, I mean uncompressed YV12 video for which you also need to specify the resolution. Both of these are ignored for avs and y4m input.

[turbojet]

I'm thinking of switches like --aud and --nal-hrd which I've heard scenarist needs and other tools don't. I thought you meant raw container output. Thanks that clears things up but --fps isn't really ignored by avs input as the files can differ as I explained above.

[10L23r]

this shouldn't cause syncing problems after muxing with audio and entering the correct framerate into the muxer ...right??

[turbojet]

this shouldn't cause syncing problems after muxing with audio and entering the correct framerate into the muxer ...right??

Technically it does but the change is so small I don't think anyone would ever notice it on typical length clips. Maybe if you had 10+ hour clip you might start to notice it.

[10L23r]

srsly?? cus muxers such as mp4box and mkvtoolnix ask you to write ur own framerate into a box, for .264 files.

but does fps rly matter for an encoder? cus i think all the encoder is supposed to do is process frames, without regard to time. the timing factor/framerate should be added by the muxer rather than the encoder. idk...

[Comatose]

Technically it does but the change is so small I don't think anyone would ever notice it on typical length clips. Maybe if you had 10+ hour clip you might start to notice it.
It doesn't, if you input the correct framerate when muxing like he said he will.

[ACrowley]

According to eac3to and DGAVCIndex x264 changes the framerate of all 23.976024 sources to 23.975986. Adding --fps 23.976, 23.976024 or 24/10001 outputs 23.976043 fps.

x264 doesn't change the framerate of 25, 29.97030, 50, 59.940060 fps sources.

DivX H.264 encoder doesn't change the framerate of 23.976024 using the same sources and avs files.

Can an x264 developer look into this?


AssumeFPS(24000,1001) into the avs sets/exports the correct Framerate through the avs and x264 writes 48000/10001 into the Header, "without" x264.exe --fps 24,10001 command.
Elecard Stream Analyzer shows timing present info flag 48000 ,1001. Its exactly 23.976024 fps :)

So simply use AssumeFPS(24000,1001) into your avs and you will always get 23.976024fps with x264 Header timing present info flag 48000 ,1001.

[roozhou]

srsly?? cus muxers such as mp4box and mkvtoolnix ask you to write ur own framerate into a box, for .264 files.

but does fps rly matter for an encoder? cus i think all the encoder is supposed to do is process frames, without regard to time. the timing factor/framerate should be added by the muxer rather than the encoder. idk...

I guess you forget ratecontrol.

[turbojet]

It doesn't, if you input the correct framerate when muxing like he said he will.

You are right I was wrong I was thinking of muxing without setting a framerate as I normally do.

EDIT: This is correct in most situations but since this framerate is so close to 23.976024 when tsmuxer, mkvmerge, mp4box are instructed to set 23.976 it doesn't change the framerate and outputs 23.975986. If you encode the same clip to 25, 29.970030, 50, 59.940060 and instruct the muxer to use 23.976 fps it will output 23.976024 which is correct. You can workaround the issue by changing the framerate to something other than 23.976 and then changing it back to 23.976 wtih any of the muxers.

Also if my calculations are correct some people might notice a little asynch near the end of a typical length movie, here's an example of a 2 hour movie:
23.976024 - 23.975986 = 0.000038 skew per second
60 seconds x 120 minutes = 7200 seconds
0.000038 x 7200 = 0.2736 second skew does this equal 27ms?


AssumeFPS(24000,1001) into the avs sets/exports the correct Framerate through the avs and x264 writes 48000/10001 into the Header, "without" x264.exe --fps 24,10001 command.
Elecard Stream Analyzer shows timing present info flag 48000 ,1001. Its exactly 23.976024 fps :)

So simply use AssumeFPS(24000,1001) into your avs and you will always get 23.976024fps with x264 Header timing present info flag 48000 ,1001.

Thanks for finding a simple workaround until x264 is fixed. I can confirm dgavcindex, eac3to, tsmuxer also treat this file as 23.976024.

[jdobbs]

Also if my calculations are correct some people might notice a little asynch near the end of a typical length movie, here's an example of a 2 hour movie:
23.976024 - 23.975986 = 0.000038 skew per second
60 seconds x 120 minutes = 7200 seconds
0.000038 x 7200 = 0.2736 second skew does this equal 27ms?
I don't think so.

23.976024 - 23.975986 = 0.000038
True, but that means you are going to be off by .000038 frames per second -- not seconds

So 1/.000038 means you would be off by one frame every 26315 seconds.... or every 7.3 hours.

Somebody correct me if I'm wrong... I hate doing public math.

[turbojet]

Ya that makes more sense, in that case sync shouldn't be an issue. Just a technical x264 issue and may cause some of the strange hardware player issues going around but that's yet TBD.

[roozhou]

If avisynth becomes time-based, there won't be such problem.

[turbojet]

Can you explain the connection between avisynth and x264 for 23.976024 input and how if differs between other encoders and inputs of other framerates?

[laserfan]

23.976024 - 23.975986 = 0.000038
True, but that means you are going to be off by .000038 frames per second -- not seconds

So 1/.000038 means you would be off by one frame every 26315 seconds.... or every 7.3 hours.

Somebody correct me if I'm wrong... I hate doing public math.:D

As an aside, I built an Excel spreadsheet to calculate time codes from frame numbers, and the only way I could get perfect HH:MM:SS.XXX out of it (as confirmed by DG's indexing tools and Vdub) was to put the fps in as:

23.976023976

Anything else and you don't get perfect thousandths in the timecodes! :p

[qyot27]

As an aside, I built an Excel spreadsheet to calculate time codes from frame numbers, and the only way I could get perfect HH:MM:SS.XXX out of it (as confirmed by DG's indexing tools and Vdub) was to put the fps in as:

23.976023976

Anything else and you don't get perfect thousandths in the timecodes!
The basic reason for that is because 23.976024 is rounded, as is 29.970030 and so on. 24000/1001 = 23.976023976 (although on my TI-30Xa it shows up as 23.97602398 because it can only show a total of ten digits+decimal point), 30000/1001 = 29.97002997, 60000/1001 = 59.94005994.

[laserfan]

Hmmm, I think I knew that! ;)

My only point was: if seeking timecode perfection, you can't round, and you can't truncate.

[ajp_anton]

The basic reason for that is because 23.976024 is rounded, as is 29.970030 and so on. 24000/1001 = 23.976023976 (although on my TI-30Xa it shows up as 23.97602398 because it can only show a total of ten digits+decimal point), 30000/1001 = 29.97002997, 60000/1001 = 59.94005994.You can't see the pattern? =)
24/1.001 = 23.9760 239760 23976 ...
30/1.001 = 29.9700 299700 2997 ...
60/1.001 = 59.9400 599400 5994 ...

[qyot27]

Hmmm, I think I knew that! ;)

My only point was: if seeking timecode perfection, you can't round, and you can't truncate.
Oh, I put it out there for the benefit of those that weren't actually aware, I only quoted your post on the matter because it was relevant to the explanation, not that I was replying.

You can't see the pattern? =)
24/1.001 = 23.9760 239760 23976 ...
30/1.001 = 29.9700 299700 2997 ...
60/1.001 = 59.9400 599400 5994 ...
Yes, of course. I just didn't feel quoting it beyond one complete iteration behind the decimal was necessary (and it really wouldn't be unless you're dealing with absurdly-long recordings).

[setarip_old]

The premise for this thread appears to be "Much ado about nothing"...

[turbojet]

Even considering eac3to and some hardware can't correctly handle the 23.975 streams outputted by x264?

xvid, divx 3.11, divx h.264, cce, hcenc don't change framerate by default I can't imagine x264 is intended to.

Removing avisynth from the workflow by using direct264 shows the same issue.

[roozhou]

Removing avisynth from the workflow by using direct264 shows the same issue.

If you are using direct264, try adding --timescale 24000 to the command line paramters

[turbojet]

If you are using direct264, try adding --timescale 24000 to the command line paramters

Output is the same 23.975986 fps.

[shon3i]

I had the same problem a few months ago, http://forum.doom9.org/showthread.php?p=1264174#post1264174, and I thought that the problem may be in eac3to or tsmuxer,
until then I always used DirectShowSource(xxx,fps=23.976 or fps=24/1.001) but same problem occur, then i switched to Neuron's DGIndexNV, and after this eac3to always showing 23.976 or 24p. I never doubt that maybe problem in x264, but now after i never saw that my video is encoded with 23,975 framerate

[madshi]

eac3to is picky. It only shows "24p / 1.001" if the h264 bitstream actually contains that information. If the h264 bitstream says "23.9xx / 1.000" then eac3to will display "23.9xx". I think there should be a way in x264 to signal that you want to use 24/1.001 instead of 23.976xxx. If there is no such way, it should be added. All Blu-Rays are 24.000/1.001. None of them uses 23.976/1.000. So x264 should do the same.

In real life probably using 23.976/1.001 is just fine. It's just not strictly standard.

[Atak_Snajpera]

In real life probably using 23.976/1.001 is just fine. It's just not strictly standard.
I think you meant 23.976 / 1 :) BTW Welcome back!

[kemuri-_9]

I think there should be a way in x264 to signal that you want to use 24/1.001 instead of 23.976xxx. If there is no such way, it should be added. All Blu-Rays are 24.000/1.001. None of them uses 23.976/1.000. So x264 should do the same.

x264 (mostly) internally uses and accepts fps as a int/int fraction-based format, so
if you want 24/1.001 pass it 24000/1001
if you want 23.976 pass it 2997/125

passing a float value to x264 causes it to convert to a fraction which generally causes an approximation to occur....

the numerator and denominator values can only go up to 65535 each...
if you give x264 something above that, it'll reduce the numbers by halving each of the values until both are below the value cap.

[Keiyakusha]

x264 (mostly) internally uses and accepts fps as a int/int fraction-based format, so
if you want 24/1.001 pass it 24000/1001
if you want 23.976 pass it 2997/125

passing a float value to x264 causes it to convert to a fraction which generally causes an approximation to occur....

the numerator and denominator values can only go up to 65535 each...
if you give x264 something above that, it'll reduce the numbers by halving each of the values until both are below the value cap.

I'm a bit confused by this post. Sorry if I get it wrong. Are you saying that if I have input framerate 24000/1001, it is possible to get exactly the same framerate after using x264? If so, how?

[kemuri-_9]

I'm a bit confused by this post. Sorry if I get it wrong. Are you saying that if I have input framerate 24000/1001, it is possible to get exactly the same framerate after using x264? If so, how?

in addition to the code segment Dark_Shikari posted, there is another relevant one:

if( param->i_fps_num > 0 && param->i_fps_den > 0)
{
sps->vui.b_timing_info_present = 1;
sps->vui.i_num_units_in_tick = param->i_fps_den;
sps->vui.i_time_scale = param->i_fps_num * 2;
sps->vui.b_fixed_frame_rate = 1;
}

in which x264 sets the stream's VUI timing/framerate parameters to what
A. x264 set based on the input file (the default action)
- 1. framerate read from avi/avs, and y4m files' respective headers
- 2. framerate set to default of 25 when reading from stdin and yuv files

B. you told x264 with the fps parameter (user-based override)

so the output stream has exactly the same framerate the input stream does (unless the fps parameter is used).

you can confirm the exact framerate x264 used in first line of the .stats file (when you generate one):
#options: 720x480 fps=24000/1001 ...

Edit:
This was mostly mentioned already by ACrowley here (http://forum.doom9.org/showthread.php?p=1295847#post1295847)

[turbojet]

Doesn't there have to be something else strange in x264's code besides 23976/1000 since 30000/1001 and 60000/1001 inputs are outputted without changing framerate by default?

[kemuri-_9]

Doesn't there have to be something else strange in x264's code besides 23976/1000 since 30000/1001 and 60000/1001 inputs are outputted without changing framerate by default?

not seeing what you're trying to say here....

x264 never alters the frame rate besides approximating float-based fps values to the thousandths place (x.xxx)...
(as indicated by the code segment posted by Dark_Shikari)
if you need something beyond the precision of 3 decimal points, use fractions.
that's it.

but you should make sure your source is the framerate you think it is, other editing/encoding programs can truncate the framerate as well...

[turbojet]

What I meant to say is 29.970030 input = 29.970030 output and 59.970060 = 59.970060. Which is accurate to the millionth and not rounded. If x264 only uses thousandths shouldn't it round these down to 29.970000 and 59.970000 thus changing the framerate?

Maybe there is something with the 6 in 23.976024 (instead of 0 in the other framerates) that's telling x264 to change the framerate to 23.975984, any idea how it comes up with this number?

[kemuri-_9]

If x264 only uses thousandths shouldn't it round these down to 29.970000 and 59.970000 thus changing the framerate?

if you said --fps 29.970030, then it rounds to 29.97 -> 2997/100
if you said --fps 30000/1001, then it's exact

if you said --fps 59.940060, then it rounds to 59.94 -> 5994/100
if you said --fps 60000/1001, then it's exact

if you said --fps 23.976024, then it rounds to 23.976 -> 2997/125
if you said --fps 24000/1001, then it's exact

moral of the story: don't use floats, use fractions.

you haven't even stated/proved that your source material has the exact fps rate of 24000/1001 either....

if it's an avisynth script use
info()
or
Subtitle("FPS: " + String(FramerateNumerator()) + "/" + String(FramerateDenominator()))
to confirm that the framerate is what you think it is.

I particularly use 24000/1001 and it outputs as just that, so it seems to me you're just blaming x264 for a problem that lies elsewhere.

[turbojet]

Info and subtitle line you wrote show 2500000/104271 which is 23.97598565277819 fps, which is not the correct framerate from the source, a filmed BD/DVD/DTV stream. 29.970030 and 59.940060 show the correct framerate.

Perhaps this could be the problem but if it is how is divx h.264, divx 6, cce, hcenc, xvid outputting 23.976024 from the same avs\source?
This is the reason I'm pointing fingers at x264 and avoiding avisynth by using direct264 has the same issue.

[kemuri-_9]

Perhaps this could be the problem but if it is how is divx h.264, divx 6, cce, hcenc, xvid outputting 23.976024 from the same avs\source?
This is the reason I'm pointing fingers at x264 and avoiding avisynth by using direct264 has the same issue.

sounds like they all do some "correcting" of the framerate based on what they think you want.
x264 does nothing of the sort, as it has a tendency to 'give the users more rope to hang themselves with'

and naturally as direct264 is mostly based on x264, it will naturally have the same issue unless extra code was added to handle that...

you should add an AssumeFPS(24000,1001) line to the avs script if you always have framerate issues with this source/type of source.

[turbojet]

Ya the workarounds work and probably should be done all the time to avoid playback\software issues but it's always nice to nip at the bud (which is still x264 considering the direct264 issue without using avisynth). Thanks for helping me troubleshoot.

I'm still hoping x264 will keep consistent to other encoders as it would solve everything but they haven't joined the discussion lately. I'll post a bug report for avisynth which should fix most, but 12 months since last commit. direct264 developer joined this conversation so they should already know about the issue.

[Trahald]

I dont think x264 developers have ever made changes simply to be consistent with other encoders. You have to prove what they are doing is wrong (ie a bug) and they will fix it. So far you havent.

[kemuri-_9]

frankly i don't see the change ever happening for x264 because
A. it's not a bug (x264 read that framerate from the input source)
B. x264 tends to stay away from correcting user ignorance
C. having x264 "auto-correct" could prevent actually having such framerates for whatever reason desired by the user

[turbojet]

True and for all we know direct264 is relying on directshowsource.dll since it has the same issue, so does DSS2. I'm surprised the other encoders mentioned have workarounds for this issue. Will just have to use workarounds for now and see if directshowsource.dll does get corrected.