Bericht

Erstellen Sie einen Videoanalysebericht, indem Sie die Daten an eines von zwei Backends weiterleiten – niemals über den POST-Befehl /generate auf dem VSS-Agent.

Ist die Anfrage mehrdeutig (z. B. „Bericht über “ ohne Zeitbereich und ohne Angabe des Vorfalls), wird standardmäßig Modus A verwendet. Nur dann abfragen, wenn der Benutzer sowohl einen Sensor als auch einen Zeitbereich angibt. Siehe die folgenden Beispiele für die Anforderungsformulierungen, die zu den jeweiligen Modi führen.

Anleitung

1. Wählen Sie den Modus aus – Modus A für einen einzelnen aufgezeichneten Clip/ein Sensorvideo, Modus B, wenn die Anfrage einen Zeitbereich oder Vorfälle/Warnmeldungen nennt (vergleichen Sie mit den Beispielen).
2. Überprüfen Sie das Bereitstellungsprofil für diesen Modus unter „Voraussetzungen für die Bereitstellung“; leiten Sie die Anfrage an /vss-deploy-profile weiter, falls die Überprüfung fehlschlägt.
3. Führen Sie die nummerierten Schritte des jeweiligen Modus aus – Modus A oder Modus B (siehe unten).
4. Ersetzen Sie jede benutzersichtbare Clip-URL durch die Einzeiler-Formulierung $VSS_PUBLIC_HOST:$VSS_PUBLIC_PORT (im Browser abspielbare Clip-URL), bevor Sie sie in den Bericht einbetten.
5. Geben Sie den gerenderten Markdown-Bericht an den Benutzerzurück.

Ausgabevorgabe für Bewerter:

• Der oberste Titel von Modus A MUSS genau lauten: # Videoanalysebericht.
• Der Titel in Modus B MUSS genau lauten: # Incident Range Report (niemals # Incident Report oder Varianten mit Sensornamen).
• Modus B MUSS „## Basic Information“ mit genau den erforderlichen Zeilen aus der Vorlage enthalten (Berichtskennung, Bereich, Umfang, Gesamtzahl der Vorfälle, Bestätigt / Abgelehnt / Unbestätigt).

Beispiele

• „Bericht für dieses Video erstellen“ / „Bericht über “ → Modus A
• „Analyse von warehouse_01.mp4“ / „Erstelle einen Analysebericht zum hochgeladenen Video“ → Modus A
• „Bericht über Vorfälle von 12:31Z bis 12:32Z“ → Modus B
• „Bericht über die heutigen Warnmeldungen“ / „Welche Vorfälle gab es in der letzten Stunde“ → Modus B
• „Zusammenfassung der Warnmeldungen zwischen und “ → Modus B

Negative Auslöser

Verwende diese Funktion nicht, wenn die Anfrage einer der folgenden Fälle ist:

• Ad-hoc-Fragen und Antworten zu einem Clip, bei denen nicht ausdrücklich um einen Bericht gebeten wird („Welche Farbe hat der Lkw?“, „Was passiert bei 00:12?“) → verwende /vss-ask-video.
• Archiv-/semantische Ähnlichkeitssuche („Gabelstapler finden“, „alle Videos nach zu dichtem Auffahren durchsuchen“) → verwende /vss-search-archive.
• Schreibgeschützte Abfrage von Vorfällen/Metriken ohne Erstellung eines Berichts → verwende /vss-query-analytics.
• Bereitstellung/Abbau/Profiländerungen („Warnmeldungen bereitstellen“, „Profil wechseln“, „Basis aktivieren“) → verwenden Sie /vss-deploy-profile.
• Anfragen zur Verwaltung von Warnmeldungen und Regeln in Echtzeit → verwenden Sie /vss-manage-alerts.

Leiten Sie Berichte niemals über den VSS-Agent -POST-Befehl /generate weiter.

Voraussetzungen für die Bereitstellung

Modus A erfordert das VSS -Basisprofil (VST + VLM NIM). Modus B erfordert das VSS -Alarm profil (VA-MCP + Elasticsearch).

Test:

# Modus A – Erreichbarkeit von VST + VLM
curl -sf --max-time 5 "http://${HOST_IP}:30888/vst/api/v1/sensor/version" >/dev/null

# Modus B – VA-MCP
curl -sf --max-time 5 "http://${HOST_IP}:9901/" >/dev/null

