Log in

View Full Version : MP4Box framerate mismatch and crashing issue

qyot27
25th July 2008, 05:03
I have two problems that have cropped up recently.

Here's the situation: I've been dealing with some MP4 files that, while they play back correctly, I know that there are some underlying problems - mainly that the AAC stream isn't correct, since Winamp won't play it back and simply spits back a blank error dialog box - a tell-tale sign that the stream has no ADTS headers. My usual method for this kind of thing is to demux the files to the individual streams, and then remux them (as far as AAC goes, that would typically be faad -a if the MP4 mux/demux plugin for dbpoweramp doesn't work, which it doesn't if the streams don't have ADTS headers). The audio extracted fine with faad. This isn't the issue.

The issue is, these are video files. And most of the H.264 elementary streams correctly demuxed and remuxed with the MP4Box commands I used. But there are a few files that I noticed discrepancies in. Namely, the -fps parameter I gave at muxtime wasn't honored exactly. For example, I would give -fps 29.970001 and get back a framerate of 29.970035 and such instead. I had derived these framerate values from the original video files with mp4info (version 1.2.8, if that matters), and subsequently checked the new files with the same version of mp4info.

I've tried with three different versions of MP4Box (dev-0.4.1, dev-0.4.5(Sep 14 2007), and dev-0.4.5(build 12 - Dec 13 2007)), and it seems this issue of framerate mismatch on these files won't go away. I'm clueless as to what's causing it. Honestly, it is a somewhat minor issue, since the audio sync is still intact, but I want the framerates exactly the same as the originals, for posterity's sake.




The other issue is one of the video files makes MP4Box dev-0.4.5 outright crash whenever I try to mux the streams together, or extract the video stream from the original or the new copy - it extracts (or muxes) to 99% if YAMB is used, and then crashes (using the CLI, the crash occurs after the progress ticker disappears). If I use dev-0.4.1, the mux goes fine, but trying to extract with dev-0.4.1 or dev-0.4.5 still produces the crash. I'm sure that it's something that's wrong with the elementary stream, but as I can't get a diagnosis on what the error itself is, I don't know what to do with it (although I should mention that the 99%-muxed file plays fine, and at that point the video is practically over, but I just don't want that error cropping up in the first place). The crash itself does throw this up however:

http://img337.imageshack.us/img337/4019/mp4boxcrasherrorzz6.th.png (http://img337.imageshack.us/my.php?image=mp4boxcrasherrorzz6.png)

I can avoid the error with the original file if I pipe the video through MKV first and use mkvextract to get the elementary stream, but the problems muxing that file or extracting from the new copy made with it remain.

Let me know if I need to supply more information here or not. Any help is much appreciated.



Here's the readout from the CLI if this is necessary:

mp4box -raw 1 -v "video.mp4"
[iso file] Read Box type ftyp size 24 start 0
[iso file] Read Box type moov size 183621 start 24
[iso file] Read Box type mvhd size 108 start 32
[iso file] Read Box type iods size 21 start 140
[iso file] Read Box type trak size 33432 start 161
[iso file] Read Box type tkhd size 92 start 169
[iso file] Read Box type mdia size 33332 start 261
[iso file] Read Box type mdhd size 32 start 269
[iso file] Read Box type hdlr size 55 start 301
[iso file] Read Box type minf size 33237 start 356
[iso file] Read Box type vmhd size 20 start 364
[iso file] Read Box type dinf size 36 start 384
[iso file] Read Box type dref size 28 start 392
[iso file] Read Box type url size 12 start 408
[iso file] Read Box type stbl size 33173 start 420
[iso file] Read Box type stsd size 169 start 428
[iso file] Read Box type avc1 size 153 start 444
[iso file] Read Box type avcC size 47 start 530
[iso file] Read Box type btrt size 20 start 577
[iso file] Read Box type stts size 24 start 597
[iso file] Read Box type stss size 324 start 621
[iso file] Read Box type stsc size 52 start 945
[iso file] Read Box type stsz size 30408 start 997
[iso file] Read Box type stco size 2188 start 31405
[iso file] Read Box type trak size 47838 start 33593
[iso file] Read Box type tkhd size 92 start 33601
[iso file] Read Box type mdia size 47738 start 33693
[iso file] Read Box type mdhd size 32 start 33701
[iso file] Read Box type hdlr size 55 start 33733
[iso file] Read Box type minf size 47643 start 33788
[iso file] Read Box type smhd size 16 start 33796
[iso file] Read Box type dinf size 36 start 33812
[iso file] Read Box type dref size 28 start 33820
[iso file] Read Box type url size 12 start 33836
[iso file] Read Box type stbl size 47583 start 33848
[iso file] Read Box type stsd size 91 start 33856
[iso file] Read Box type mp4a size 75 start 33872
[iso file] Read Box type esds size 39 start 33908
[iso file] Read Box type stts size 24 start 33947
[iso file] Read Box type stsc size 1576 start 33971
[iso file] Read Box type stsz size 43692 start 35547
[iso file] Read Box type stco size 2192 start 79239
[iso file] Read Box type udta size 102214 start 81431
[iso file] Read Box type meta size 102206 start 81439
[iso file] Read Box type hdlr size 34 start 81451
[iso file] Read Box type ilst size 102160 start 81485
[iso file] Read Box type gnre size 26 start 81493
[iso file] Read Box type data size 18 start 81501
[iso file] Read Box type .ART size 30 start 81519
[iso file] Read Box type data size 22 start 81527
[iso file] Read Box type .nam size 78 start 81549
[iso file] Read Box type data size 70 start 81557
[iso file] Read Box type .day size 44 start 81627
[iso file] Read Box type data size 36 start 81635
[iso file] Read Box type covr size 101974 start 81671
[iso file] Read Box type data size 101966 start 81679
[iso file] Read Box type mdat size 52143063 start 183645
Extracting MPEG-4 AVC-H264 stream to h264
crypto
25th July 2008, 08:10
First, the fps problem isn't real. It is a rounding problem. The fps isn't stored as a floating point number, but as an integer and a fraction.

