Like a lot of posts I see here, I had the 'SoS' problem with some of my video files. I didn't know about the 'press any button' trick at the time, and the camera didn't fix the files automatically later, so I was left trying to recover the video after the fact.

I examined the contents of the files and it was pretty clear that I had the raw video data preserved, but no header to allow the reading of it. With some known good sample files and a copy of the mp4 container spec, I was able to figure out enough to reconstruct the headers.

So I wrote a perl script to fix my damaged and unplayable video files(attached).

Edit: Here are more explicit instructions.

If you don't already have perl v5.8 or later on your computer, you will need to install that first.
ActiveState makes a good free version and you can get it here: http://www.activestate.com/activeperl/downloads
I also recommend installing VLC for video playback. You can get it here: http://www.videolan.org/vlc/download-windows.html

Once you have installed perl, you can confirm it is installed correctly by opening a command prompt window and giving the command:

Code: Select all

perl -v

You should see something like this:

Code: Select all

This is perl 5, version 12, subversion 1 (v5.12.1) built for MSWin32-x86-multi-thread
(with 3 registered patches, see perl -V for more detail)
...


To fix your file, I recommend crating a temporary directory to work in. C:\temp will do nicely
Copy your damaged video file(s) into this temp directory.
Download the .zip file attached to this post and unzip it. There is a single perl script (.pl) file inside.
Copy this perl file to the same temp directory as your videos.
Open a command prompt widow
cd to your temp directory (e.g. cd \temp)
Run the script with this command:

Code: Select all

perl fix_header_v3a.pl <file_to_fix> [-options]


Replace <file_to_fix> with the name of the damaged video file you are trying to repair
Replace [-options] with any of the following options:

Code: Select all

-reso Resolution      Sets the resolution mode the corrupt file was shot in.
                      Defaults to 720P30 'r2' if not specified
                      Valid values are 480p60, 720p30, 720p60, 960p30, 1080p30, r1, r2, r3, r4, or r5
-ctts N      Sets ctts offset to N. Defaults to 0 if not specified
             Use this to correct jerky playback in reconstructed video due to out-of-order frames
             Valid offsets are 0-2 for 720p30 'r2' & 960p30 'r4'; 0-5 for 720p60 'r3' & 480p60 'r1'


For example, if your damaged file is GOPR0001.mp4 and you took this file in 720P60 'r3' mode, you would enter

Code: Select all

perl fix_header_v3a.pl GOPR0001.mp4 -reso r3

If all goes well you will see output that looks like:

Code: Select all

Attempting to fix GOPR0001.MP4

Found frame 000252 at 0083b65b
Opened file GOPR0001.MP4.restore.mp4 for writing

Found 252 (fc) frames, or approx 4s of video at 60fps
   min size e2d, max size 30c4c
   from 8008, to 839b5c
Calculated header size of 0x8000
Using ctts offset of 0
Using 1280 x 720 @ 60 fps
Copying  frame 000252...
Done.


The script will create a new file with the same name as your damaged file with ".restore.mp4" tacked on the end. You should be able to open and play this file in VLC.

If the video plays back but appears very jerky due to out of order frames on playback, run the recovery script again using a different -ctts value until the recovered video looks right.

There will be no audio in the restored file, as the script is not smart enough to find lost audio at this time.

