incomplete mp4 repair

[movmasty]

Is there any free simple tool to repair incomplete mp4 and make them playable??

A divxfix for mp4 in short.

[LoRd_MuldeR]

If with "incomplete" you mean that the moov atom is missing, I don't see much hope. That's because in MP4 all video frames and all audio frames are store in one big continuous data block, the mdat atom. And only the "raw" data is stored there, so there are no additional headers or anything, like there would be in a transport stream. To make things even worse, audio and video frames are stored in an interleaved way, but you don't know in which pattern they are interleaved. Only way to figure out where a specific frame starts (and how long it is) is reading the tables (stco, stsz, etc), stored in the moov atom. For the same reason MP4 files are not "streamable" if the moov atom is stored at the end of the file...

To make a long story short: Without moov atom it will not be possible to recover the data from the MP4 file, except maybe by using some "forensic" methods...

[movmasty]

Thanks LoRd, but you give not hope.

For incomplete i mean LEGAL FILES from P2P
you cannot preview what you are receiving
Why to store the atom at the end????????

And why mp4 is worst than avi for this?
When old mpg didnt have any of these troubles!

Then someone ask me why i like avis+VirtualDub :rolleyes:

[LoRd_MuldeR]

Why to store the atom at the end????????

Because it's more easy to do. The file is written from the beginning to the end. And until you have written the complete audio/video data, you simply don't know the final frame positions and sizes, i.e. you cannot write the moov atom first. But it's straight forward to just append the moov atom when you are done with everything else. "Moving" the moov atom to the beginning of the MP4 file usually requires a second pass, i.e. the whole file needs to be written again. Also, unless you are streaming (or doing a "porgressive download") it doesn't matter much! And when you are streaming, the MP4 file can be prepared accordingly (moov atom to the beginning). If users don't do that, it's not to blame on the MP4 format.

And why mp4 is worst than avi for this?

To reduce overhead. MP4 stores all information as compact as possible. It avoids additional headers, if the same info can be derived from the moov atom. Even the table encoding is very "compact".

AVI also had an "index" block at the very end of the file, which was required for (reasonably fast) seeking. But still each frame was encapsulated in it's own RIFF chunk, which made "rebuilding" the index more straight forward.

When old mpg didnt have any of these troubles!

Because it was a simple transport stream format, where each frame starts with a header/syncword - and thus seeking in a frame-accurate way was pretty much impossible (except by scanning/indexing the complete file).

[pcordes]

It looks like there is a tool for this, but maybe only usable if you have a sample complete mp4 produced by the same device. So this is probably only very useful for recovering what's left if your phone / camera crashes or loses power mid-recording.

I assume it just uses the moov atom from the reference file, and hopefully a/v is interleaved the same way in the file you're repairing. It might have more smarts, like looking at the A and V bitstreams that would result, to see if their headers look valid.

http://muzso.hu/2012/11/14/how-to-fix-a-broken-mp4-mov-video-ffmpeg-reports-moov-atom-not-found

I never output to mp4 unless I have to for compat with HTML5 video or something. mkv has only a tiny fraction more overhead than mp4's best case, but stores enough stream info at the front of the file to be playable before its fully written. It also handles more codecs (e.g. Opus) than mp4, and has good support for subtitle streams.

Apparently ffmpeg has a -f ismv muxer, as an alternative to the default mp4 muxer, that puts a moov atom at the beginning, so your file is usable no matter what happens. Someone in the comments on the page I linked mentions it.

[StainlessS]

Cant remember what it is called, but there is some kind of setting for bitTorrent's that forces download of last few blocks of file
right at the beginning of the download. (at least in the standard BitTorrent and uBitTorrent clients).
EDIT: Dont know how big the moov atom is likely to be.

EDIT: And the persona-non-grata PotPlayer is the most error resilient player that I am aware of, can also capture
and save from some broken files, although it may actually edit the files so if part of a download might want to
make copy of file try to play copy. (Think that GOM also edits file contents when trying to play broken files).

[pcordes]

Cant remember what it is called, but there is some kind of setting for bitTorrent's

yup, most BT clients have a prioritize first/last pieces of each file setting. IIRC, usually annoyingly-muxed files (with the moov atom at the end) will play as long as you have the last megabyte or so, and also enough of the beginning to get the stream headers. And then for most codecs, mpv or mplayer will either fast-forward through the all-zero parts, or let you seek through them, until you get to something that's playable.

With mplayer, AAC audio and AVC video, toggling audio off and then on again (# key to cycle audio streams) will make the A/V sync code pick up at the start of the next valid part of the file, if it got out into a still-unwritten all-zero part of the file.

mpv seems to just need a right-arrow seek, but I haven't used it as much. (just switched recently, since it gets a lot more things right than mplayer. e.g. colormatrix based on h.264 stream flags, with fallback to rez-based bt.601 vs. bt.709).

You have to be careful with fullscreening them, since you occasionally have to blindly tab back to your terminal window and ^c if they get stuck the wrong way. Although I don't think I've had that happen for a while. (I use fluxbox; Maybe with a compositing window manager you wouldn't have this problem. And windows can always ctrl-alt-delete.)