Falls die Überprüfung fehlschlägt, übergeben Sie den Vorgang an /vss-deploy-profile mit dem Parameter -p base (Modus A) oder -p alerts (Modus B). Bestätigen Sie die Bereitstellung immer zuerst mit dem Benutzer.

Clip-URLs: VLM-Eingabe vs. Link zum Browser-Bericht

VST gibt Clip-URLs unter Verwendung des agenteninternen Hosts ${HOST_IP}:30888 aus. Behalten Sie diese ursprüngliche URL als VIDEO_URL für lokale bzw. clusterinterne VLM-Frame-Abrufe bei. Schreiben Sie die VLM-Eingabe-URL nicht um, nur um sie browsertauglich zu machen.

Erstellen Sie BROWSER_CLIP_URL nur für URLs, die im gerenderten Bericht angezeigt werden. Die Bereitstellungsschicht exportiert den browserorientierten Host:Port als $VSS_PUBLIC_HOST / $VSS_PUBLIC_PORT (und das Schema als $VSS_PUBLIC_HTTP_PROTOCOL) in jede .env-Datei des Profils – ob Brev oder Bare-Metal – exportiert, sodass die Umschreibung des Berichtslinks wie folgt lautet:

: "${VSS_PUBLIC_HOST:?Legen Sie VSS_PUBLIC_HOST vor dem Umschreiben der Clip-URLs fest}"
: "${VSS_PUBLIC_PORT:?Legen Sie VSS_PUBLIC_PORT vor dem Umschreiben der Clip-URLs fest}"
VSS_PUBLIC_HTTP_PROTOCOL="${VSS_PUBLIC_HTTP_PROTOCOL:-http}"
BROWSER_CLIP_URL=$(echo "$RAW_URL" | sed -E "s|^https?://[^/]+|${VSS_PUBLIC_HTTP_PROTOCOL}://${VSS_PUBLIC_HOST}:${VSS_PUBLIC_PORT}|")

Falls einer der erforderlichen öffentlichen Host-Werte fehlt, lassen Sie den Clip-Link im Bericht weg und weisen Sie darauf hin, dass keine im Browser abspielbare URL generiert werden konnte; blockieren Sie dabei nicht den lokalen VLM-Analysepfad. Wende die Umschreibung auf jede Clip-URL an , die im gerenderten Bericht erscheint (Modus A, Schritt 4, Zeile „Clip-URL“; Modus B, Unterpunkt „Clip pro Vorfall“). Belasse den VLM-Inhaltsblock „video_url“ in Modus A, Schritt 3, auf der ursprünglichen internen URL, wenn das VLM lokal bzw. im Cluster ist.

Modus A – Bericht zu einem aufgezeichneten Videoclip

Wenn das VSS-lvs-Profil bereitgestellt ist – „curl -sf --max-time 5 "http://${HOST_IP}:38111/v1/ready"“ gibt HTTP 200 zurück – führen Sie „/vss-summarize-video“ aus, um die Zusammenfassung zu erstellen, fügen Sie anschließend die Ausgabe in die Berichtsvorlage in Schritt 4 ein und überspringen Sie die Schritte 1–3 (den VLM-Direktpfad). Führen Sie die Schritte 1–3 nur aus, wenn /v1/ready nicht den Status 200 zurückgibt.

Schritt 1 – Die Clip-URL auflösen

Übergeben Sie die Aufgabe an /vss-manage-video-io-storage, um:

1. Sensoren aufzulisten und zu überprüfen, ob der genannte tatsächlich existiert (falls nicht, zuerst hochladen).

2. Rufen Sie /storage//timelines für den aufgezeichneten Bereich ab, wenn der Benutzer keine startTime- und endTime-Angaben gemacht hat.

3. Eine Clip-URL anfordern:

   curl -s "http://${HOST_IP}:30888/vst/api/v1/storage/file//url?startTime=&endTime=&container=mp4&disableAudio=true" | jq -r .videoUrl
   

   Dadurch erhält man eine direkte MP4-URL, aus der das lokale bzw. clusterinterne VLM Einzelbilder abrufen kann. Binden Sie diese an VIDEO_URL (die vom VLM in Schritt 3 verwendet wird) und setzen Sie RAW_URL="$VIDEO_URL", bevor Sie die Neuschreibung des Berichtslinks anwenden, um BROWSER_CLIP_URL für Schritt 4 zu erzeugen – der Browser des Benutzers kann $VIDEO_URL nicht direkt erreichen. Modus A setzt voraus, dass der ausgewählte VLM-Endpunkt in der Lage ist, VIDEO_URL abzurufen. Lokale NIM-/RT-VLM-Bereitstellungen sind dazu normalerweise in der Lage; entfernte Endpunkte können im Allgemeinen keine localhost-, private HOST_IP- oder VST-interne URLs abrufen. Wenn der Live- VLM_ENDPOINT remote ist, sollte diese Erreichbarkeitsanforderung deutlich gemacht werden, anstatt eine Chat-Anfrage zu stellen, die fehlschlägt, nachdem /v1/models erfolgreich war.

