Known Limitations & Architectural Trade-offs

To maintain ultra-high throughput, flat memory usage, and single-binary simplicity, RUSEON Core makes intentional engineering trade-offs.

1. Zero-Transcoding Design Boundary

Limitation: RUSEON Core does not transcode video pixels on the server (e.g. converting H.265 to H.264 or downscaling 4K to 720p).
Rationale: Server-side pixel decoding and re-encoding burns massive CPU/GPU power and prevents achieving 600+ stream density on standard hardware.
Solution: Configure cameras with multi-stream profiles (Main Stream for high-res archiving; Sub Stream for multi-view browser grids).

2. Browser Codec Compatibility & WebCodecs Fallback

Limitation: Some older browsers lack native WebRTC H.265/HEVC hardware decoding support.
Solution: RUSEON Core provides a binary WebSocket WebCodecs stream (GET /stream/ws/:id), enabling hardware-accelerated client-side NALU decoding via the HTML5 WebCodecs API in Chrome, Edge, and Safari.

3. Audio Transmuxing Constraints

Limitation: WebRTC standard requires Opus or G.711 audio. Legacy CCTV cameras outputting proprietary G.726 or MP2 audio will not play sound in standard WebRTC browser players.
Solution: Set the camera audio profile to AAC (48 kHz) or PCMA/PCMU (G.711) in the camera web UI.

4. Single-Node Embedded Database (BadgerDB v4)

Limitation: BadgerDB is an embedded LSM key-value engine, not a distributed multi-master cluster.
Solution: For multi-server deployments exceeding 600 cameras, use Camera Sharding (partitioning cameras across independent nodes) behind an Nginx or HAProxy reverse proxy.

5. Linux-Specific Kernel Optimizations

Limitation: Direct I/O cache dropping (POSIX_FADV_DONTNEED) and adaptive UDP packet batching (sendmmsg) rely on Linux kernel syscalls.
Behavior on Windows / macOS: RUSEON Core automatically falls back to standard buffered file I/O and single-packet UDP writes with full functional parity for development and edge testing.