On Wed, Oct 12, 2016 at 8:04 AM, Carl Eugen Hoyos <ceffm...@gmail.com>
> 2016-10-12 16:03 GMT+02:00 Thomas Worth <d...@rarevision.com>:
> > On Wed, Oct 12, 2016 at 2:50 AM, Carl Eugen Hoyos <ceffm...@gmail.com>
> > wrote:
> >> 2016-10-12 9:31 GMT+02:00 Thomas Worth <d...@rarevision.com>:
> >> > Has anyone actually looked at the MP4 file, BrokenVideo-8min.mp4?
> > Just look at mdhd and you'll see what I'm talking about.
> This is the second comment today that could be misinterpreted:
> Please remember that not everybody is a native speaker and
> be more careful.
Allow me a question:
> Did you test with any non-QT based player?
> If your analysis were right, nothing could play the sample, so I
> believe it is safe to say that your analysis cannot be correct.
Yes. Tested the file with Adobe After Effects version 13 on a Mac, and it
failed. I am pretty sure After Effects uses its own media decoder for
MOV/MP4 and not QuickTime.
The mdhd atom in the file is version 1 and has 64bit time and
> duration fields and is therefore twelve bytes larger than a
> version 0 mdhd atom.
Right. I took another look at this, and QuickTime Player on OS X 10.12 does
report a 23.976 frame rate. I re-encoded Alexey's file with my copy of
ffmpeg using libx264 and using -video_track_timescale 10000000, and it
wrote an MP4 file with the same mdhd atom as Alexey's file. Obviously, the
duration field of the mdhd atom (version 1) needed to be 64 bit since the
video was so long that the PTS values would have exceeded the 32 bit
unsigned limit. In this case, since the file has 11509 frames, the last PTS
would be 11509*417083, or 4800208247. Anyway, it worked with QuickTime
Player so we can rule this out. It may not be a container problem after all
as I originally suspected, but an H264 decoder problem. If the file were
encoded as JPEG and not H.264 and it works, then the problem is codec
ffmpeg-user mailing list
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".