Crash Resilience & fMP4 File Recovery

Hardware crashes, sudden power outages, or kernel panics can interrupt in-progress recording files mid-write. In traditional video surveillance systems, an interrupted MP4 file is completely unreadable because the trailing index (moov atom) was never finalized.

RUSEON Core solves this with Fragmented MP4 (fMP4) container architecture and an automated Startup Crash Recovery Service (internal/recorder/recovery.go).

---

The Integrity Validation Engine (ValidateFMP4File)

During startup and before indexing, the recovery service performs deep structural box inspection on each recording file:

1. Minimum Size Threshold: Verifies that the file is at least 32 bytes (minimum possible header size for ftyp + moov).
2. Box Boundary Verification: Traverses every top-level atom (ftyp, moov, moof, mdat, mfra) and confirms box.offset + box.size <= fileSize.
3. Trailing Byte Cleanliness: Ensures the file terminates exactly on a box boundary without incomplete or garbage trailing bytes caused by abrupt power loss.
4. Header Sanity: Confirms the presence of a valid initialization block (moov) containing valid trak and mdia descriptions.
5. Media Presence: Verifies that at least one complete media fragment (moof + mdat) is present.

---

Automatic Truncation & Atom Repair

When an abnormal shutdown leaves an unclosed fragment at the end of an .mp4 file:

[ ftyp ][ moov ][ moof #1 ][ mdat #1 ][ moof #2 ][ mdat #2 ][ moof #3 ][ mdat #3 (interrupted!) ]
                                                            ▲
                                                 Truncation boundary

1. The recovery parser identifies the exact byte offset where the last healthy mdat atom completed.
2. The file is cleanly truncated using os.Truncate(filePath, lastValidOffset).
3. The resulting file is 100% compliant with standard ISO BMFF specifications and can be decoded by any standard player (VLC, FFmpeg, Chrome, Safari, iOS).
4. Zero Video Loss: All recorded video up to the last flushed keyframe is preserved.

---

Startup Recovery Workflow

When RUSEON Core boots:

1. It automatically inspects active temporary files from the previous session.
2. Runs ValidateFMP4File on any unclosed recordings.
3. Automatically repairs and renames valid files to their final {start}_{end}.mp4 naming scheme.
4. Updates the BadgerDB archive timeline and generates the sidecar index (.idx).

Related Documentation

• Archive Overview
• fMP4 Recording Mechanics
• Storage File Layout
• Troubleshooting Corrupted MP4
• Page Cache Thrashing Deep Dive