On Wed, Oct 12, 2016 at 2:50 AM, Carl Eugen Hoyos <ceffm...@gmail.com>
> 2016-10-12 9:31 GMT+02:00 Thomas Worth <d...@rarevision.com>:
> > Has anyone actually looked at the MP4 file, BrokenVideo-8min.mp4?
> > It was written with a video track timescale of 0
> The uploaded file BrokenVideo-8min.mp4 has a video track timescale of
> 10000000, exactly as the input file from the conversion.
> (If I set it to 0, playback fails with every software.)
> > a track duration of 0 and due to that, outrageous packet durations.
> > Regardless of the quality of input (which I'm sure was bad), the muxer
> > should still be able to detect that something is obviously wrong. In this
> > case, the muxer should probably just fail with an error.
> > No reasonable person should expect MP4s written this
> > way to work correctly.
> The file works fine with every software tested so far except QT,
> this includes vlc, MPlayer, xine, GStreamer and WMP (which
> contrary to what was claimed here all use different demuxers
Upon closer inspection, there is definitely a problem. The 10000000 you are
referring to is in the wrong place in the video track's mdhd atom. mdhd
should be 32 bytes, according to the Apple specification for QuickTime,
which the MP4 file format is based upon. The mdhd in Alexey's file is 44
bytes. mdhd should look like this:
 //creation time
 //modification time
 //time scale
The mdhd atom in question is located at offset 12065154
in BrokenVideo-8min.mp4. The 10000000 is actually where language and
quality should be, and spans both fields. Then there's an extra 12 bytes at
the end of the atom.
I double checked this with a properly encoded MP4 file, and sure enough
mdhd for the video track was 32 bytes.
Just look at mdhd and you'll see what I'm talking about.
ffmpeg-user mailing list
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".