Recording Pipeline & fMP4 Serialization Architecture
The Recording Pipeline (internal/recorder/) is engineered for 24/7 sustained video archiving. It converts raw video frames from the Ring Buffer into ISO BMFF compliant Fragmented MP4 (.mp4) files.
1. Fragmented MP4 (fMP4) Box Structure
Traditional MP4 files store an index (moov atom) at the very end of the recording. If power is cut mid-write, the file cannot be opened.
RUSEON Core writes Fragmented MP4 files composed of independent fragments:
┌────────────────────────────────────────────────────────────────────────┐
│ Initialization Segment │
│ [ ftyp: isom/iso6/mp41 ] [ moov: trak / mdia / minf / avcC|hvcC ] │
├────────────────────────────────────────────────────────────────────────┤
│ Movie Fragment #1 (GOP 1) │
│ [ moof: mfhd / traf / tfhd / tfdt / trun ] [ mdat: Video NALUs ] │
├────────────────────────────────────────────────────────────────────────┤
│ Movie Fragment #2 (GOP 2) │
│ [ moof: mfhd / traf / tfhd / tfdt / trun ] [ mdat: Video NALUs ] │
└────────────────────────────────────────────────────────────────────────┘ftyp+moov: Written immediately upon file creation. Contains video SPS/PPS codec configuration records (avcCfor H.264,hvcCfor H.265).moof+mdat: Written on every KeyFrame boundary (GOP). Thetrunbox contains sample durations, sizes, and flags;mdatholds the raw compressed video slices.
2. Linux Kernel Page Cache Eviction (POSIX_FADV_DONTNEED)
Writing continuous video streams across hundreds of cameras generates tens of megabytes per second of disk writes. In standard Linux deployments, the kernel buffers all written data in RAM Page Cache, leading to Page Cache Thrashing, system freezes, and OOM killer crashes.
RUSEON Core solves this using a Direct I/O Sliding-Window Flush Strategy:
// 1. Flush written fMP4 part to disk
_ = part.Marshal(file)
// 2. Instruct Linux kernel to evict cached pages from RAM
if dropper, ok := file.(registry.CacheDropper); ok {
_ = dropper.DropCache()
}- Zero Memory Bloat: RAM usage remains strictly flat (~471 MB RSS under 600 cameras) even when writing hundreds of gigabytes per day.
- Zero I/O Stalls: Background writeout prevents disk controller queue congestion.
3. Storage Hierarchy & Crash Recovery
Files are organized within the configured record directory (default recordings/):
- Ongoing Stream:
recordings/{camera_id}/2026-08-23_15-04-05_ongoing.mp4 - Hourly Completed:
recordings/{camera_id}/2026-08-23_15-04-05_to_16-04-05.mp4 - Crash Recovery: At server startup,
cmd/server/main.goscans for interrupted.crashedor.ongoingfiles and renames completed segments, ensuring 100% data integrity without lost footage.