The Everest of movie repairs

From time to time, I receive an Everest-class repair.
Mount Everest, the highest summit on earth, can barely be climbed by men. Only an elite of alpinists can reach the 8848m without help of oxigen.
In some way, it is measuring the capacity of humans. A bit higher and it would be physiologically impossible to climb.

Similarly, every two or three months, I receive a movie repair that is at the edge of impossible. It has this rare quality of being too damaged to be repaired with known techniques, but at the same time I foresee that there is a small chance that a new technique may fix it.

Officialy, I don’t call it Everest-class, but rather Investigative Repair, to convey to the customer three important ideas:
– I have to develop something radically new. A unique solution for a unique case.
– it’s gonna be expensive (I charge usually one order of magnitude more for those repairs)
– at the end, I can come to the conclusion that the repair is impossible. Results are not guaranteed.

I do such repairs primarly to challenge my repair ability and to push the enveloppe of the discipline. As boring as repairing movies may seem, an Everest-class repair is when there’s adventure, struggle and achievement.

The last Everest-class repair came last month: Canon EOS 5D Mark II files with some bitstream corruption. Mr Szot, the polish director, did not notice the problem until the production was finished. The clips, needed for a 15 minutes short movie called “An Exclusive”, could not be shot again.

I observed around fifty defects in a dozen of files. The footage is encoded in H264, where one wrong bit can propagate nefarious effects over a dozen of frames. Even with “creative editing”, it would be impossible to tell the story: For some important takes, the footage was unusable.

In 99% of the repairs, the problem consists in re-indexing the clip: Audio and Video media is fine but the “table of contents” that tells where the data for each frame, is missing.
But here, it’s the opposite. The table of contents is fine, but the media is corrupt.

Not that corrupt, according to real world standards, since the amount of bad data is only 1 for 100 millions. Like a rare disease that would affect just 70 people in the world population. The typical needle-in-a-hay-stack problem. Change needle for bits and haystack for a file with one billion bits and you get the idea.

Bits Flipping Party

The repair technique lies on a simple idea: when decoding the frame, the wrong bit will cause errors and exceptions that eventually stop the decoding process. That is what we observe in a defective frame: the top is ok, then something occurs, then the rest of the frame is not decoded.
The location where it stops should be close to the wrong bit. Never before, at a short distance after.
From here, we will go backward and flip the bits one by one, until we get something that decodes without error.

I made a bold assumption here: that wrong bits are extremely rare. So rare that we can consider that there is only one wrong bit involved in every decoding error.
I had nothing to really back this assumption: If it’s true, we would be able to repair. If it’s wrong, it would be impossible. Checking the assumption thus became a priority before engaging into time consuming developments.

There’s a second assumption: The distance between the wrong bit and the error is small.
One iteration will be needed for every bit, and iterations are slow since they decode several video frames each. Not just one frame, but the whole group from the I keyframe to the damaged frame. That can take several seconds, so if we have thousands of iterations, it would become impracticable.

Prototype and Automation

I assembled a prototype from various pieces, an open-source H264 decoder, a couple of small programs to flip bits and to detect errors and generate pictures from potentially successful iterations.
I tried it on a first defect, a slow process since almost everything had to be done by hand, and results have to be carefully interpreted.
When I finally managed to get a good picture out of the prototype, it was unbelievable. I had found the needle.

Since I had almost fifty defects to fix, I spent some time automating the process. At the end, I would only have to send a few command-line commands, choose manually the starting point of the search, and launch it.
The computer would run for minutes, sometimes hours, until it starts spitting pictures.
I had to review the pictures one by one, until I could find one that was perfect.
Then, I would modify by the wrong bit in the movie and verify that it fixed the frame and also the rest of frames in the “Group of Pictures”.

In some cases, fixing a frame would just unveil a defective one a few frames later. Just as one train may hide another…

Finally, I managed to clean completely all but one defect. This was quite a surprise. I would never have anticipated such a desperate repair attempt to work with a 98% success rate.

My customer, Mr Szot, is happy. His film “An Exclusive” will be presented this week to the polish public.