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

[Michael Niedermayer]

On Tue, Dec 06, 2011 at 09:29:47AM +0200, Mihnea Balta wrote:
> 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.

patch applied, thanks

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20111206/9d3e5f21/attachment.asc>