[MEncoder-users] Need help fixing/decoding a recovered h264 file

[Reimar Döffinger]

On Fri, Feb 26, 2010 at 01:40:54PM -0800, Marc MERLIN wrote:
> > Not it is trivial for FAT. For every cluster of the file that was not overwritten the
> > FAT still contains the next cluster address.
> 
> Oh, good. I'm not sure why photorecovery is having issues recovering then.

I was wrong about that part, I misremembered, this only works when the main directory
somehow was damaged, but not for intentionally deleted files.

> > We are talking about FAT, right? FAT has no mechanisms to avoid fragmentation,
> > and for FAT32 the directories themselves are ordinary files, so it is never
> > very likely they are in order.
>  
> I thought that on an empty filesystem, FAT would just allocate blocks in
> order, since why not? (and I do delete all the files before each recording,
> so the filesystem should be empty).

Actually, the device does write the file in order. It just has the problem
that it doesn't know the size of the index beforehand - the trick it uses is
to not write the index at all and only splice it in afterwards using some FAT
magic.
Thus the file layout is:
- mov file header
- file data
- index-related part of the header.

What you need to do is move the data from offset 40eb7200
(start of block containing lots of 00 00 01 00 00) to 40eff200 (end of block containing the string #free)
on the SD card in-between the mmov header and mdat blocks (mdat block starts at 22287200).