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

[Marc MERLIN]

On Sat, Feb 27, 2010 at 07:09:09AM +0100, Reimar Döffinger wrote:
> > > 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).

Oh my, it took me over an hour to manage that with some crude tools
(midnight commander for hex viewing and vi -b for cut and paste :) ), but
thanks to your detailled info, it worked!!!

Hopefully I won't have to do this again, but do you have a good binary
editor with block cut/paste that you recommend for a case like this?

Thank you.
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/