Bad computed size for atoms with size 0 in MOV files
|Reported by:||Mihnea||Owned by:|
|Blocking:||Reproduced by developer:||no|
|Analyzed by developer:||no|
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.
Change History (8)
comment:4 by , 10 years ago
|Component:||undetermined → avformat|
|Status:||new → open|
|Version:||unspecified → git-master|