Corrupt MP4 [recording interrupted]

Question

I was recording an MP4 file using PlaysTV, and my computer had a power fault half-way through the recording. I'm sure that the file contains valid data, it's just that no media player will recognize it.

To fix it I have tried Avidemux, I have tried numerous programs listed in other questions on stackexchange. And so far nothing has worked.

The ffmpeg -i output is as follows:

  libavutil      55. 24.100 / 55. 24.100
  libavcodec     57. 43.100 / 57. 43.100
  libavformat    57. 37.100 / 57. 37.100
  libavdevice    57.  0.101 / 57.  0.101
  libavfilter     6. 46.100 /  6. 46.100
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc    54.  0.100 / 54.  0.100
[mov,mp4,m4a,3gp,3g2,mj2 @ 000000000262d040] moov atom not found
2016_05_27_20_08_12-ses.mp4: Invalid data found when processing input

Mediainfo output:

General
Complete name                            : F:\vids\2016_05_27_20_08_12-ses.mp4
Format                                   : MPEG-4
Format profile                           : Base Media / Version 2
Codec ID                                 : mp42 (mp41/isom)
File size                                : 1.21 GiB

There are probably paid services that will fix this file for me, however since it is a (quite)large-ish file, they cost too much.

Can anyone help me here?

Answer 1

I recently encountered this exact problem and I was able to repair the file using Untrunc, a program created specifically to solve this problem, as suggested by sparrowt on SuperUser:

For this method you need:

• another video file which isn't broken

• a linux installation (I used Ubuntu 12.04) and basic ability to use a command line.

This is what to do:

1. Install some pre-requisite libraries with this command:

   sudo apt-get install libavformat-dev libavcodec-dev libavutil-dev

2. Download the source code for Untrunc from the github repo:

   wget https://github.com/ponchio/untrunc/archive/master.zip

3. Unzip the source code:

   unzip master.zip

4. Go into the directory where it's been unzipped:

   cd untrunc-master

5. Compile the source code using this command (all one line):

   g++ -o untrunc file.cpp main.cpp track.cpp atom.cpp mp4.cpp -L/usr/local/lib -lavformat -lavcodec -lavutil

   (you can try skipping this step and using the ready-provided executable, but it didn't work for me)

6. Then you can actually fix the video. You need both the broken video and an example working video.

   Ideally the video should be from the same camera & have the same resolution (mine was but it might work without). Also if it is at least as long as the broken one (preferably roughly the same) this may help.

   Run this command in the folder where you have unzipped and compiled Untrunc but replace the /path/to/... bits with your 2 video files:

   ./untrunc /path/to/working-video.m4v /path/to/broken-video.m4v

   Then it should churn away and hopefully produce a playable file called broken-video_fixed.m4v

That's it you're done!

VLC Media Player should now be able to play the file. However it may be reporting the wrong length information (Untrunc tries to guess/work this out, but doesn't always get it right). To fix this try re-encoding the video through another program.

Answer 2

Updated: this tool can now recover files from more sources.

Try with recover_mp4_to_h264. It's a command line program, and will require a good reference file.

Usage as indicated:

recover_mp4 in_good_similar.mp4 --analyze
recover_mp4 in_corrupted.mp4 {out_video.h264 | out_video.hevc | --novideo} [out_audio.aac | out_audio.wav | out_audio.mp3 | out_audio.raw | --noaudio] [options]

Answer 3

You may also, to save yourself trouble, check to see the data is even there first. The file size being 1.21 GB, does that sound correct for the time until you lost power?

I bring this up because some programs write the data first to memory... sometimes very long large chunks of data, before actually committing it to disk.

With an MP4, the video should play, if it has valid headers, up until the last good packet containing the correct key/i frames.

What pops into my head, is the data may not be there, as in, it had been committed to memory, but not to disk-- I'd do a test record (factoring the time it "should be", and compare file sizes). Before you jump through hoops.