Camera Feed Lab

Open source · MIT · v0.2.0

A roomful of virtual security cameras without buying or wiring a single one — plus the tool that proves the video actually made it through.

Camera Feed Lab serves configurable RTSP camera feeds from generated test patterns or approved recordings, so you can develop and test an NVR, VMS, video wall, player, analytics service, or any other RTSP consumer as though real cameras were attached. The same configuration runs on a laptop, in CI, or as a shared lab feeder.

The problem it solves.

Software that consumes surveillance video is hard to develop and test without a stable camera estate. Physical cameras are finite, location-dependent, privacy-sensitive, and prone to changes outside the test. A directory of video files is reproducible, but it does not exercise RTSP connections, stream startup, fan-out, pacing, readiness, process lifecycle, or time-aligned replay. Hand-written FFmpeg commands fill the gap for one experiment, but they are hard to review, repeat, scale, and carry between environments.

Camera Feed Lab packages those concerns into one controlled test fixture. The portable default needs no media files — it produces a site-neutral set of synthetic camera feeds immediately. More realistic tests mount local or shared media read-only and replay it without embedding footage or deployment details in the image or repository.

Part one

Feed server.

Validates a JSON manifest, supervises MediaMTX and FFmpeg, and publishes the requested RTSP/TCP camera paths.

1–64 source streams, each with a stable ID, unique RTSP path, activation mode, and explicit video/audio handling.
Synthetic or recorded. Deterministic test patterns and tones, or real-time replay of approved MPEG-PS/TS, MP4/MOV, and MXF files.
Wall-clock day replay. A looped full-day recording seeks to the current time of day so historical footage tracks real time.
Validate before start. Strict JSON contract, rooted media confinement, shell-free FFmpeg planning, and a machine-readable /health readiness endpoint.

Part two

Chain Monitor.

The verification half. It observes what a test consumer actually receives rather than assuming a healthy simulator means a healthy end-to-end system.

Delivery probes. Rotating RTSP/TCP probes measure delivered frames against monotonic time.
Display liveness. In-memory PNG/JPEG comparisons verify that each region of a physical display is advancing — not dark or frozen — with per-tile masks so moving UI chrome can’t hide a frozen video surface.
Telemetry-aware. Typed collectors fold in application health, reader state, and event counts from generic JSON endpoints.
Runs independently. Use the feed server alone when end-to-end observation isn’t needed.

NVR, VMS, and video-analytics developers — a controlled set of RTSP sources for ingest, recording, restreaming, transcoding, motion/object detection, indexing, or playback, with no dependence on physical hardware.
QA and CI engineers — repeatable synthetic fixtures with a machine-readable readiness contract; start, assert, tear down, retain nothing.
Capacity and performance engineers — vary stream count, resolution, frame rate, codec, activation, and reader fan-out to drive ingest, PID, memory, network, decoder, and concurrency tests.
Video-wall and player developers — many simultaneous tiles, codec transitions, stall handling, and reconnection, with Chain Monitor correlating delivery to per-region display advancement.
Integrators and support engineers — reproduce a timing, container, codec, or lifecycle failure from a scrubbed manifest and approved sample, without access to the original camera estate.

It does not discover or control cameras, record footage, manage retention, run analytics, or emulate a vendor’s management API.
Its consumer-facing protocol is RTSP; it does not emulate ONVIF or proprietary camera/NVR APIs. The portable hardened container supports RTSP/TCP.
No footage, credentials, host addresses, or site mappings ship in the repository or image — users provide approved media and deployment configuration separately.
Manifest limits are not performance promises; capacity must be measured on the target host and workload.

Open source.

Camera Feed Lab is MIT-licensed and released as open source at v0.2.0. A Go supervisor wraps pinned MediaMTX and FFmpeg in a hardened, non-root, read-only container. The default Compose stack is self-contained: clone the repository, build, and it generates a site-neutral synthetic profile with no footage or credentials required.

View on GitHub → MIT · Go · MediaMTX + FFmpeg

The problem it solves.

Feed server.

Chain Monitor.

Who it’s for.

What it isn’t.

Open source.