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 I/O performance.
🏗 Key Architectural Differences
1. Storage Subsystem: Direct I/O fMP4 vs Standard MP4
- MediaMTX: MediaMTX uses standard Go file writing for MP4 recordings. Under heavy 24/7 write loads across 50+ 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 events.
- RUSEON Core: RUSEON implements fragmented MP4 (
fMP4) recording combined with sequentialPOSIX_FADV_DONTNEEDsyscalls. After writing each segment, RUSEON explicitly instructs the Linux kernel to flush and evict the written video pages from the OS page cache. Memory consumption remains strictly constant (~180MB) even with 100 cameras recording 24/7.
2. Crash Resilience: Unfinalized MP4 Recovery
- MediaMTX: Standard MP4 files require writing the
moovindex atom at the end of the file. If power drops, the process crashes, or the server abruptly reboots, unclosed MP4 files become corrupted and unplayable. - RUSEON Core: RUSEON writes independent
moof+mdatfragments. Every fragment is standalone and self-describing. Even in the event of an abrupt kernel panic or power outage, every second recorded up to the moment of failure remains 100% playable without repair tools.
3. CPU Efficiency: Lazy HLS On-Demand Muxing
- MediaMTX: Muxes and segments video streams continuously as long as the stream is active.
- RUSEON Core: Implements Lazy HLS Muxing with an automated 15-second watchdog timer. If no web clients are currently requesting HLS playlists or segments, the HLS muxer for that camera is dormant. When a client connects, RUSEON instantly fetches the last 4 seconds from its in-memory RingBuffer, serving instant video and saving up to 80% idle CPU across hundreds of inactive cameras.
4. Database & State Management: Embedded BadgerDB vs YAML
- MediaMTX: Relies exclusively on static
mediamtx.ymlconfiguration and in-memory runtime maps. - RUSEON Core: Integrates pure Go BadgerDB (LSM-tree Key-Value store). Provides ACID transactional state management, dynamic camera tags, access tokens, and automatic daily database snapshots without external database setup.
⚡ Performance Summary
| Metric | RUSEON Core | MediaMTX |
|---|---|---|
| Max Cameras per Node | 100+ Streams | ~40-60 Streams |
| Concurrent RPS (WHEP/HLS) | ~7,000 RPS | ~2,500-3,500 RPS |
| p95 Request Latency | 1.7ms | ~5-12ms |
| RAM Footprint (100 Cams) | ~180 MB - 350 MB | ~1.2 GB - 3.5 GB (Page cache bound) |
| Web UI | Built-in Glassmorphism UI | None (Third-party integrations) |
🚀 Conclusion: Which One Should You Choose?
- Choose MediaMTX if: You need a general-purpose Swiss Army knife for protocol conversions (e.g. RTMP ingress to SRT or WebTransport) and do not need built-in crash-proof archival or web dashboard management.
- Choose RUSEON Core if: You are building CCTV surveillance infrastructure, enterprise NVRs, or high-density video AI pipelines where 24/7 storage integrity, page cache protection, sub-50ms WebRTC, and resource efficiency are non-negotiable.