Sources

Praxis is deliberately boring about ingest. If OpenCV can read it, the runtime can run on it. There is no vendor SDK requirement and no certified-hardware list. The same pipeline that processes a live gimbal feed also processes an MP4 you recorded last week, which is how all of our ground-truth testing works.

Registering a source#

{
  "id": "src_boulevard",
  "kind": "rtsp",
  "uri": "rtsp://10.0.4.21:8554/main",
  "fps_hint": 30,
  "telemetry": {
    "mode": "mavlink",
    "endpoint": "udp://10.0.4.21:14550"
  }
}

kind is one of rtsp, udp, file, or device. The telemetry block is optional. Without it, zones still anchor visually (see Zones); with it, they can also be grounded in world coordinates.

The frame hub#

Decoding and inference are decoupled. A reader thread owns the source and keeps the latest frame in a hub; the inference loop takes whatever is newest when it's ready for more work. Two consequences of this design:

• A slow model never causes the stream to back up. The runtime processes the most recent frame, not a growing backlog, so latency stays flat instead of compounding.
• Frames can be skipped under load. Counting logic tolerates this because tracking carries identity across gaps, but it does mean per-frame outputs are not guaranteed to be contiguous.

Telemetry#

When the platform exposes attitude and position (gimbal pitch and yaw, altitude, GPS), the runtime uses it to ground the scene. Telemetry-grounded zones survive aggressive camera moves that would strain pure visual anchoring. Supported inputs today are MAVLink streams and a phone bridge that forwards device gyro data, which we use for handheld testing.