Docs
Concepts

Sources

In the intended runtime contract, a source supplies frames through a stream, relay, device, or file. Telemetry can accompany those frames when the platform provides it.

Source registration and live ingest are not public services on this site. The JSON below documents the planned shape of that interface.

The ingest design uses common video interfaces rather than a public certified-hardware list. It is intended to treat a recorded file and a live feed as sources for the same later stages.

Registering a source#

source.json
{
  "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 a platform exposes attitude and position, such as gimbal pitch and yaw, altitude, and GPS, the intended runtime can use it to ground the scene. The documented input shapes include MAVLink streams and a phone bridge that forwards device gyro data. These are design records, not a compatibility guarantee for a public service.

The prepared data used by the challenge has no telemetry fields. Its per-frame zone geometry was prepared from visual registration.