The crash is caused by the data execution protection of the CPU. You could disable it for mp4box, to prevent the error. But generally it means an error has occured during execution, like a buffer overflow, which could also be an attack.

You can give mp4creator a try.
http://mp4creator.sourceforge.net

There is also a new GUI version (mp4muxer (http://www.dvbportal.de/projects/mp4muxer)).
qyot27
25th July 2008, 18:46
Ok. Is the rounding problem evident in mp4info or mp4box, though? Because the value difference for one of the files is rather large (the original was 29.970760 and the new copy reported 29.972752), and I'd think if the fps could be reported out to several decimal places - even if that decimal is rendered from reading a fraction - that there would be a closer number rendered to .970760 if that particular value couldn't be represented exactly, rather than jumping all the way up to .972752. All the other differences were within 100 points of each other, but that one was much more drastic.

But maybe I'm just not understanding it correctly. There's a pretty good chance of that.


As for the data execution problem, that makes me wonder why it would be doing that in the first place. Since that file is the only one that causes it, at the very heart of it wouldn't that be a problem with the elementary stream? I'll see about mp4creator/mp4muxer. I had noticed the thread when I was searching to see if my questions had come up before.
crypto
26th July 2008, 08:28
You are right. Such a big difference in fps cannot be caused by rounding. And it can cause audio sync problems with longer movies. So the difference can be real or it can be caused by the displaying application. QT for instance seems to round to two decimals. The displaying application can also take it from the movie header, or from the video track.

During muxing you can specify a time_scale for the mp4. It determines the granularity of the fps value. So maybe you used one different from the original multiplex. You can use an atom viewer or other tool to get the timescale from the original. The timescale can be specified for the movie (moov.mvhd box) and for each track (trak.mdia.mdhd).
qyot27
26th July 2008, 18:44
You are right. Such a big difference in fps cannot be caused by rounding. And it can cause audio sync problems with longer movies. So the difference can be real or it can be caused by the displaying application. QT for instance seems to round to two decimals. The displaying application can also take it from the movie header, or from the video track.

During muxing you can specify a time_scale for the mp4. It determines the granularity of the fps value. So maybe you used one different from the original multiplex. You can use an atom viewer or other tool to get the timescale from the original. The timescale can be specified for the movie (moov.mvhd box) and for each track (trak.mdia.mdhd).
I had a feeling the timescale value was somehow involved when I looked at mp4creator, but didn't know exactly what to do with it so I left it at the default. I'll definitely see about the atom viewer. Any in particular that are worth noting? I checked on AtomicParsley something on the order of a year ago or so, but that stopped at pretty much a dead-end at that point.




Some updates:

I tried mp4muxer/mp4creator, and I got back mixed results. If I tried opening the file as is, it errored (the error is included below, for the purpose of completeness).

However, after trying a lot of different things, I think I came to the root of the problem. Neither mp4box nor mp4creator can handle having extra periods in the filename. Part of the video's filename had "R.E.M." in it, and as soon as I changed that to "REM" the problem disappeared.


As for the framerate issue, using mp4creator did make two of the four problematic files' framerates match the originals exactly. But two of them were still off (a 29.970002 turned into 29.970087 and a 29.970015 turned into 29.970036).



The error given by mp4muxer was this:
Length cannot be less than zero.
Parameter name: length.




See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.ArgumentOutOfRangeException: Length cannot be less than zero.
Parameter name: length
at System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 length, Boolean fAlwaysCopy)
at mp4muxer.frmMain.setDestination(String destination)
at mp4muxer.frmMain.btnDestBrowse_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
mp4muxer
Assembly Version: 0.9.1.0
Win32 Version: 0.9.1.0
CodeBase: file:///C:/Program%20Files/mp4muxer-0.9.1/mp4muxer.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
Accessibility
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/Accessibility/2.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------
System.Configuration
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Xml
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.
crypto
26th July 2008, 21:52
I had a feeling the timescale value was somehow involved when I looked at mp4creator, but didn't know exactly what to do with it so I left it at the default. I'll definitely see about the atom viewer. Any in particular that are worth noting?..

Yes, there are two free programs:

MiraVid MP4 Browser
Apple Dumpster (can also modify atoms)



Some updates:

I tried mp4muxer/mp4creator, and I got back mixed results. If I tried opening the file as is, it errored (the error is included below, for the purpose of completeness).


Thanks for the error description, I'll fix that.