[FFmpeg-user] Developer "cehoyos" closed my bug without any explanation, and without solving it

[Carl Eugen Hoyos]

2016-10-12 16:03 GMT+02:00 Thomas Worth <dev at rarevision.com>:
> On Wed, Oct 12, 2016 at 2:50 AM, Carl Eugen Hoyos <ceffmpeg at gmail.com>
> wrote:
>
>> 2016-10-12 9:31 GMT+02:00 Thomas Worth <dev at 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.

[...]

> 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.

You are of course right that isom is based on mov but you
are missing two (important) things:
There is a difference between mov and isom.
Alexey told us that he needs QT compatibility but he told
FFmpeg that he absolutely doesn't care about QT, he
requested an isom file (and that's why FFmpeg did not try
to create a QT-compatible file and did not warn that the file
is not QT-compatible).

> The mdhd in Alexey's file is 44 bytes. mdhd should look
> like this:
>
> [0000] //size
> [0000] //'mdhd'
> [0]    //version
> [000]  //flags
> [0000] //creation time
> [0000] //modification time
> [0000] //time scale
> [0000] //duration

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.

Thank you for finally solving the question why QT fails!

Carl Eugen