Vss Deploy Detection Tracking 2d

# vss-deploy-detection-tracking-2d deploy defaults
#
# Defaults the skill SUGGESTS to the user. The user's choice ALWAYS wins:
#   • Custom NGC ref for a slot   → replaces resolved `<asset>.source`/`path`
#   • Local model file (.onnx)    → replaces resolved `usecases.<X>.model`
#   • Local video file/directory  → replaces resolved `usecases.<X>.videos`
#
# This YAML never auto-deploys — it only pre-fills the *Recommended* choice
# in `AskQuestion` blocks and supplies fall-back values when the user
# accepts the defaults.
#
# Path resolution
# ───────────────
# Per-usecase NGC assets (`model`, `videos`, `labels`, `anchor`, …) are
# objects with two fields:
#
#   source : key into `ngc_resources` — which NGC asset the file lives in.
#            Different assets in the same usecase MAY point at different
#            resources (e.g. model in `rtdetr_model_pkg`, videos in
#            `warehouse_videos`).
#   path   : path RELATIVE TO that resource's `extract_dir`.
#
# Resolved to:
#   host_path      = <paths.resources host-side>/<source.extract_dir>/<path>
#   container_path = <paths.resources>/<source.extract_dir>/<path>
#
# If `path` is just a basename (no `/`) OR the exact relative subpath does
# not exist after extraction, the skill falls back to discovery:
# `find <extract_dir> -name <basename(path)>` (Step 9a). Treat `path` as
# the canonical default and discovery as a safety net for NGC packaging
# changes.
#
# `main_config` / `pgie_config` / `sparse4d_config` are simple strings —
# paths RELATIVE TO `paths.configs` (these files are baked into the
# container image).
# ─────────────────────────────────────────────────────────────────────────────

# ─────────────────────────────────────────────────────────────────────────────
# 1. Docker image (per arch). Skill picks one based on `uname -m` + Tegra check.
#    Multi-arch and SBSA tags publish at different cadences — keep separate.
# ─────────────────────────────────────────────────────────────────────────────
docker_image:
  multi_arch: nvcr.io/nvstaging/vss-core/vss-rt-cv:3.2.0-26.05.1      # x86_64 dGPU + aarch64 Jetson
  sbsa:       nvcr.io/nvstaging/vss-core/vss-rt-cv:3.2.0-sbsa-26.05.1 # SBSA (Spark, Grace-Hopper)

# ─────────────────────────────────────────────────────────────────────────────
# 2. In-container path layout (the image is built around these).
# ─────────────────────────────────────────────────────────────────────────────
paths:
  configs:   /opt/nvidia/deepstream/deepstream/sources/apps/sample_apps/metropolis_perception_app/reference-configs
  engines:   /opt/storage/engines
  resources: /opt/storage/resources
  logs:      /opt/storage/logs

# ─────────────────────────────────────────────────────────────────────────────
# 3. Runtime knobs the skill applies to every `docker run`.
#
#    gpu_id : zero-based GPU index passed as `--gpus '"device=<gpu_id>"'`.
#             Defaults to 0 (deterministic on single-GPU hosts and avoids
#             accidentally claiming every device on a multi-GPU workstation,
#             which `--gpus all` would do). The user can override per-deploy
#             by saying e.g. "run on gpu 1" in the skill query — that
#             overrides this YAML value but does NOT mutate the file.
# ─────────────────────────────────────────────────────────────────────────────
runtime:
  gpu_id: 0

# ─────────────────────────────────────────────────────────────────────────────
# 4. NGC org default — written to ~/.ngc/config when the user has no existing
#    config and didn't override at the prompt.
# ─────────────────────────────────────────────────────────────────────────────
ngc:
  default_org: nvstaging

# ─────────────────────────────────────────────────────────────────────────────
# 5. NGC resource catalog. Each entry is declared ONCE here and referenced by
#    individual assets via `<asset>.source`. A single usecase may pull from
#    multiple resources (e.g. model from one, videos from another).
#
#    kind        : `resource`