mkvmerge (GUI) and fps question

[djesteban]

In the Format specific options tab, if I entered 23.976 manually in the FPS field instead of selecting the 24000/1001 option in the drop down menu, will I get the same result at the end? I mean, since dividing 24000 by 1001 is a lot more precise than just entering 23.976, will it have an impact on playback?

Thanks

[hello_hello]

Well for fun I just extracted and then remuxed a raw x264 video stream using both methods, and played each with ffdshow doing the decoding while using ffdshow's on screen display to show the frame duration. It seems to be the best way to determine if there's any differences in frame rate, as programs such as MediaInfo seem to "round" the frame rates a little when supplying that info.

Using either method to remux the video stream using MKVMergeGUI, ffdshow displayed the frame duration as being 41.7083ms, so I'd assume the answer to your question is "no". Either method should produce the same result (I used a 25fps video stream for testing to be sure MKVMergeGUI was changing the frame rate each time).

As a side note... according to ffdshow an AVI remuxed with a frame rate of 23.976 using VurtualDubMod has a frame duration of 41.708ms, while the same video remuxed using VirtualDub had 3 out of 4 frames with a duration of 41.7084ms while the 4th's frame duration was 41.7083ms, giving an average frame duration of 41.708375ms.

According to my calculations the real frame duration for 23.976fps video is 41.708375ms so VirtualDub seems to win in the accuracy department.

Is 24000/1001 really supposed to be a more accurate way of describing 23.976 video or just an alternative method? Because according to the math it produces a frame duration of 41.7083333333ms which isn't quite the same as 23.976fps.
Not that it matters in relation to your question, as either way of describing the frame rate produces the same frame duration when muxing with MKVMergeGUI.

[sneaker_ger]

Is 24000/1001 really supposed to be a more accurate way of describing 23.976 video or just an alternative method?

Yes, it was defined that way.

mkvmerge produced exactly the same result for 23.976 and 24000/1001 over the length of a two hour movie for me. I don't know whether it automatically uses 24000/1001 when a user inputs "23.976" or if it's because of mkvmerge's internal math. mkvmerge produces timecodes with a precision of 1ms, so you get alternating frame lengths.

PCs have limited precision, if you use a simple calculator:
180000 (frames) / 23.976 ~= 7507.507508
(180000 * 1001) / 24000 = 7507.5

So the difference would be ~7.508 ms over the course of a 2 hours ~5 minutes long movie. Nothing anyone would notice. Whether it makes a difference boils down to the implementation of the muxer. Personally, I'd enter "24000/1001" in any program that allows it just to be safe. Why not do it correctly if you can?

[hello_hello]

Personally, I'd enter "24000/1001" in any program that allows it just to be safe. Why not do it correctly if you can?

Well aside from the three or four reasons you gave yourself for it not making any difference, how do you know the video you're remuxing wasn't originally created using 23.976 as the frame rate and by using 24000/1001 you're introducing a small error. ;)

[sneaker_ger]

Well aside from the three or four reasons you gave yourself for it not making any difference

It doesn't make any difference in mkvmerge, but it could have erratic outcome for players or other muxers. Let me rephrase: why use 23.976, which is not exact, when you could use the exact number?

how do you know the video you're remuxing wasn't originally created using 23.976 as the frame rate and by using 24000/1001 you're introducing a small error. ;)

Good point. But at 8ms error margin, I'd rather go for compatibility. mkv probably won't pose any problems, but mp4 and h264 have things like a timebase IIRC, so I'd rather make sure that it is set correctly.

[hello_hello]

I'm not really arguing against using 24000/1001 if a program will let you, although to be honest I can't see it making any real difference either way.

Out of curiosity... I just extracted a 23.976 video stream from an MKV and remuxed it into a new MKV using MKVMergeGUI while changing the frame rate to 25fps. Looking at the MediaInfo using MPC-HC, it reported the Frame Rate as being 25fps and the Original Frame Rate as being 23.976. The same thing happens even when changing the frame rate while remuxing Xvid/AVIs using VirtualDub.
Given the video stream seems to contain the frame rate information, I wonder why when muxing raw video streams using MKVMergeGUI it can't use that frame rate information, and instead forces you to enter a frame rate (otherwise it assumes 25fps)?

I'd even wonder how accurately players (well hardware players at least) adhere to the frame rate, or whether they're as liberal with the "rounding" as MediaInfo seems to be. For instance if I change the frame rate from 23.976 to 23.974, MediaInfo still reports it as 23.976. Obviously it isn't as the audio eventually goes out of sync when played with MPC-HC, but it does make me wonder if a hardware player would just speed it up a little and play it with a frame rate of 23.976 regardless. If that's the case, then any minor differences in frame rate would only serve to keep the audio in sync, or not.

[sneaker_ger]

You are correct, it could use that information - Mosu just hasn't implemented it. (Future versions are supposed to also change the stream info, btw.)