Strix: brute-force RTSP URL discovery for IP cameras, and the Frigate config that follows

The problem: cameras ship without documentation for their own stream URLs

An IP camera will tell you it exists. It will rarely tell you the path to its video. RTSP paths are vendor conventions, not standards: a Hikvision unit and a Dahua unit on the same shelf will answer on port 554 with completely different URL structures, and the sub-stream path is usually different again from the main stream. The README frames Strix around exactly this gap. You enter a camera IP, Strix probes the device for open ports, MAC vendor, mDNS and HTTP server, then you search the camera model in a bundled database and it builds every candidate stream URL from stored patterns. Twenty workers test them in parallel and report back with live screenshots, codecs, resolution and latency. The target user is someone running Frigate or go2rtc at home or in a small deployment who has inherited cameras, bought used hardware, or is tired of reading forum posts to find the second stream path. It is not aimed at large NVR deployments with vendor-supplied integration documents.

How the discovery pipeline actually runs

The flow has four distinct stages, and they fail in different ways. Stage one is device probing: Strix opens ports, reads the MAC to identify the vendor via OUI lookup, listens for mDNS and HomeKit advertisements, and inspects the HTTP server. The README claims this completes in 100ms. Stage two is database matching. The SQLite file holds 3,600+ brands and 100,000+ URL patterns, organised into three entity types: presets (curated sets like ONVIF or Popular RTSP), brands (all patterns for Hikvision or Dahua), and models (patterns for one specific model inside a brand). Stage three is the test sweep: 20 parallel workers attempt every generated URL, and the results carry a screenshot, codec, resolution and latency. Stage four is config generation, where you pick a main and a sub stream and Strix writes a Frigate config, either to copy, to download, or to merge directly into an existing Frigate setup. The smart merge claim matters more than the generation claim. Writing a fresh config is easy; inserting a camera block into a config someone already hand-tuned without destroying it is the part that determines whether the tool is usable on an existing deployment.

Install paths and the environment variables that matter

The one-line installer is `bash <(curl -fsSL https://raw.githubusercontent.com/eduard256/Strix/main/install.sh)` and the README states it must run as root or with sudo, because the installer probes the system and guides setup. It serves on port 4567. Docker is the simpler route: `docker run -d --name strix --network host --restart unless-stopped eduard256/strix:latest`. Host networking is not optional here, since discovery depends on seeing the local network. Podman needs explicit capabilities, and the README is direct about why: Podman drops NET_RAW and NET_ADMIN by default, and Strix needs both for network scanning. The documented fix is `--cap-add=NET_RAW --cap-add=NET_ADMIN`, with `--privileged` offered as the blunter alternative. There are compose files for Strix alone, Strix plus Frigate, and Strix plus go2rtc. For the static binary, the README gives `STRIX_LISTEN=:4567 ./strix-linux-amd64` after a chmod, and notes the only dependency is ffmpeg for screenshot conversion. Five environment variables are documented: STRIX_LISTEN (default :4567), STRIX_DB_PATH (default cameras.db), STRIX_LOG_LEVEL (debug, info, warn, error, trace), STRIX_FRIGATE_URL and STRIX_GO2RTC_URL. The last two default to auto-discovery, which is why the compose files can wire the three services together without you pasting addresses.

Protocol coverage is the real differentiator, and also the source of noise

Strix does not stop at RTSP. The README's protocol table covers RTSP on 554, RTSPS on 322, HTTP and HTTPS on 80 and 443 for MJPEG, JPEG snapshots, HLS and MPEG-TS, RTMP on 1935 for some Chinese NVRs, Bubble on port 80 for XMeye and NetSurveillance cameras, DVRIP on 34567 for the Sofia protocol used by DVRs and NVRs, and HomeKit on 51826 via HAP. That breadth is what makes the 100,000+ pattern count meaningful rather than padded. It is also the source of a practical problem: a camera that answers on HTTP with a JPEG snapshot endpoint and also on RTSP will produce results for both, and the tool cannot know which one you want. The README's answer is procedural rather than automatic. You pick the main and sub streams from the results yourself. The screenshots, codecs, resolution and latency fields exist to make that choice possible, but the decision is yours. If you skip that step and accept whatever the tool highlights, you may end up with a snapshot URL in Frigate where a stream belongs.

Where Strix is the wrong tool

The first limitation is scope: probing is described as local. ARP and OUI lookup, mDNS, and raw socket scanning are all link-local mechanisms. Nothing in the README suggests Strix can discover cameras behind a router on a different VLAN, and the capability requirements it documents (NET_RAW, NET_ADMIN) point the same direction. If your cameras sit on an isolated surveillance VLAN, you need to run Strix on a host that can reach that VLAN directly. The second limitation is the database itself. Coverage is 3,600+ brands and 100,000+ patterns, which is large but not exhaustive, and the README routes missing cameras to a contribution page rather than offering a heuristic fallback. A camera absent from StrixCamDB produces nothing useful. The third limitation is that brute-force testing is inherently noisy against the target. Twenty parallel workers hitting a camera with a long list of candidate URLs is a burst of authentication attempts. Some cameras rate-limit, log, or lock accounts after repeated failures. The README does not discuss lockout behaviour, and that is a real gap for anyone testing a production camera rather than a spare. The fourth is that the binary needs ffmpeg for screenshot conversion, so the zero-dependency claim is about libraries, not about the whole toolchain.

How this differs from ONVIF-based discovery

The obvious alternative is ONVIF, which is what most discovery tooling uses. ONVIF is a standard: a conformant camera exposes a discovery endpoint and a media service that returns its stream URIs, so a client asks the camera for its own answer instead of guessing. Strix inverts that. It assumes the camera may not speak ONVIF usefully, may speak a vendor protocol like DVRIP or Bubble, or may expose ONVIF but return URIs that do not match what actually streams. In exchange for that assumption, it accepts a cost: guessing is slower per camera, noisier on the network, and dependent on a database someone else maintains. The trade-off is clearest with cheap and older hardware. A no-name camera with a Bubble interface on port 80 will not answer an ONVIF probe at all, and Strix's pattern database is the only path to its stream. On a rack of modern ONVIF-conformant cameras, ONVIF discovery is faster and produces authoritative URIs, and Strix's parallel sweep is wasted effort. Note that the README lists ONVIF as one of the curated presets in the database, so Strix does use ONVIF patterns, but as one input among many rather than as the discovery mechanism.

Maintenance, licensing, and what the release cadence implies

Strix is MIT licensed, which permits commercial use, modification and redistribution with the licence text retained. The camera database is a separate concern: it lives in the StrixCamDB repository, is embedded in the Docker image, and is bundled with binary releases. That separation is sensible, but it means database freshness is tied to your update path. Pulling a new Docker tag gets you a new database; running a binary you downloaded months ago does not. The release history shows v2.0.0 and v2.1.0 in April 2026 and v2.2.0 in August 2026, so the project is active but not on a rapid cadence. The primary language field on the repository is HTML, which is worth noting: the README describes a Go binary and the topics list golang, so the HTML figure likely reflects the web UI's share of the tree rather than the backend. That is an observation about repository metadata, not a claim about code quality. For upgrade cost, the practical question is whether your config survives a version bump. Strix merges into existing Frigate configs, and the README does not describe a migration or backup step for that merge. Back up your Frigate config before letting Strix write to it. This is not legal advice, and the MIT terms should be read in full if you plan to redistribute the binary.

Editorial conclusion

Adopt Strix if you have a mixed fleet of cameras whose stream paths you do not know, or if you are standing up Frigate and want a generated config rather than a hand-written one. Do not adopt it if your cameras already expose a documented RTSP path, if your network forbids ARP and raw socket access, or if you need to discover cameras across subnets, since the README describes probing as local. Verify three things before committing: that your camera model appears in the StrixCamDB browser at gostrix.github.io, that the container or binary can reach the cameras on the ports listed in the protocol table, and that ffmpeg is present if you want screenshot conversion, because the binary is documented as having no dependencies except ffmpeg.

Official sources

1. eduard256/Strix on GitHub
2. Issues
3. License: MIT
4. README
5. Releases