Architecture

The appliance keeps video and detection data on separate paths. Video is never decoded or re-encoded on its way to your browser, and the backend never touches a video frame. Detections travel as small messages and are drawn over the frame they were computed on.

flowchart LR
  cam[IP cameras<br/>RTSP] --> relay[Video relay<br/>MediaMTX]
  cam --> pipe[Detection pipeline<br/>DeepStream]
  relay -- "WebRTC video" --> browser[Operator console<br/>in your browser]
  pipe -- "detections" --> api[EdgeVision API]
  api -- "WebSocket + REST" --> browser
  api --- db[(SQLite)]
  api --- models[(Model store)]
  api -. "supervises" .-> pipe
  api -. "keeps camera paths" .-> relay

The three planes

• Video plane. Camera, then relay, then browser over WebRTC. The relay passes the video through without decoding it.
• Metadata plane. The detection pipeline publishes one detection message per frame. The API forwards it over a WebSocket, and the browser draws it over the frame it belongs to.
• Control and state. The API starts and stops the detection pipeline, keeps the relay’s camera paths in place, builds TensorRT engines, handles authentication, and stores all state in a local SQLite database.

Network ports

The device listens on these ports. Allow them on your site network.

Port	Used for
5080/tcp	Operator console and API
8554/tcp	RTSP, served by the relay
8889/tcp	WebRTC signalling (WHEP)
8189/udp	WebRTC media (ICE)

If 8189/udp is blocked, the console connects but no video arrives.

Failure behaviour

• The API can run without video. If the relay stops, camera tiles show no picture but the console keeps working. When the relay comes back, the API restores its camera paths within about 30 seconds, without a restart.
• A release that fails to start is rolled back by the installer, along with the database snapshot taken before it. See Updating a device.

Running and status Check what is running and where its logs are.

API overview The public interfaces and how they are versioned.