壊れたAndroidの動画を修復する

Androidのメディアスタックは、録画がいつ再生可能になるかを明確に定めています。キャプチャ中、MediaRecorder（あるいは MediaCodec と MediaMuxer を直接使うカメラアプリ）は、エンコード済みのサンプルを mdat に追記していきます。moov アトム（サンプルサイズ、チャンク（chunk）のオフセット、タイミングテーブル、そしてコーデックのパラメータセット）はメモリ上で組み立てられ、stop() と release() が実行されたときにのみファイル末尾へと書き出されます。この手順が飛ばされると、ディスク上のバイト列は頭のないMP4になります。本物のフレームはあるのに、地図がないのです。

原因となる中断は三つあります。カメラアプリがクラッシュした、またはシステムに強制終了された。 バグ、あるいはメモリ不足のもとでバックグラウンド／フォアグラウンドのアプリを回収するAndroidのlow-memory killer（低メモリキラー）が、stop() の前にプロセスを終わらせてしまうと、インデックスを書き込むものが何もありません。録画中にストレージが一杯になった。 4KのHEVCは書き込みが速く、内部ストレージやSDカードの空き容量がゼロバイトに達すると、muxerの書き込みが途中で失敗し、ファイルは moov のないまま切り詰められます。端末の電源が切れた。 キャプチャ中のバッテリー切れや強制再起動も、同じようにファイナライズを飛ばしてしまいます。

中身のコーデックは、HEVC/H.265（効率の高さから選ばれ、最近のAndroidの多くで高解像度モードの既定になっています）か、H.264/AVC（互換性のための代替）のどちらかです。コンテナの挙動はどちらも同一で、だからこそ修復の手順はコーデックに関係なく同じになります。

フレームのデータは mdat に残っているため、修復とは MediaMuxer.stop() が書き残さなかったインデックスを再構築することです。ツールは生き残ったストリームを走査し、各フレームの境界とタイミングを復元し、サンプルテーブルを作り直して、プレーヤーが先頭からデコードできるようにします。つまり、頭のないファイルを、シークできる通常のMP4へと戻すのです。ディスクが一杯になってファイルが切り詰められている場合でも、切断の前に完全に書き込まれたフレームをサルベージし、その周りに再生可能なコンテナを閉じます。そのため、あるテイクの80%を捉えたクリップは、全体が失敗するのではなく、その80%を返してくれます。これらすべては、ファイルがストレージから読み込まれるのに合わせて、あなたのブラウザ内で実行されます。

正直に言えば、限界は、中断の後に書き込まれるはずだったフレームが存在しないという点です。ディスクが一杯になれば書き込みは止まり、クラッシュすればエンコーダは止まり、そして一度も保存されなかったバイトを、どんなツールも作り出すことはできません。手元に切り詰められたコピーしか残っていないなら、サルベージが正しい選択です。ただし、元のファイルがまだ端末に残っていて、単純にきれいにコピーし直せるなら、まずそちらを試してください。良いコピーは、どんな修復にも勝るからです。

インデックスの再構築が最も確実になるのは、壊れたファイルが省いてしまった正確なコーデック設定をツールが把握しているときです。同じ端末で、同じアプリが同じモードで録画した正常なクリップは、まさにそれを提供してくれます。HEVCのパラメータセット（VPS/SPS/PPS）またはH.264のSPS/PPS、加えて解像度とフレームレートです。おかげで再構築は、近似ではなく元のとおりに再現できます。

実際には、同じカメラアプリと同じ画質設定で使い捨ての数秒を録画し、手元に用意しておいてください。コーデックを合わせておけば（HEVCのクリップにはHEVCのリファレンス、H.264にはH.264を）、修復が必要とするときにだけそれを求められます。別の端末や別のアプリのサンプルは、パラメータセットが異なるため、たいてい合致しません。