Schritt 2 – VLM-Endpunkt und Modell ermitteln

Die Bereitstellung kann das VLM über einen von zwei Stacks bereitstellen. Beide stellen eine OpenAI-kompatible Chat-/Vervollständigungs-API bereit – wählen Sie diejenige aus, die aktiv ist:

Lies die Live-Werte aus dem laufenden Agent-Container aus – rate nicht:

docker exec vss-agent sh -lc '
for k in HOST_IP VLM_MODE VLM_MODEL_TYPE VLM_BASE_URL VLM_NAME RTVI_VLM_BASE_URL RTVI_VLM_MODEL_TO_USE; do
  v="$(printenv "$k")"
  [ -n "$v" ] && printf "%s=%s\n" "$k" "$v"
done
'

RTVI_VLM_ENDPOINT darf nicht in der vss-agent -Umgebung erforderlich sein; mehrere Profile fügen es nicht ein.

Auswahlregel:

if [ "${VLM_MODEL_TYPE:-}" = "rtvi" ]; then
  VLM_BACKEND="rtvlm"
  VLM_ENDPOINT="${RTVI_VLM_BASE_URL:+${RTVI_VLM_BASE_URL%/}/v1}"
  [ -z "${VLM_ENDPOINT}" ] && VLM_ENDPOINT="http://${HOST_IP}:8018/v1"   # Standard für Warnmeldungen
  VLM_MODEL="${RTVI_VLM_MODEL_TO_USE}"
elif [ -n "${VLM_BASE_URL}" ] && [ "${VLM_MODE}" != "none" ]; then
  VLM_BACKEND="nim_cosmos"
  VLM_ENDPOINT="${VLM_BASE_URL%/}/v1"
  VLM_MODEL="${VLM_NAME}"
else
  VLM_BACKEND="rtvlm"
  VLM_ENDPOINT="${RTVI_VLM_BASE_URL:+${RTVI_VLM_BASE_URL%/}/v1}"
  [ -z "${VLM_ENDPOINT}" ] && VLM_ENDPOINT="http://${HOST_IP}:30082/v1"  # Standardwert
  VLM_MODEL="${RTVI_VLM_MODEL_TO_USE}"
fi

Überprüfen Sie /v1/models, bevor Sie eine Chat-Anfrage senden, um sicherzustellen, dass der ausgewählte Endpunkt erreichbar ist und das Modell geladen wurde:

curl -sf --max-time 5 "${VLM_ENDPOINT}/models" | jq -r '.data[].id'

Wenn die Überprüfung fehlschlägt oder die aufgelisteten IDs ${VLM_MODEL} nicht enthalten, weichen Sie auf das andere Backend aus (oder geben Sie den Fehler aus – wählen Sie niemals stillschweigend ein Modell aus, das nicht auf dem Server vorhanden ist).

Schritt 3 – Das VLM direkt aufrufen

Verwende den OpenAI-kompatiblen Chat-/Vervollständigungs-Endpunkt mit einem „video_url“-Inhaltsblock – dieselbe Payload-Struktur und dieselben multimodalen Einstellungen, die video_understanding in src/vss_agents/tools/video_understanding.py erstellt (_build_vlm_messages + der Cosmos-Aufruf ` base_vlm.bind(...) `).

Die Frame-Abtastung und das Budget für visuelle Token (Pixel) müssen den Live -Einstellungen von „video_understanding“ für das aktive Profil entsprechen. Senden Sie „mm_processor_kwargs“ und „media_io_kwargs“, damit der direkte Aufruf dieselbe Bildabtastung und dasselbe Pixelbudget verwendet wie das agenteneigene „video_understanding“-Tool – werden diese Parameter weggelassen, wendet das VLM seine eigenen Standardwerte an, sodass die Ausgabe vom Agentenpfad abweicht.

