Surveillance analytics with queryable live video
Surveillance analytics software interprets live or recorded video to support monitoring and review. Overshoot supplies a developer API for language-based questions over live WebRTC video and 600 seconds of recent Stream history. Your application chooses when to query, what visual interval to reference, and how a person reviews the answer. Camera management, direct camera-protocol ingest, continuous recording, identity, long-term storage, policy enforcement, and a finished security dashboard remain responsibilities of your product or existing video system.
- Response
- 200msTypical response time for Overshoot-hosted vision models.
- Live ingest
- WebRTCPublish through LiveKit from browser, native, or server code.
- History
- 600 secondsReference recent frames by index, timestamp, or live-edge offset.
- Lease
- 300 secondsRenew with a keepalive, which also returns a fresh publish token.
- Output
- SSEStream chat-completion tokens until the data: [DONE] marker.
Use Overshoot as an analysis layer
The API fits teams building a custom monitoring interface, adding visual context to an existing event, or creating a review assistant. A motion signal or user request can trigger a focused question about the latest frame or a short preceding interval. The VLM can describe visible scene state, summarize a transition, or organize review items using language defined by the application.
Overshoot is not a packaged video-management system. The public contract does not include direct RTSP, RTMP, or ONVIF ingest, 24-hour recording, camera fleet administration, or an operations dashboard. Publish video through a browser, native, or server LiveKit client. Keep recording and camera control in the system already designed for those jobs.
Select live context around an event
frame_index=-1 answers a question about the current view. An exact frame or timestamp supports repeatable review. A video_url reference with start_offset_ms=-5000 inspects the previous five seconds through the live edge. max_fps defaults to 1.0, which may suit slow scene changes. Test a higher value only when faster motion affects task quality.
The 600-second history gives an event pipeline time to ask follow-up questions. It is rolling and temporary. Persist source evidence in your own approved store if an investigation or policy requires longer retention. Log the Stream id, media anchor, region, prompt version, model id, and response with the event. This record explains what the model actually received.
Write policy-aware prompts
Ask about observable activity and scene context using a narrow vocabulary. Include an unknown or insufficient-view result. Avoid inferring identity, intent, protected traits, or facts that are not visually supported. A useful prompt can request a one-sentence description, a list of visible evidence, and an allowed event category. Validate every machine-consumed field.
Keep policy enforcement in application code. Define which users, cameras, times, and purposes permit inference. Limit model output and access to source evidence. Require human review for consequential security, employment, housing, or access decisions. A VLM response can prioritize attention, yet it should not become an unexplained final judgment.
Operate a reliable live session
Create the Stream under /v1beta and publish to its LiveKit room. Renew its 300-second lease before expiry. Each keepalive returns a fresh token for the publisher. Track recent frame arrival through Stream status. If the Stream moves to ended, create a replacement. Delete Streams on deliberate shutdown and stop querying after source video becomes stale.
Use us-west1 or us-central1 and keep all Stream references in a multi-source request within one region. Plan for network loss, publisher interruption, model unavailability, and partial SSE responses. The interface should tell an operator whether the source is live, reconnecting, stale, or unavailable. Silent failure creates more risk than a visible gap.
Evaluate accuracy, latency, and reviewer load
Build a labeled set from the actual camera positions, times of day, weather, crowd levels, occlusion, compression, and empty scenes. Measure event-level false positives and false negatives. Include ambiguous examples where unknown is correct. Track how often a reviewer needs to open the source clip and how quickly they can resolve an item.
Overshoot-hosted models respond in 200ms. Measure from the event trigger to the first usable output on the deployed network. Record model, region, frame count, segment duration, max_fps, prompt, output limit, load, and percentile. A server-stage benchmark does not describe the complete monitoring workflow. Test bursts because event sources often cluster.
Deploy with privacy and evidence controls
Document the purpose for each visual source and inference. Apply least-privilege access to API credentials, camera mappings, answers, and retained artifacts. Decide which data may enter logs. Set retention in the systems that store durable evidence. The Overshoot Stream window is 600 seconds and should not be treated as the product retention policy.
Begin with a low-consequence review queue and compare it with the current process. Expose source evidence beside every answer. Add actions only after policy, error handling, and measured task performance are accepted. This approach uses VLMs to make recent video easier to inspect while keeping surveillance governance and final decisions in accountable application workflows.
References
Prototype a review-first analytics workflow
Query a low-consequence event, show the source beside the answer, and measure reviewer corrections.