[FFmpeg-trac] #708(undetermined:new): Bad computed size for atoms with size 0 in MOV files
FFmpeg
trac at avcodec.org
Mon Dec 5 13:12:56 CET 2011
#708: Bad computed size for atoms with size 0 in MOV files
-------------------------------------+-------------------------------------
Reporter: mihnea | Type: defect
Status: new | Priority: normal
Component: | Version:
undetermined | unspecified
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
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.
I've attached a sample MOV file which can be used to reproduce the error.
Just do {{{ffmpeg -i audio.mov -vn -acodec copy test.mp4}}} and ffmpeg
will say "error reading header". If you apply the proposed patch, the file
works correctly.
PS: the value of the layout tag in the 'chan' atom is 24, which doesn't
correspond to anything. I don't know what the authoring program meant by
that, but at least it wrote all 3 required fields, so the file can be
parsed.
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/708>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list