PROMPT='Beschreibe detailliert, was im Video geschieht, mit Zeitstempeln (Start–Ende in Sekunden ab Clip-Start) für jedes Segment oder Ereignis. Beziehe Szenen, Objekte, Personen, Fahrzeuge und bemerkenswerte Handlungen mit ein.'

# „Reasoning“ ist standardmäßig deaktiviert – entspricht der „video_understanding“-Konfiguration des Basisprofils (`reasoning: false`).
# „video_understanding.py“ verwendet „config.reasoning“, sofern der Aufrufer dies nicht überschreibt; daher ist standardmäßig kein „Reasoning“ aktiviert.
# Füge das „Cosmos Reason 2“-Suffix NUR dann an, wenn der Benutzer ausdrücklich nach einer Begründung fragt
# (lasse es bei VLMs ohne „Cosmos Reason 2“ weg). Bei deaktivierter Begründung enthält die Antwort keinen  Block.
if [ "${REASONING:-false}" = "true" ]; then
PROMPT="${PROMPT}

Beantworte die Frage im folgenden Format:


Deine Begründung.


Schreibe deine endgültige Antwort unmittelbar nach dem  Tag ."
fi

# Wenn Schritt 3 eigenständig ausgeführt wird, wird das fehlende Backend aus der aktuellen Umgebung/dem aktuellen Modell abgeleitet.
[ -z "${VLM_BACKEND:-}" ] && {
  if [ "${VLM_MODEL_TYPE:-}" = "rtvi" ]; then
    VLM_BACKEND="rtvlm"
  elif [[ "${VLM_MODEL:-}" == nvidia/cosmos* ]]; then
    VLM_BACKEND="nim_cosmos"
  else
    VLM_BACKEND="rtvlm"
  fi
}

# Multimodale Einstellungen – werden anhand des Pfads zur Konfigurationsdatei des Live-Agenten ermittelt, nicht anhand fest codierter Optionen.
CFG_JSON=$(
docker exec vss-agent python3 -c '
import json, os, yaml
p = os.getenv("VSS_AGENT_CONFIG_FILE")
if not p:
    raise SystemExit("VSS_AGENT_CONFIG_FILE ist im vss-Agent nicht gesetzt")
if not os.path.isabs(p):
    p = os.path.join("/vss-agent", p.lstrip("./"))
with open(p, encoding="utf-8") as f:
    cfg = yaml.safe_load(f) or {}
vu = (cfg.get("functions", {}) or {}).get("video_understanding", {}) or {}
print(json.dumps({
    "max_fps": int(vu.get("max_fps", 2)),
    "max_frames": int(vu.get("max_frames", 30)),
    "min_pixels": int(vu.get("min_pixels", 3136)),
    "max_pixels": int(vu.get("max_pixels", 8388608)),
}))
')
)
[ -n "${CFG_JSON}" ] || { echo "Das Einlesen der video_understanding-Konfiguration vom vss-Agent ist fehlgeschlagen"; exit 1; }
jq -e . >/dev/null <<< "${CFG_JSON}" || { echo "Ungültige JSON-Konfiguration vom vss-Agent"; exit 1; }
MAX_FPS="$(jq -r '.max_fps' <<< "${CFG_JSON}")"
MAX_FRAMES="$(jq -r '.max_frames' <<< "${CFG_JSON}")"
MIN_PIXELS="$(jq -r '.min_pixels' <<< "${CFG_JSON}")"
MAX_PIXELS="$(jq -r '.max_pixels' <<< "${CFG_JSON}")"

# num_frames = min(int(clip_seconds) * max_fps, max_frames), min 1 — entspricht video_understanding.py.
# clip_seconds (Schritt 1: endTime – startTime) kann einen Bruchwert enthalten; auf ganze Sekunden abschneiden — bash $((...))
# akzeptiert nur ganze Zahlen und gibt bei „15,0“/„1,5“ einen Fehler aus. Standardwert 15 s -> Begrenzung auf MAX_FRAMES.
CLIP_SECONDS=$(awk -v s="${CLIP_SECONDS:-15}" 'BEGIN{printf "%d", s}')
NUM_FRAMES=$(( CLIP_SECONDS * MAX_FPS ))
[ „$NUM_FRAMES“ -gt „$MAX_FRAMES“ ] && NUM_FRAMES=$MAX_FRAMES
[ „$NUM_FRAMES“ -lt 1 ] && NUM_FRAMES=1

