RUSEON Core vs MediaMTX (formerly rtsp-simple-server)
MediaMTX is a widely popular, well-engineered zero-dependency media server and router written in Go by Alessandro Decina. It excels as a universal multi-protocol proxy supporting RTSP, RTMP, HLS, WebRTC, SRT, and WebTransport.
While MediaMTX is great for general-purpose stream routing and rebroadcasting, RUSEON Core was architected specifically for high-density CCTV surveillance, crash-proof 24/7 archive storage, and zero-allocation Linux kernel I/O performance.
1. Key Architectural Differences
1. Storage Subsystem: Direct I/O fMP4 vs Standard MP4
- MediaMTX: Uses standard Go buffered file writing for MP4 recordings. Under heavy 24/7 write loads across dozens of camera streams, the Linux kernel accumulates dirty pages in RAM, which can lead to page cache thrashing, high I/O wait times, and OOM killer panics.
- RUSEON Core: Implements fragmented MP4 (
fMP4) recording combined with sequentialsync_file_rangeandPOSIX_FADV_DONTNEEDsyscalls. After writing each 2MB segment, RUSEON explicitly instructs the Linux kernel to drop the written video pages from RAM. Memory consumption remains strictly flat (~471 MB RSS even under 600 cameras).
2. Crash Resilience: Self-Indexed fMP4 Fragments
- MediaMTX: Standard MP4 files require writing the
moovindex atom at the end of the file. If power drops or the process crashes, unfinalized MP4 files become corrupted and unplayable. - RUSEON Core: Writes independent
moof+mdatfragments. Every fragment is standalone and self-describing. Even during an abrupt power outage, every completed fragment remains 100% playable without repair utilities.
3. WebRTC Networking: Adaptive sendmmsg UDP Batching
- MediaMTX: Uses standard single-packet UDP socket writes for WebRTC egress.
- RUSEON Core: Wraps UDP multiplexing in an adaptive
BatchingUDPMuxConnusing the Linuxsendmmsgsyscall. Batches up to 32 RTP packets or flushes immediately upon receiving the RFC 6184 Marker bit ($M=1$), reducing Linux kernel context switching overhead by 85–90%.
4. Database & State Store: Embedded BadgerDB vs Static YAML
- MediaMTX: Relies exclusively on static YAML configuration and in-memory runtime maps.
- RUSEON Core: Integrates pure Go BadgerDB v4 (LSM-tree Key-Value store with ACID durability). Provides transactional camera records, tags, folders, access tokens, and one-click JSON backup snapshots.
2. Performance Summary
| Metric | RUSEON Core | MediaMTX |
|---|---|---|
| Max Streams per Node | 600+ Streams (18,139 FPS / 1.34 Gbps) | ~60 – 100 Streams |
| Concurrent Viewers | 1,800 HLS + 240 WebRTC Viewers | ~200 – 400 Viewers |
| HLS Master Latency | < 0.5 ms (In-Memory) | ~2 – 5 ms |
| RAM Footprint (600 Cams) | 471 MB RSS (140 MB Heap) | ~2 – 4 GB |
| Web UI | Built-in React 19 Glassmorphism | None |