PDA

View Full Version : MP4 - Bad Public Movie Atom


Barker
15th February 2006, 20:59
I hope this hasn't been answered before, I searched a few times but could find nothing relevant. I am using x264 Megui and I cannot get a full file to transcode from Xvid. The output container is mp4 and the profile I am using is PD-Ipod. When I try to play the resulting file, quicktime throws an error
-2002: a bad public movie atom was found in the movie. I found a solution on google that said to zip the file then unzip it, but it didn't work. In Media Player Classic, it simply states "unable to render file". This happens on 2 computers.

Now here is the strange part...If I use "trim" in my avs, and select a short clip to test (i.e. 0,5000) it works fine (the video plays without an issue). I have tried multiple xvid files with the same result. I am currently trying different trims to see what works and what does not. 0,100000 did not work.

Could this have something to do with the large frame count? Has anyone had this problem? I'm stumped on this one.

Below is my avs and megui log:

avs:
DirectShowSource("E:\XVID\test.avi",fps=23.9759856527702,audio=false)
LanczosResize(320,176)

megui log:
avis [info]: 320x176 @ 23.98 fps (100001 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
mp4 [info]: initial delay 0 (scale 2500000)
x264 [info]: slice I:821 Avg QP:22.00 size: 5494
x264 [info]: slice P:99180 Avg QP:22.00 size: 1468
x264 [info]: mb I I16..4: 21.6% 0.0% 78.4%
x264 [info]: mb P I16..4: 3.9% 0.0% 0.0% P16..4: 39.1% 23.2% 9.0% 0.0% 0.0% skip:24.8%
x264 [info]: final ratefactor: 12.41
x264 [info]: kb/s:288.0

Actual bitrate after encoding without container overhead: 288.97
desired video bitrate of this job: 700 kbit/s - obtained video bitrate: 289.767686665856 kbit/s

Regards,
Barker

foxyshadis
15th February 2006, 21:45
Sounds like it might be a 64-bit timescale bug. Try using assumefps(24000,1001) at the end of the script, and see if that lowers the mp4 scale, which might fix the problem.

(Calculations show it should hit 4 billion timescale around 40,000 frames, which should roughly match the # of good frames you get. The resulting bitrate bears that out, being around 2/5 of 700.)

Barker
16th February 2006, 04:23
Sounds like it might be a 64-bit timescale bug. Try using assumefps(24000,1001) at the end of the script, and see if that lowers the mp4 scale, which might fix the problem.

(Calculations show it should hit 4 billion timescale around 40,000 frames, which should roughly match the # of good frames you get. The resulting bitrate bears that out, being around 2/5 of 700.)


Thank you foxy! That worked perfectly!