H264 is a modern standard for video compression. It is also known as MPEG-4 AVC (Advanced Video Coding) or MPEG-4 Part 10.
It is designed to deliver good video quality at very low bitrates, for instance for telephony systems, but also to scale very well at high resolutions and bitrates.
H264 repair is difficult because it is versatile, highly configurable and exposes very little data pattern.
To fix a corrupt video containing H264, it is often necessary, and always helpful, to have a good file similarly encoded. Even if the good file contains only a few frames, the fact that it was encoded with the exact settings of the damaged clip will provide useful information:
- Sample description (usually in the stsd atom)
- Pixel size
- Distribution of frames between I, P and B types, their approximate length in bytes (stsc, stsz, stss tables)
- Composition offsets, if used (ctts table)
- Distribution of blocks inside a frame
This information can be guessed from a broken H264 file, but through a very lengthy trial-and-error iterative process.
Nowadays, the majority of consumer and prosumer cameras use H264 or derivatives like AVCHD. The most popular H264 cameras are supported.
How to repair a corrupt H264 movie
The easiest way is certainly to ask our Movie Repair Service to help you recover the damaged footage.
But for those who can program, here you have a few tips:
To detect H264 media, the only simple technique is to look for a block length encoded in 32 bits.
For example, here you find three blocks, of length 0x0b, 0x9b and 0xb4.
0001ac0: b186 bb07 0000 000b 0600 0786 d330 8000 .............0.. 0001ad0: 0040 8000 0000 9b25 b820 2719 ffff 85a2 .@.....%. '..... 0001ae0: 8000 8037 d71c 0009 c7c4 6ad7 8b9f 5abd ...7......j...Z. 0001af0: 5eaf bd5f 7abe fbd5 f7ab efbd 5f7d f7de ^.._z......._}.. 0001b00: afbe 7f57 abef 9ff5 f7df 7df7 df7d f7cd ...W......}..}.. 0001b10: ab57 5d75 d75d 75d7 5d75 d77d 75df 2f7d .W]u.]u.]u.}u./} 0001b20: 75cd eaba ebbe baeb aeba ebae baeb a7ae u............... 0001b30: 4cfc 9c4f a939 3be4 e4e5 ef93 97be faef L..O.9;......... 0001b40: 89f5 7dbd 73fa 97be fbe4 e5ef 93be fbef ..}.s........... 0001b50: befb efbe faeb 15bd b272 f7c9 c9df 272f .........r....'/ 0001b60: 7c47 a97a ef93 befb e4ef aeba ebbe 5ef9 |G.z..........^. 0001b70: 3bf0 0000 00b4 2501 2ee0 809c 67ff fe08 ;.....%.....g...
This is reliable only if you can check that the data after the encoded length is another block of video or audio.
Usually one block represents one frame. It's not the case in the example above, where 4 to 9 blocks are needed for a frame.
The byte just after the length has interesting properties. Most common values are 0x06, 0x25, 0x01 and 0x21.
It can tell you something about the frame type (I, P, B) and the composition offset.
Note also that if a frame is made of several blocks, a constant value can help tracing where the frame starts and ends.
Once H264 frames have been correctly identified (data blocks, frame type, composition offset), the video can be repaired by reindexing.
More on bitstream structure: (from h264_parser source code)
Byte+4 (just after the block length) can be separated in 8 bits: 0xxzzzzz
xx encodes a value between 0 and 3 that is called idc_ref.
zzzzz encodes a value between 0 and 31 that tells what the block contains. 1 stands for progressive frame, 5 for I-frame.
Using h264_parser to parse H264 data:
QuickTime stores data differently, so you'll have to do a small conversion before movie data can be fed into h264_parser.
In stsd atom, after avcC, we have two chunks of data. The first one, of length 8 (in bold below), corresponds to ??? and the second one, until next atom stts, to "Sequence parameter set".
0000000: 6176 6343 014d 401e ffe1 0014 274d 401e avcC.M@.....'M@. 0000010: a918 1407 b600 d418 041a db0a d7bd f010 ................ 0000020: 0100 0428 ce09 c800 0000 1873 7474 7300 ...(.......stts. 0000030: 0000 0000 0000 0100 000a 8c ...........
To make it readable in h264_parser, add 00 00 00 01 in front, followed by 07 in case of second piece, followed by data, followed by 00 00 01 34 34 03, like this:
0000 0001 074d 401e a918 1407 b600 d418 041a db0a d7bd f010 0100 0428 ce09 c800 0000 0001 3434 03
For a block of data inside QuickTime mdat, replace the 4-bytes length by 00 00 00 01, and add 00 00 01 34 34 03 at the end.