Please note:
This is quick 'n' dirty and not extremely robust code
It's non-destructive; it will copy the old data into a new file, so be sure to have plenty of disk space wherever you run it
It makes no attempt to recover the audio. The raw audio data is preserved, but I don't know enough about Mp4/AAC to recover it.
It will not help at all with filesystem errors (e.g. you can't move or copy your file)

hey, thanks for this. trying to use it but no luck so far. downloaded/installed strawberry perl for windows. running the script on a 2.39 gig file and it just sits there on:

Attempting to fix gopro_sess3.mp4
Opened file gopro_sess3.mp4.restore.mp4 for writing

how do I know if it's actually doing something? how long before it prints any progress text? my file was captured in r2 mode 720p30... as you described, got the sos message but didn't know to press a button. I actually did press both buttons but when they didn't seem to do anything I pressed the front button until the camera powered down.

thanks!

If it sets stuck there, that means that the script did not find an 'mdat' section in the original file.
To get an idea of what the output looks like and how quickly it runs on your machine, try running it with a known good mp4 file.

Your files may be corrupted in a different way than mine were. Can you get a file splitter utility, split off the first 100MB or so and host that somewhere? I'll take a look and see if it appears to be recoverable.

hey thanks for the reply!

I tried the script on a different corrupt file I had and it worked on that one so I've now seen how the output looks when it's working. I don't really understand the script but it seems like it scans the file for "mdat". I would assume that when it gets to the end of the file without finding it the script would stop. however, it seems if "mdat" is not found the script loops forever... is that the expected behavior?

anyway, I split the file it doesn't work on and put the first 100mb of it here: http://asifnyc.com/images/ the file is gopro_sess3.mp4.001 right click on it and select "save link as" to save it to your hard drive.

appreciate any help you can provide.

Yeah, it scans the file looking for the video data section and then looks in there for frame data. This worked for me because my corrupt files all had intact box structures, just no headers. On this file you sent me, you actually have header data, but it looks like portions were overwritten - one of the overwritten sections was the 'mdat' tag the script was looking for. So the script hung because it expected to find that but didn't. Hey, I said this was a quick 'n dirty script

I made a new version that skips looking for 'mdat' and just brute force looks for frame markers. This should keep it from getting stuck like that if there's no 'mdat' marker. I also added a feature to adjust the ctts pattern offset. This is necessary if the first frame recovered is not the beginning of the GOP. If you don't know what any of that means don't worry. You should ignore it unless your recovered video looks very jerky/stuttery due to out-of-order frames on playback. If it does, try recovering with ctts offset 1 or 2 to find the setting where it looks smooth.

Edit: See later version of script down below

So how was your weekend at infineon? I'd love to go drive there some day.

you sir.... ROCK!

it worked... very happy. footage is from this past Monday at Infineon. it was a blast. thanks again. it's really awesome to be able to salvage this footage. the silver car in front is a friends and it's the only time it has (or will) be on track so I was completely bummed when the file turned out to be corrupted.

Your script seems to be what I need to fix my "broken" gopro files. However, my video was recorded at 960p 30 fps. So, my files are now at least recognizable by the video player (Quicktime in this case) but the video is just black.

How difficult do you think it would be to modify the script to handle 960p? I have not looked at the script extensively yet, but I am a software guy, so if you point me in the right direction I could probably make the modifications. Also, I assume you have the MP4 file format spec, that would help too.

I think your script could become a very useful tool for a lot of people here. Thanks for taking the time and making the effort to develop it and putting it out there for general use.

Of course, any changes I make will be posted back so others can take advantage too.

Larry

Larry,

I suspect all that needs to be changed is the relevant fields in the header that contain the width and height info. Let me take a look at some good 960p30 video from my camera and I'll let you know.

If you're curious, I found the MP4 container spec here: http://neuron2.net/library/avc/c041828_ ... 28E%29.pdf

I looked at sample file of each of the recording modes, and I've modified the script to support them all. It ended up needing more than just a size field change. It's interesting that the modes don't all use the same overall structure, but I think I've got the most important differences captured now.

It appears to be working for all modes with a quick test here, but some of the modes are less exact header reconstructions than others, so you might see some oddities that I didn't notice.

command line is now:

perl fix_header_v3a.pl <file_to_fix> [-options]

where options are any of:
-ctts N Sets ctts offset to N. Defaults to 0 if not specified
Use this to correct jerky playback in reconstructed video due to out-of-order frames
Valid offsets are 0-2 for 720p30 'r2' & 960p30 'r4'; 0-5 for 720p60 'r3' & 480p60 'r1'
-reso Resolution Sets the resolution mode the corrupt file was shot in. Defaults to 720P30 'r2' if not specified
Valid values are 480p60, 720p30, 720p60, 960p30, 1080p30, r1, r2, r3, r4, or r5


Note that I had to change the way ctts offsets are used, so non-zero ctts offsets don't match the behavior in v2

Edit: V3a gets rid of the 'grey screen lead-in' issue with a fake stss table.

tchiers,

I really appreciate the time and effort to modify the script. Unfortunately, I may have something more wrong with my files than you did. I still get an output file that can be recognized by the video player, but the video is still just all black. I'm not sure what is going on there. It's very disappointing as I've lost 75 minutes of video from a weekend driving school and only have one 5 minute file that works.

If you have any other ideas or thoughts I'd love to hear them.

- Larry