vss-deploy-detection-tracking-3d

Deploy and operate the RTVI-CV-3D microservice as MV3DT (`MODE=mv3dt`): per-camera DeepStream perception plus BEV Fusion over calibrated cameras. Supports the bundled sample dataset, custom video files, and RTSP streams, and chains to `vss-generate-video-calibration` when calibration is missing. Use `vss-deploy-profile` for the full warehouse blueprint and `vss-deploy-detection-tracking-2d` for single-camera 2D detection.

2,741stars319forksUpdated 7/31/2026

DevOps & CI/CD #object-detection #docker #devops #deployment #nvidia #computer-vision

Security Assessment

Low Risk(80/100)

Detected risks:

Destructive Filesystem and Volume Teardown(The teardown and nuke procedures recursively delete bind-mounted calibration and auto-calibration project directories using elevated sudo privileges, which permanently removes data if the wrong dataset slug is targeted., Deployment teardown drops named docker volumes and runs a cleanup script that deletes Elasticsearch indexes, Kafka logs, and VST sensor state, so redeploys start from a clean but data-losing state., The scripts guard destructive actions by checking the dataset name against the shipped sample and surfacing commands for manual confirmation when passwordless sudo is unavailable.)

Security Score80/100

About vss-deploy-detection-tracking-3d

vss-deploy-detection-tracking-3d deploys and operates NVIDIA's RTVI-CV-3D microservice in MV3DT mode (MODE=mv3dt) — per-camera DeepStream perception combined with BEV Fusion over multiple calibrated cameras — as part of the Video Search and Summarization warehouse blueprint. It solves the problem of bringing up a multi-camera 3D detection-and-tracking stack without the full warehouse agent/LLM/VLM stack, working against a bundled sample dataset, custom video files, or live RTSP streams.

The skill is routing-driven: it asks the user at most four questions (profile size, data source, calibration coverage, dataset slug) and then dispatches to detailed reference procedures for deployment, the calibration chain, camera configuration, verification, teardown, and troubleshooting. It drives docker-compose env overrides for extended (with ELK, analytics API, Kibana overlays) or minimal profiles, chains to vss-generate-video-calibration when calibration is missing, and manages the MQTT bus, broker, and VST sensor stack. Teardown procedures cover stopping containers, resetting named docker volumes, targeted volume cleanup, a data-log cleanup script, and an explicit destructive "nuke" option that removes bind-mounted calibration and AMC project state via sudo.

It targets DevOps and computer-vision engineers deploying warehouse/industrial multi-camera tracking on NVIDIA infrastructure. Related skills handle the full warehouse blueprint (vss-deploy-profile) and single-camera 2D detection (vss-deploy-detection-tracking-2d).

FAQ

What gets deployed?

The RTVI-CV-3D microservice as MV3DT: per-camera DeepStream perception plus BEV Fusion, a mosquitto MQTT bus, broker, and VST sensor stack, optionally with an extended profile adding ELK, a video-analytics API, and Kibana for bounding-box overlays.

What data sources are supported?

A bundled 4-camera synthetic sample dataset, local video files named after cameras, or live RTSP streams. Videos and RTSP run calibration (standalone AMC or VIOS-driven AMC) when calibration is not already on disk.

What is the difference between the extended and minimal profiles?

Extended (the default) includes ELK, the analytics API, and Kibana so overlays render in the VST video wall. Minimal brings up MV3DT core only — about five fewer containers, no overlays, but metadata still flows on Kafka/Redis.

How do I tear the stack down cleanly?

Use docker compose down (optionally with -v to reset named volumes), then a shipped cleanup_all_datalog.sh script with the --skip-revert-from-oldest-backup flag; a separate nuke option additionally removes bind-mounted AMC and custom calibration state via sudo.

Is my calibration data preserved across teardown?

Yes, by default. Calibration outputs and AMC project state are bind-mounted and intentionally not deleted, so the next deploy reuses them, unless you explicitly run the destructive nuke option.