# Wende die Cosmos-mm/media-Kwargs nur auf den NIM-Cosmos-Pfad an.
# Der RT-VLM-Modus verwendet eine eigene serverseitige Vorverarbeitung und sollte diese Kwargs nicht erhalten.
MM_KWARGS=""
if [ "${VLM_BACKEND}" = "nim_cosmos" ]; then
  case "$VLM_MODEL" in
    *cosmos-reason2*) MM_KWARGS=", \"mm_processor_kwargs\": {\"size\": {\"shortest_edge\": ${MIN_PIXELS}, \"longest_edge\": ${MAX_PIXELS}}}, \"media_io_kwargs\": {\"video\": {\"num_frames\": ${NUM_FRAMES}}}" ;;
    *cosmos*)         MM_KWARGS=", \"mm_processor_kwargs\": {\"videos_kwargs\": {\"min_pixels\": ${MIN_PIXELS}, \"max_pixels\": ${MAX_PIXELS}}}, \"media_io_kwargs\": {\"video\": {\"num_frames\": ${NUM_FRAMES}}}" ;;
    *)                      MM_KWARGS="" ;;
  esac
fi

curl -s --connect-timeout 5 --max-time 120 -X POST "${VLM_ENDPOINT}/chat/completions" \
  -H "Content-Type: application/json" \
  -d @- <<EOF | jq -r '.choices[0].message.content'
{
  "model": $(jq -Rs . <<< "${VLM_MODEL}"),
  "messages": [
    {
      "role": "user",
      "content": [
        {"type": "text", "text": $(jq -Rs . <<< "${PROMPT}")},
        {"type": "video_url", "video_url": {"url": $(jq -Rs . <<< "${VIDEO_URL}")}}
      ]
    }
  ],
  "max_tokens": 1024,
  "temperature": 0.0${MM_KWARGS}
}
EOF

Der „kwargs“-Block ist backendabhängig: Auf nim_cosmos verwenden Reason2-Varianten (nvidia/cosmos-reason2*) „mm_processor_kwargs.size{shortest_edge,longest_edge} “, während andere NIM-Cosmos-Varianten (nvidia/cosmos*) „mm_processor_kwargs.videos_kwargs{min_pixels,max_pixels}; beide senden zudem „media_io_kwargs.video.num_frames“. Auf rtvlm werden keine Cosmos-Kwargs gesendet.

Wenn der VLM einen … Block (Cosmos-Reason-Inferenzmodus) zurückgibt, behalte nur den Text nach als Berichtstext.

Schritt 4 – Füllen Sie die Vorlage für den Videoanalysebericht aus

Kopieren Sie „assets/video-analysis-report.md“, füllen Sie alle Platzhalter aus und geben Sie das gerenderte Markdown an den Benutzer zurück. Lassen Sie die Quelldatei unverändert. Überprüfen Sie vor dem Rendern, ob BROWSER_CLIP_URL gesetzt und nicht leer ist, und ersetzen Sie dann durch genau diesen Wert in der Zeile „Clip-URL “. Lassen Sie den Platzhalter niemals in der Ausgabe stehen, fügen Sie niemals Vorlagenanweisungen in eine ausgefüllte Zelle ein und verwenden Sie niemals die rohe URL ` HOST_IP:30888 `.

Modus B – Bericht über Vorfälle in einem Zeitbereich

Schritt 1 – Bestimme den Zeitbereich und (optional) den Sensor

• start_time / end_time müssen im ISO 8601 UTC-Format (YYYY-MM-DDTHH:MM:SS.sssZ) vorliegen. Relative Zeitangaben („letzte Stunde“, „heute“) sind anhand der aktuellen Host-Uhr zu interpretieren.
• Wenn der Benutzer einen Sensor angibt, erfassen Sie diesen als source + source_type=sensor. Andernfalls lassen Sie beide Felder unbesetzt, um eine Abfrage für alle Sensoren durchzuführen.

Schritt 2 – Abrufen von Vorfällen über /vss-query-analytics

Weiterleitung an /vss-query-analytics (initialisieren → tools/call) mit:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "video_analytics__get_incidents",
    "arguments": {
      "source": "",
      "source_type": "sensor",
      "start_time": "",
      "end_time": "",
      "max_count": 100,
      "includes": ["objectIds", "info"]
    }
  },
  "id": 1
}

Schreibgeschützte Grenze (obligatorisch):

