[FFmpeg-devel] [PATCH] [PATCH] libavformat/mov.c: Skipped duplicated MOOV atom

[Robert Krüger]

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
> applied
>
> Thanks
>
> [...]
> --
> 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
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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