fMP4 Recording & Linux I/O Architecture

The recording engine in RUSEON Core (internal/recorder/) delivers reliable, high-throughput video archiving for continuous 24/7 camera operations. Unlike traditional NVRs that produce monolithic MP4 files requiring an end-of-file moov index atom, RUSEON packages video exclusively into Fragmented MP4 (fMP4) containers.

---

1. Why Fragmented MP4 (fMP4)?

Standard MP4 files write video data sequentially to an mdat atom, but write the index table (moov atom) only when the file is finalized upon closing. If power is interrupted or the process terminates abnormally, the unfinalized MP4 file becomes completely unreadable and corrupted.

With Fragmented MP4:

1. An Initialization Segment (ftyp + moov) is written at the very beginning containing codec parameters (H.264 SPS/PPS or H.265 VPS/SPS/PPS).
2. Video is continuously written as a sequence of independent Movie Fragments (moof atom followed by mdat payload).
3. Each fragment represents exactly one GOP (Group of Pictures) starting with a KeyFrame (I-Frame).
4. If a server loses power unexpectedly, every completed fragment written to disk remains 100% valid and playable.

---

2. Linux Kernel Page Cache Eviction (CacheDropper)

When archiving dozens or hundreds of high-bitrate cameras, the operating system's standard write-buffering behavior can cause severe system degradation:

1. Page Cache Thrashing: The Linux kernel fills physical RAM with dirty writeback pages.
2. I/O Wait Freezes: Flushing gigabytes of dirty buffers blocks storage controllers.

RUSEON Core solves this in internal/recorder/recorder.go via direct cache eviction:

// 1. Write fMP4 part to disk
_ = part.Marshal(file)

// 2. Instruct Linux kernel to drop cached video pages from RAM
if dropper, ok := file.(registry.CacheDropper); ok {
    _ = dropper.DropCache()
}

• unix.SyncFileRange(fd, offset, length, unix.SYNC_FILE_RANGE_WRITE): Initiates non-blocking background writeback of dirty pages without stalling the calling goroutine.
• unix.Fadvise(fd, offset, length, unix.FADV_DONTNEED): Hints the Linux kernel that the written pages will not be read again soon, allowing the kernel to instantly reclaim RAM.

---

3. Rotation & File Lifecycle

Recordings are automatically rotated every 1 hour on KeyFrame boundaries:

• Active File: recordings/{camera_id}/2026-08-23_15-04-05_ongoing.mp4
• Finalized File: recordings/{camera_id}/2026-08-23_15-04-05_to_16-04-05.mp4
• Recovery on Startup: Any unfinalized .crashed or .ongoing files are scanned and recovered by cmd/server/main.go.

---

4. Configuration Example

server:
  record_retention_days: 14  # Global retention days (0 = no cleanup)

cameras:
  - id: "cam-01"
    url: "rtsp://admin:pass@192.168.1.100:554/live"
    record: true
    retention_days: 7       # Override retention for this camera

Related Documentation

• Archive Overview
• Storage File Layout
• Page Cache Thrashing Deep Dive
• Crash Recovery Guide
• Recording Configuration Reference