-moov_size option causes MOV file structure to be corrupted

[rling]

Summary of the bug:
Using the -moov_size option causes a 'free' atom to be added to the MOV file immediately after the 'moov' atom. The 'free' atom's size field is wrong, corrupting the file.
How to reproduce:

1. Encode a MOV file, determine required size of 'moov' atom by using a very small -moov_size:

   % ffmpeg -y -i input.MOV -moov_size 1 output.MOV
   ffmpeg version N-64667-gd595361 Copyright (c) 2000-2014 the FFmpeg developers
     built on Jul 14 2014 22:02:04 with gcc 4.8.3 (GCC)
   [...]
   [mov @ 04865620] reserved_moov_size is too small, needed 6135 additional.
   [...]
   

2. Required size is thus 6136 bytes. Use -moov_size option to require 'moov' atom to be 20 bytes larger than required size:

   % ffmpeg -y -i input.MOV -moov_size 6156 output.MOV
   

3. Examine output.MOV with a hex editor and look for the 'free' atom between the 'moov' and 'mdat' atoms:

   017e00a 5d 6e 00 00 00 21 75 64 74 61 00 00 00 19 a9  .]n...!udta....©  
   017f073 77 72 00 0d 55 c4 4c 61 76 66 35 35 2e 34 37  swr..UÄLavf55.47  
   018002e 31 30 30 00 00 00 1c 66 72 65 65 00 00 00 00  .100....free....  
   0181000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................  
   0182000 00 00 00 00 00 00 00 00 0a 4a 9b 6d 64 61 74  ..........J.mdat  
   0183000 00 02 ae 06 05 ff ff aa dc 45 e9 bd e6 d9 48  ...®..ÿÿªÜEé½æÙH  
   

The atom's size field has been set to the size of the content only (28 empty bytes), NOT including the 8 bytes for the header itself. The size should include the 8 bytes for the atom header. The MOV file is thus corrupt and cannot be parsed correctly with normal tools.

[rling]

Appears to be related to these lines near 4394-4402 of libavformat/movenc.c:

size = mov->reserved_moov_size - (avio_tell(pb) - mov->reserved_moov_pos);
[...]
avio_wb32(pb, size);
ffio_wfourcc(pb, "free");
for (i = 0; i < size; i++)
    avio_w8(pb, 0);

The code appears to write size as the atom's size, then write 'free' as the tag, then write size bytes as the atom content. This is a violation of atom structure.

[Carl Eugen Hoyos]

Are you planning to send a patch created with git format-patch to the ffmpeg-devel mailing list?

[rling]

Sorry, I don't have a checkout and am too time poor to contribute. I'm also not sure whether the fix is to increase the size field by 8 or to reduce the number of bytes written by 8. Will have to leave it to the experts.

[Carl Eugen Hoyos]

Which tool cannot parse the output file with the incorrect free atom?

[rling]

It's my very simple in-house tool. My tool correctly parses input.MOV, which is direct from a Canon G15 camera and also contains a 'free' atom, but fails on the output.MOV generated with the command line above.

WMP and MPC-HC were able to play output.MOV, and Windows displayed a normal thumbnail for it. I think many media players may only read up to the 'moov' atom, which itself contains absolute file offsets into the 'mdat' atom, which allows them to display and play the file without ever reading the 'free' atom. So I'm not surprised this bug could hide for a long time.

[Carl Eugen Hoyos]

Should be fixed in 0e70266b - thank you for the report!