OmniBridge

Future Plan

What's on the roadmap, what's deliberately parked, and why — so you know what to expect (and not expect) in a coming release.

On the roadmap

Topology / signal-flow view

A real interactive diagram of source → gateway → destination routing, rather than reading it off the Operate/Diagnostics tables. For now, see Diagnostics and Signal Flow for a text-diagram stand-in — a full interactive version is being considered but isn't built yet.

HA add-on: automatic failover

Planned as its own paid add-on (~$200/yr), separate from base licensing — not folded into the sources/destinations capacity model the way RTMP/RIST/NDI are. A standby gateway continuously tracks the live primary's routing setup and mirrors it, ready to take over the moment the primary goes down. Because the standby is tracking the primary rather than independently routing the same feeds live, it's designed not to count against licensed source/destination usage the way two fully independent instances mirroring the same routing do today (see the manual method below). Not started — today, a single gateway is a single point of failure for the gateway process itself (see Home's "What survives a restart" for what actually happens if it goes down mid-show: routes and presets are preserved, and everything reconnects automatically once it's back up, but nothing fails over to a second machine while it's down).

Manual redundancy, available today: installs are unlimited under one key, so running a second instance on a separate machine or network path needs no separate per-install license — see Compare. This is entirely manual, though: you configure the standby's sources/ destinations yourself, it doesn't track the primary's live routing changes, and — since usage is summed across every install checked in under the key — if both instances mirror the same sources/destinations live at once, that counts on both, so the license needs authorized capacity for the combined total. The planned HA add-on above is what's meant to remove both the manual setup and that usage double-count.

SDI capture & playout (attached hardware)

Every source and destination today is IP-based (SRT, RTMP, UDP MPEG-TS, RIST, NDI) — OmniBridge has no path in or out for baseband SDI, the coax/fiber signal most broadcast cameras, switchers, and monitors actually speak. Bringing SDI in would mean a capture card physically installed in the machine running the gateway (Blackmagic DeckLink is the obvious first target — it's the de facto standard and the one most customers already own), decoding baseband video/audio into the same internal pipeline every IP source already feeds; playout out to SDI is the same idea in reverse, on the destination side.

Why this isn't started: it's a different kind of dependency than any protocol OmniBridge bridges today. RTMP/RIST/NDI go through ffmpeg or a Rust crate talking to a network socket — no physical hardware, no driver, nothing to install beyond the gateway itself. SDI needs a real card in a real machine, the vendor's own SDK (DeckLink's is C/C++, no official Rust bindings — this would need either a maintained third-party binding or hand-written FFI, the same shape of work grafton-ndi already did for NDI), and testing against real hardware this team would need to own. Realistically scoped as capture first (SDI in, as a new source type) before playout, since capture covers the more common ask — feeding an SDI camera or existing switcher's output into OmniBridge's routing — without also solving hardware playout timing.

Time-sync (SMPTE timecode / PTP)

Two related but different things, both currently absent:

  • SMPTE timecode passthrough — carrying a source's embedded timecode (LTC, or an RTP-based equivalent) through the gateway to whatever's on the other end, so a destination can identify exactly which frame it's looking at (matching multi-camera footage in post, or driving timecode-aware graphics/switchers live). OmniBridge doesn't read, preserve, or re-embed timecode metadata today — it treats every stream as an opaque payload to relay, not something to inspect.
  • PTP (IEEE 1588) for the gateway's own clock — keeping the gateway's system clock traceable to the same reference every other device on a production network uses (standard practice in SMPTE ST 2110 IP-video facilities), so anything OmniBridge timestamps (event log entries, a future re-embedded timecode) means the same thing facility-wide, including across multiple gateways at different sites.

What this would not deliver, even once built: true frame-accurate genlock across independently-encoded network sources. Two SRT/RTMP feeds from two different encoders each have their own capture clock and their own network jitter — passing timecode through, or disciplining the gateway's clock via PTP, lets you know precisely which frame each source is on, but it can't make two independently -encoded network streams land pixel-locked the way a shared genlock reference generator does for SDI infrastructure. Good enough for correlating multi-cam angles and timecode-driven switching decisions; not a substitute for real genlock if that's what a production needs.

Custom install ISO / appliance image

A pre-built Linux image with OmniBridge already installed and configured to boot straight to the dashboard — flash a drive, boot it, done, no manual Debian/Ubuntu install first. Not scoped to redundancy specifically (see the failover item above) — useful for any new install, and especially for standing up a second/hot-standby node quickly without repeating a full OS setup by hand. Not started.

WebRTC

Sub-second-latency browser-based contribution and playback, alongside SRT/RTMP/RIST/NDI — no dedicated encoder needed on the sending side, just a browser tab. Not started. Would follow the same per-license add-on model RTMP/RIST/NDI already use once built.

Epiphan API remote control

Remote control of Epiphan capture/streaming hardware (e.g. their Pearl line) via Epiphan's own device API — starting/stopping streams, changing encoder settings, rebooting the device. Early idea, not yet scoped: no research done yet on the API's shape, auth model, or exactly what "remote control" should cover.

OBS SRT Toolkit's own dedicated encoder

OBS SRT Toolkit (see the OBS Setup Guide) is real, shipped, and verified end-to-end against a real OmniBridge instance — see "Shipped" below. One limitation remains: its SRT Output currently reuses whichever encoder OBS's own Streaming or Recording output already has configured, rather than creating a dedicated one, so Stream or Record needs to have been started at least once first. A version with its own independent encoder is planned as a follow-up — see issue #1 for status.

Persistent event logging

The Events tab (see Home) is currently a live, in-memory session log only — it doesn't survive a gateway restart. Persisting it to disk (a rotated log file next to app_config.json) so you can pull up what happened even after an unplanned restart, crash, or power loss, is on the roadmap. Not started yet.

Shipped

Everything below already exists in the current release — kept here so "what's actually on the roadmap" above isn't confused with what's already done:

  • Protocol Support — RTMP, UDP MPEG-TS, RIST, and NDI as both a source and destination protocol (live NDI source discovery built in). SRT and UDP MPEG-TS are included with every license; RTMP, RIST, and NDI are each separately-licensed add-ons.
  • Observability — the three-state status indicators, the (in-memory) event/audit log, relay traffic counters, the endpoint Diagnostics view, and per-connection metrics (RTT/loss/retransmits).
  • Core Platform & Config — the shared program-out port + stream-ID architecture, per-endpoint SRT latency/passphrase overrides, and the source/destination terminology cleanup.
  • OBS Media Source reliability (#17) — OBS's Media Source had appeared less reliable than a raw SRT connection under otherwise identical conditions; root-caused to FFmpeg libsrt's default listener-socket timeout/buffer settings, not the gateway side — the OBS Setup Guide's manual-setup Direction 2 documents the URL parameters (timeout, latency, rcvbuf, pkt_size) that fix the "freezes on disconnect" and stutter symptoms.
  • OBS integration — OBS SRT Toolkit, a native OBS plugin adding a real SRT Output (its own dock) and SRT Source, replacing the old Media-Source-tuning and Custom-FFmpeg-Output workarounds documented further down the OBS Setup Guide. Verified end-to-end against a real OmniBridge instance in both directions, with sustained throughput. The manual, no-plugin methods (Media Source tuning, Custom FFmpeg Output) remain fully documented and supported for anyone who can't install a plugin.
  • Peplink InControl2 integration — a licensed add-on: a Peplink tab showing live WAN status per device (online/offline, per-interface status, real cellular signal metrics — RSSI/SINR/RSRP/ RSRQ from InControl2's cloud API) and per-device PepVPN/SpeedFusion tunnel stats (RTT, cumulative TX/RX, packet loss, tunnel state). Connected LAN clients are listed per device with a one-click link to a client's web admin UI when reachable. SRT/UDP sources are automatically matched to the Peplink device whose configured CIDR their connecting IP falls in. See Peplink Integration.
  • Diagnostics/support-report system — a "Send diagnostics report" button on the About page: recent logs + the current routing config (every passphrase/secret redacted client-side before it's ever sent) + an optional note, submitted to a shared JPPS support intake service. Works even on an unlicensed/expired/over-limit install, deliberately — that's exactly when it's most needed. Crashes are now also automatically reported the same way, on every platform. See Sending a Support Report.

Tracking

All roadmap work — shipped and open — is tracked internally, grouped by theme (not by release date — no ETA is implied on the open ones):

  • Reliability & Failover — HA add-on/automatic failover (open).
  • Protocol Support — RTMP/UDP-TS/RIST/NDI output, NDI as a source with live discovery (all shipped); SDI hardware capture/playout, WebRTC, and SMPTE timecode/PTP time-sync (all open).
  • Third-party integrations — Peplink InControl2 integration (shipped); Epiphan API remote control (open, not yet scoped in detail).
  • Support tooling — the diagnostics/support-report system, manual + automatic crash reporting (shipped).
  • OBS integration — OBS SRT Toolkit's SRT Output/Source, the OBS Media Source reliability investigation (both shipped); the toolkit's own dedicated encoder, replacing today's reuse-whatever-OBS-already-has-configured behavior (open).
  • Observability — status indicators, event log, traffic counters, diagnostics view, connection metrics (all shipped), plus the topology/signal-flow view and persistent event logging (both open).
  • Core Platform & Config — shared port architecture, per-endpoint SRT config, terminology cleanup (all shipped); custom install ISO/appliance image (open).
  • Backlog (not scheduled) — single-feed destination diagnostics, per-destination preset scoping (see below).

Deliberately not planned

Tracked for visibility, but not committed to any release:

  • Single-feed destination diagnostics (RTMP/RIST/UDP-TS connectivity tracking in the Diagnostics view) — a real, acknowledged gap (see Known Issues), but not scheduled; a bigger lift than a quick add-on to the existing view.
  • Per-destination preset scoping — no current plan; presets stay all-or-nothing across the whole matrix.