Entrance footfall & conversion
IN/OUT at the door gives visits over time; pair it with sales for conversion and with the live inside count for dwell — no separate counter hardware.
All Studio apps
Vision & CCTV
Edge
Counting
line crossing · IN/OUT
Count people across one or more lines drawn on the live video — realtime IN/OUT crossings and a live inside count against a capacity.
Interface preview coming soon
The problem
Footfall and live occupancy drive staffing, conversion and capacity decisions, but the numbers usually live in a separate counting box over the door. Counting reads them straight off the camera you already have — multiple lines per view, drawn on the live frame — and emits every crossing in realtime rather than as a nightly batch.
Use cases
Live occupancy vs capacity
A running inside count against an optional capacity keeps a live occupancy figure for a venue, floor or waiting room without a turnstile.
Multi-line flow
Draw several tagged lines across corridors, gates or aisles and read the flow through each one separately across a shift.
How it works
Input
Live HLS + drawn lines
A worker pulls the live stream over HLS at a fixed cadence. You draw and rotate one or more counting lines with their IN side on a live frame and tag each; they persist per stream as normalized coordinates.
Detect
YOLO11 at a fixed cadence
Detection plus a tracker at a steady 3.5 FPS counts a crossing only when a tracked person passes fully across a line — the fixed cadence is deliberate, so track IDs stay stable.
Signed callback
in / out / occupancy
count.in, count.out and a live count.occupancy flow through the app's HMAC-signed callbacks (webhook + MQTT), each carrying the line, its tag and the tracked crossing.
Your system
Live panel + history
Live totals and inside count show in the app tab; every crossing persists in the app's own counting database for your reporting.
Events it emits
Declared in the plugin manifest and relayed through the app's HMAC-signed callbacks (webhook + MQTT). Anything a worker tries to emit that is not on this list is rejected — no core-event spoofing.
count.in
count.out
count.occupancy
Scope & limits
- Accuracy depends far more on camera placement than model size: an overhead or high-angle view with the line across the walking path counts reliably; frontal, low-angle views cause occlusion misses.
- It counts crossings at walking pace, not a sprint through the door, and counts crossings — not identities.
- Runs co-located on the master or distributed per-stream on edge nodes; change a line and the master re-pushes the resolved config to whichever node holds that stream.
Minimum requirements
- CPU-only default: YOLO11 resizes to 640 px, so a walking-pace entrance runs comfortably at the fixed cadence on ~0.5–1 core per stream plus HLS decode.
- RAM: ~1.5 GB per worker. The yolo11n weights (~6 MB) auto-download on first run; the counting database grows ~100 bytes per crossing.
- GPU optional: a CUDA GPU tracks many streams at once — budget ~200 MB VRAM per stream on a GPU edge node.
Numbers are the plugin authors' honest measurements, not marketing. GPU is optional on every vision plugin except where noted.
Runs as a full app
Every Studio app is a first-class application, not a config modal — and it does not have to live inside StreamHub.
Full-page dashboard view
Opens as its own page inside the tenant app — zones, live panels, history and settings on one surface, not squeezed into a dialog.
Its own database
Keeps its state in a dedicated per-app SQLite database — reads, alerts, occupancy and evidence rows — that you own and can query.
Exportable bundle
Download the app as a self-contained bundle — worker, Dockerfile, compose and an env template — to self-host on your own infra and extend, talking back over the REST API and signed webhooks.
Have cameras or streams to put to work?
Tell us what you are monitoring and we will scope the right apps, wire them into your systems and run them with you. The software is open source — the deployment and operation is what we do.