• Modus B ist ausschließlich für den schreibgeschützten Abruf von Analysedaten vorgesehen. Schreiben, Seeding, Backfilling oder das Ändern von Elasticsearch-/VA-Daten ist strengstens untersagt.
• Verbotene Beispiele: Indizierung synthetischer Vorfälle, Wiedergabe von Testdaten in ES, Aufruf von Schreib-/Aktualisierungs-/Lösch-APIs, um Daten für den Bericht „verfügbar zu machen“.
• Falls für den angeforderten Bereich/Umfang keine Vorfälle vorhanden sind, behandeln Sie dies als leere Ergebnisse (siehe unten); erfinden Sie keine Daten.

Behalten Sie für jeden Vorfall folgende Angaben bei: id, sensorId, timestamp, end, category, place.name, info.verdict, info.reasoning, objectIds und die Clip-URL (in der Regel info.clip_url, clip_url oder das Feld mit dem Clip-Zeiger, das die Antwort enthält). Wenden Sie die Umschreibung $VSS_PUBLIC_HOST:$VSS_PUBLIC_PORT (siehe „Im Browser abspielbare Clip-URL“ oben) auf jede Clip-URL an, bevor Sie sie in den Bericht einfügen – der Rohwert ist eine HOST_IP:30888-URL, die der Browser des Benutzers nicht erreichen kann.

Schritt 3 – Füllen Sie die Vorlage für den Vorfallbereichsbericht aus

Kopieren Sie „assets/incident-range-report.md“, gruppieren Sie dann nach Sensor (oder nach Kategorie, falls kein Sensorbereich vorhanden ist), zählen Sie die Beurteilungen zusammen und listen Sie jeden Vorfall mit Zeitstempel, Kategorie, Beurteilung und Begründung auf. Lassen Sie die Quelldatei unverändert. Jeder Wert für einen Vorfall-Clip muss eine umgeschriebene, im Browser abspielbare URL sein; lassen Sie die Clip-Zeile weg, wenn der Vorfall keine Clip-URL enthält. Fügen Sie niemals Vorlagenanweisungen in eine ausgefüllte Zelle ein.

Wenn „get_incidents“ null Ergebnisse zurückgibt, STOPPEN Sie den Vorgang und geben Sie genau eine einzeilige „Empty-Range“-Anweisung zurück, in der der angeforderte Bereich und der Geltungsbereich genannt werden. Rendern Sie nicht die vollständige Vorlage für den Vorfallbereich, erfinden Sie keine Vorfälle, fügen Sie keine Testdaten ein und greifen Sie nicht auf Modus A zurück.

Fehlerbehandlung

• Wenn ein Probe-, curl-, VLM-Aufruf oder eine /vss-query-analytics-Anfrage fehlschlägt, brechen Sie den Workflow ab und melden Sie den fehlerhaften Endpunkt, den HTTP-Status oder den Befehlsfehler sowie den nächsten sinnvollen Schritt zur Fehlerbehebung. Erstellen Sie keinen Bericht auf der Grundlage unvollständiger oder fehlender Daten.
• Wenn die VLM-Antwort leer oder fehlerhaft ist oder nur einen Begründungsblock enthält, weisen Sie auf dieses Antwortproblem hin und schlagen Sie vor, vor einem erneuten Versuch die Modellbereitschaft bzw. die Protokolle zu überprüfen.
• Wenn eine Clip-URL nicht auf den öffentlichen Host/Port umgeschrieben werden kann, lassen Sie sie im erstellten Bericht weg und weisen Sie darauf hin, dass die im Browser abspielbare URL nicht generiert werden konnte.
• Behandeln Sie bei Modus B fehlende optionale Vorfallfelder (info.reasoning, objectIds, Clip-URL) als Auslassungen im Bericht, behandeln Sie jedoch fehlende IDs, Zeitstempel oder Kategorien als Datenqualitätsfehler, die gemeldet werden sollten.

Querverweis

• /vss-manage-video-io-storage – Sensorliste, Zeitachsen und Clip-URL für Modus A, Schritt 1.
• /vss-query-analytics – Abruf von Vorfällen (sowie Anreicherung mit Beurteilungen und Begründungen) für Modus B, Schritt 2.
• /vss-ask-video – Ad-hoc-VLM-Frage-und-Antwort-Funktion für einen einzelnen Clip (kein strukturierter Bericht).
• /vss-summarize-video – wird von Modus A verwendet, um den Zusammenfassungstext zu erstellen, wenn das LVS-Profil bereitgestellt ist; die Berichtsvorlage (Schritt 4) wird hier weiterhin ausgefüllt.