Bug in MP4 Header?

[Thomas9999]

Hi,

I convert movies using MeGUI for a long time. I convert different type of sources to 1280 x 720 mp4 which I can use on iPad, iPhone and PS3. I found out, that the Quicktime player for Windows is a good test vehicle for verifying the converted movies. If it works on Quicktime player it works also at PS3 and the other devices.

If the source is a movie with a frame rate of 23.976 fps the converted mp4 always causes an error -2002 on Quicktime player and I get also an error on PS3.

I did a little bit of research and found out, that the mp4 header of the movie has wrong entries in the Media Handler Header (mdhd). The attachment shows two examples. For my opinion the values for stts.sampCnt and stts.sampDur were defined improper, so that the product of these two values exceeds the allowed range of 32 bit in the mdhd structure.

It can be shown, that any part of a movie with 23.976 fps, which must not be longer than 28 min, has correct entries in the header and can be played without problems. If the part is longer than 28 min the error occurs.

Is there anybody who can help me?
Thomas

[Sharktooth]

yes, you should report this to x264 and gpac developers to see where the problem lies.
but, before doing that, trash CrapTime(tm) and use a compliant player with a working mp4 source demuxer.

[b66pak]

go to settings and check the qt compatibility box...
_

[Mr VacBob]

What does the compatibility option change?

[b66pak]

will force encoding to raw before muxing to mp4...
_

[roozhou]

@Thomas9999
What software did you use to show the mp4 header structure in that pdf?

[cacepi]

@Thomas9999
What software did you use to show the mp4 header structure in that pdf?

That's QuickTime Dumpster... don't know if it's available for Windows, though.

@Thomas9999: Since it seems that you have OS X, have you tried using QTCoffee (http://www.3am.pair.com/QTCoffee.html) to remux the file?

muxmovie InFile.mp4 -mp4 -o OutFile.mp4

[VFR maniac]

QuickTime doesn't support 64-bit atoms except for mdat and co64 atom.
flags = 0x01000000 means version 1 atom, so the movie with the error ‐2002 in Quicktime‐Player and error at PS3 has version 1 mdhd atom, which is 64-bit atom.
Version 1 mdhd atom is defined by ISO base media file format (14496-12).
MOV (QuickTime file format) doesn't have definition of version 1 mdhd atom.
Basically, QuickTime app support not MP4 lol but MOV-ish MP4 such as M4V, M4A, etc....
QuickTime app read the mdhd as version=0 (32-bit atom), thus that is the reason why QuickTime returned such error.

Large timescale brings about large duration, so you should reduce the timescale.
I think your sample movie has mdhd timescale=2500000 (apparently, parser sent inappropriate timebase to x264), thus you should specify --timebase 1001/24000 or --fps 24000/1001 manually,if you want fps=24000/1001 from the source.