[FFmpeg-devel] [PATCH] [PATCH] libavformat/mov.c: Skipped duplicated MOOV atom
dave at dericed.com
Fri Jul 12 15:53:28 CEST 2013
On Jul 12, 2013, at 4:05 AM, Robert Krüger wrote:
> On Fri, Jul 12, 2013 at 2:57 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> On Thu, Jul 11, 2013 at 02:37:59PM -0700, Thierry Foucu wrote:
>>> This should fix ticket 1378
>>> If we have parsed a moov atom, and found another one, just skip it.
>> i hope this has no sideeffects
>> but i guess only one way to find out
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>> I have never wished to cater to the crowd; for what I know they do not
>> approve, and what they approve I do not know. -- Epicurus
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
> Well, the big question here is, whether to use the first or the last
> one as the valid moov atom. While your fix is probably the easiest, I
> would guess, that in cases where e.g. a capturing application keeps
> rewriting moovs from time to time (and then relabeling the old moov to
> free) and crashes before changing the previous moov atom to free (I
> have seem files like this in the wild at least they were from
> capturing applications and the explanation made sense for their atom
> structure), you would make data inaccessible to ffmpeg that would be
> there otherwise.
I'm testing the patch now. I used the sample on the ticket in QuickTime Pro 7 and QuickTime X. In each case QT uses the first moov as does mediainfo. Exiftool does seem to use the last moov.
When I compared the first and second moov of the sample I see that the first moov has two mvhd atoms while the second moov only has one mvhd. QuickTime 7 and QuickTime Pro use the second mvhd atom of the first moov. For the record the second mvhd of the first moov is almost identical to the only mvhd of the second moov (except for adding a uuid that is copied in the first mvhd of the first moov).
So my opinion would be to replicate Apple's parsing done in QuickTime Pro and use the last mvhd of the first moov.
> Unfortunately the spec does not say anything about
> that and it does not seem to be the only case were this might happen
> (see http://comments.gmane.org/gmane.comp.video.libquicktime.devel/1747).
> So it is a bit of gambling on statistics. Although I would say it is
> better to have it fixed as it is now and wait until someone complains
> that their mov files appear truncated (or are missing some metadata
> like in the referenced case) rather than having the tracks appear
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel