Thousands of 2008–2018 analog DVRs have no RTSP and no ONVIF — so Frigate, Home Assistant and Scrypted can't see them. dvrbridge talks the board's own closed protocol and re-serves every channel as standard RTSP. Same H.264, stream-copied, no new hardware.
MIT-licensed core · runs on a Raspberry Pi · verified live on a 4-channel board
# 1 · find your channels $ dvrbridge probe 192.168.1.108 -u admin -p •••• ch1: OK 352×288 ch2: OK ch3: OK ch4: OK # → prints ready-to-paste config # 2 · run the bridge $ dvrbridge serve -c dvrbridge.toml # 3 · watch, anywhere $ ffplay rtsp://host:8554/dvr/ch1
It's one of the most common walls in the self-hosted-camera world, and it stays unsolved for years. Every existing DVRIP tool assumes the standard protocol on port 34567 and sends a login packet that desyncs these older boards. dvrbridge is built for exactly the boards nothing else can reach.
“My DVR model doesn't have an RTSP port, only mobile and media port.”
Home Assistant community forum
“Timeout while loading URL… maybe HA doesn't support some old RTSP protocol?” — resolved only at 176×144.
HA — “Connecting ancient DVR to HA”
“Struggling to find the right string to connect it.” ffmpeg loops on Invalid data found.
Frigate issue #6893
Users hunting the mobile-app stream format precisely because there is no documented RTSP.
ZoneMinder forums
The DVR is already emitting standard H.264 — it's just wrapped in proprietary framing behind a locked handshake. dvrbridge is the translator, and it never re-encodes, so it's light enough to bridge dozens of channels on a Pi.
A pluggable driver speaks the board's native binary protocol and parses its frame headers, resyncing on corruption.
The hub multiplexes many viewers over one device socket — and only connects while someone's watching, respecting the board's tiny connection budget.
A built-in RTSP server (TCP + UDP, RFC 6184) hands clean H.264 to Frigate, HA or VLC at rtsp://host:8554/dvr/chN.
No per-channel encoder dongles, no power bricks, no ONVIF negotiation to babysit. One process, on hardware you already own.
Forwards the DVR's own H.264 untouched. No quality loss, negligible CPU — a Raspberry Pi bridges all four channels.
Capped-backoff reconnect and mid-stream resynchronisation mean a device hiccup is invisible to Frigate.
Everything stays on your LAN. Keep the DVR on an isolated VLAN; the bridge is the only thing that talks to it.
dvrbridge probe detects channels, checks credentials and prints your whole config. Paste, serve, done.
Adversarially reviewed, soak-tested against real hardware, and open source. Fork it, audit it, trust it.
The bridge is open source and always will be — that's the point. Revenue comes from the hard part: reverse-engineering boards nobody's cracked yet, and supporting the pros who deploy them.
Love it but on a supported board? Sponsor on GitHub from $5/mo — it keeps the drivers coming.
We won't pretend otherwise: a generic AHD-to-IP encoder is ~$25–40 a channel and is genuinely plug-and-play. dvrbridge earns its place when you'd rather not run four more boxes and power bricks on the wall — when you want one auditable process on the host you already own, no ONVIF lottery, no added hardware to fail, and your footage never leaving the LAN. If that's you, welcome. If you just want the fastest path and don't mind the boxes, buy the dongles — we'll still be here when you outgrow them.
Today: generic “NetDvrV3” / MEye-app OEM boards on port 8888 (the XMEye-adjacent family that standard DVRIP tools can't reach), verified on real hardware. The architecture is one driver per protocol family — Sofia/XMEye on 34567 and others are on the roadmap, and Revive My Board exists precisely to add yours.
No re-encoding — it forwards the DVR's own H.264 byte-for-byte, so image quality is identical to the source and CPU use is negligible. Latency is sub-second on a LAN.
Nothing leaves your network. dvrbridge is a local daemon with zero external dependencies. Best practice — documented in the README — is to keep the DVR on an isolated VLAN with the bridge as the only thing allowed to reach it.
Point go2rtc at rtsp://bridge-host:8554/dvr/chN and give the camera detect + record roles. Run the daemon as a systemd service or a sidecar container — there's nothing to install inside the Frigate image. Full config is in the docs.
You wouldn't, to run it on a supported board. You'd pay only to get an unsupported board reverse-engineered, or for a support SLA if you deploy for clients. The reverse-engineering is real, bespoke work — and the driver we write for you becomes free for the whole community.
MIT core · Docker & systemd ready · no account, no telemetry, no catch