#968 Muxing to MP4 uses decimal fps when it should use fractions

[ravewulf]

After encoding a 24000/1001 fps video, MediaTab shows

Frame rate: 23.976 (23976/1000) fps
Original frame rate: 23.976 (24000/1001) fps

When it should show

Frame rate: 23.976 (24000/1001) fps

This appears to be due to MeGUI sending a decimal frame rate to mp4box when it should be sending a fraction

Currently:

"C:\Programs\MeGUI\tools\mp4box\mp4box.exe" -add "D:\test.mp4.264#trackID=1:fps=23.976:par=1:1:name=" -tmp "D:\Temp" -new "D:\test.mp4.mp4"

What it should be for fractional frame rates:

"C:\Programs\MeGUI\tools\mp4box\mp4box.exe" -add "D:\test.mp4.264#trackID=1:fps=24000/1001:par=1:1:name=" -tmp "D:\Temp" -new "D:\test.mp4.mp4"

But it may also have something to do with the log showing MediaInfo (always?) returning a decimal frame rate rather than the fractional frame rate.

[ravewulf]

I found a workaround by forcing x264 to use the internal mp4 muxer via the --muxer mp4 switch even though MeGUI sets the output file extension to .264. Thankfully, x264's internal mp4 muxer outputs the correct 24000/1001 frame rate. This makes me wonder why MeGUI is using an external mp4 muxer for the encoding step when the internal muxer works just fine.

On remuxing with audio (and chapters, subtitles), mp4box detects the fractional frame rate in the imported mp4 file (with .264 extension as metioned above) and overrides the decimal frame rate specified by MeGUI's command line.

The workaround is a bit janky but the end result is acceptable.

[Obi-Wan]

Is something similar available in x265? I cannot see any muxer parameter only the output filename option.

[ravewulf]

It looks like x265 only supports raw bitstream output, so the workaround wouldn't work there. If there's a way to pull either the fractional fps or the numerator and denominator from MediaInfo, then that can be passed to MP4Box as fps=num/denom. I'm not sure how the dll interface differs, but MediaInfo's CLI gives the FPS as a decimal followed by the fraction in parentheses

[Jerome Martinez]

I'm not sure how the dll interface differs, but MediaInfo's CLI gives the FPS as a decimal followed by the fraction in parentheses

"FrameRate_Num" and "FrameRate_Den" field names.

[Obi-Wan]

Does it even matter? Does it influences playback or so?

[Jerome Martinez]

Does it influences playback or so?

Yes because it is inaccurate and leads to some A/V problems e.g. after 2 hours of content, there is 160 ms (4 video frames...) of difference between audio and video.

Does it even matter?

It does. There is already enough mess with 1/1.001 frame rates, no need to add even more mess. The tip in MediaInfo is because some users faced such kind of A/V sync and try to catch that before their own users complain about playback incoherence.

[Obi-Wan]

Oh, thanks. You convinced me ;-)

[ravewulf]

It matters because it is inaccurate and, hence, a bug

[Zathor]

Thank you very much. It should be fixed on version 2929.

[ravewulf]

Confirmed as fixed. Thank you!

[Zathor]

thanks for the confirmation