[FFmpeg-trac] #708(undetermined:new): Bad computed size for atoms with size 0 in MOV files

[FFmpeg]

#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