[FFmpeg-devel] Bad computed size for atoms with size 0 in MOV files

[Mihnea Balta]

Hi.

I've posted this as ticket #708
(https://ffmpeg.org/trac/ffmpeg/ticket/708) but I was instructed to
post here too about it, so I'll repeat the problem.

I have a MOV file written by a lazy program which can't be bothered to
compute the size for the 'chan' atoms it writes, so it just places
them at the end of the 'stsd' atom and writes 0 in the size field. I
don't know which program it is, I just have the resulting file.
According to the spec, size 0 is only allowed for top-level atoms, so
strictly speaking the file is malformed, but I see that most parsers
(Quicktime included) do not enforce this restriction and take size 0
to mean "extend to the end of the parent atom" instead of "to the end
of the file". Ffmpeg does this too, but I think there's an error in
the computation. Inside the function mov_read_default() in
libavformat/mov.c you have this (slightly edited to show the relevant
code path):

a.size = avio_rb32(pb);
a.type = avio_rl32(pb);
total_size += 8;
if (a.size == 0)
    a.size = atom.size - total_size;
a.size -= 8;

The computed size doesn't contain the header size because it's already
skipped by incrementing total_size, but then it's skipped again in the
last line. The atom comes out 8 bytes short and the function
mov_read_chan() aborts the whole parsing process. I think the computed
size should be atom.size - total_size + 8.

The ticket contains a MOV file which reproduces the problem. cehoyos
committed a change (a448a5d1c4620aa58ec138fbffd46d18d42d53e0) which
makes ffmpeg ignore short 'chan' atoms, so the file doesn't fail
anymore, but the root cause remains. With the patch from cehoyos, the
read position is wrong after mov_read_chan() returns, but since it's
only off by 8 bytes and the offending atom is, by definition, at the
end of the parent, the parser ignores the "extra" bytes and continues
correctly. However, atoms with size 0 will still fail to parse, or
will be incomplete.

The attached patch should fix the problem, please take it into consideration.

Thanks,
Mihnea

PS: the 'chan' atom in that particular sample file seems broken, but
at least it has all the required fields, so it should be parsed
correctly and ignored. Quicktime, VLC and even Windows Media Player
are able to play the file.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mov.patch
Type: application/octet-stream
Size: 369 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20111206/12995e07/attachment.obj>