The foundation of Visylix. A proprietary streaming engine purpose-built from scratch. Not a wrapper around open-source libraries. Designed for high stream density on commodity hardware with sub-second WebRTC live view, up to sub-200ms in ideal conditions, and native H.264/H.265 handling. Exact per-node capacity depends on resolution, codec, and enabled AI models, so we validate it on your hardware during the proof of concept.
Request a DemoBuilt for the most demanding video workloads in enterprise, government, and smart city environments.
Purpose-built from scratch with native H.264 and H.265 support, adaptive backpressure that drops non-reference frames while preserving keyframes, GOP cache for instant viewer playback, automatic H.265 to H.264 transcoding, smart audio transcoding (G.711/AAC to Opus), and circuit breaker protection at configurable CPU thresholds.
Native H.264 and H.265 encoding and decoding with GPU acceleration for real time format conversion, resolution scaling, and adaptive bitrate stream generation. AI inference runs GPU-accelerated, and falls back to CPU-only where no accelerator is available.
Built in multi tenancy with isolated data planes, per tenant resource quotas, role based access control, and white label customization. Non root containers with no new privileges and minimal base images.
Sub second event processing pipeline that correlates AI detections, motion events, and system alerts into actionable notifications and automated workflows. Smart backpressure drops P frames under load but never keyframes.
Auto config detects CPU, RAM, GPU, and camera count then optimizes every parameter automatically. Scales from a 4 core laptop to a 128 core server. Less than 2 GB memory per 1,000 streams. Full stack cold start in under 60 seconds.
TLS 1.3 everywhere including HTTPS, RTMPS, RTSPS, and TURNS. TURN relay for WebRTC through firewalls. RBAC with LDAP/SAML SSO. RSA signed tamper proof license files with hardware fingerprint binding. Air gap compatible.
A modular, containerized architecture designed for resilience and performance.
What the engine is built to do. These are design characteristics, not a published benchmark. We size and measure them on your own hardware during the proof of concept.
Schedule a technical deep dive with our engineering team to explore the proprietary VMS engine architecture and 13-protocol streaming capabilities.
It is a first-party native engine rather than an integration layer over a third-party media server. Each camera is decoded once and the decoded frame is shared by reference across the live-view, recording, and AI paths instead of being copied for each consumer. That single design decision is why the marginal cost of adding one more camera stays low.
The engine is built for thousands of concurrent streams per node on commodity hardware, but the exact figure depends on resolution, codec, and how many AI models are enabled per camera. There is no published load benchmark yet, so capacity is sized and validated on your own hardware during the proof of concept rather than quoted as a fixed number.
No. All 22 analytics run against the same decoded frames the engine already produces for live view and recording, on the same node, with no separate analytics server and no per-stream AI fee. Detection zones can be set per camera and per model, so different models can watch different regions of the same feed.
The engine applies adaptive backpressure, dropping non-reference frames first so that keyframes survive. The practical effect is that a struggling viewer sees reduced smoothness rather than a frozen or broken picture, and recording quality is unaffected because recording writes the camera bitstream directly rather than the viewer stream.
No. The engine keeps a GOP cache, so a viewer joining a stream receives the most recent Group of Pictures immediately and starts playing rather than waiting for the camera to emit its next keyframe. On cameras with long keyframe intervals this is the difference between instant playback and several seconds of black.
H.264 and H.265 (HEVC) for video, and AAC, G.711, G.726, and Opus for audio, processed natively by the engine. Where a client needs a codec the camera does not produce, GPU-accelerated transcoding converts only the streams that require it rather than the whole fleet.