HLS & Low-Latency Pipeline Architecture
The HLS Pipeline (internal/hls/) generates standardized HTTP Live Streaming (HLS) master manifests, media playlists, and WebVTT subtitle tracks directly from the Ring Buffer.
1. Zero-Disk In-Memory Transmuxing
Traditional media servers write live HLS .m3u8 and .ts files to disk (or a /dev/shm ramdisk), causing thousands of file creation and deletion syscalls every minute.
RUSEON Core performs all live HLS packaging purely in RAM:
- Virtual Segments: Media segments (
.tsor.vtt) are generated in memory and retained inside an in-memory cache (server.hls.live_segments_in_memory: 3by default). - Sub-Millisecond Response: Master playlists are generated with zero disk access with latency
p50 < 0.5 ms. - Zero Storage Wear: Solid-state drives experience zero write degradation from live viewing sessions.
2. Master Manifest with Embedded WebVTT Metadata
RUSEON Core delivers synchronized AI metadata over HLS using WebVTT subtitle tracks:
index.m3u8: Master playlist declaring both video (stream.m3u8) and subtitle metadata tracks (subs.m3u8).subs.m3u8: Delivers timestamp-aligned WebVTT cues containing JSON bounding boxes from AI inference.
3. Lazy HLS Muxer Lifecycle (lazy_hls)
For large multi-camera enterprise deployments:
- When
lazy_hls: trueis configured, RUSEON keeps the HLS muxer dormant until an HTTP request arrives. - When an initial viewer connects,
st.WakeUpHLSMuxer()subscribes to the Ring Buffer and generates playlists. - Idle muxers automatically sleep when unwatched, conserving CPU cycles across hundreds of cameras.