I tried real-time monitoring of video with VSS Event Reviewer

Introduction

Hello, I'm Morishige from Classmethod's Manufacturing Business Technology Division.

In a previous article, I deployed Standard VSS of VSS (Video Search and Summarization) on DGX Spark and tried searching archived footage and Japanese Q&A. Last time, I had an early look at the microservice-based architecture with the 3.0.0 EA Warehouse Blueprint.

This time, I used "Event Reviewer," another deployment mode of VSS 2.4.1 GA, to build a real-time camera monitoring environment. If Standard VSS is a tool for "searching recorded footage after the fact," Event Reviewer is a tool for "automatically verifying detected events happening right now."

GroundingDINO detects cardboard boxes on a conveyor belt through object detection, and a VLM (Cosmos-Reason2-8B) looks at the footage to determine "is there damage to the box?" This two-stage approach of CV + VLM runs on a single DGX Spark.

What is Event Reviewer

Differences from Standard VSS

VSS has two deployment modes: Standard VSS and Event Reviewer. Standard VSS, which was used in the previous article, generates captions with a VLM when footage is uploaded, indexes it into a vector DB and graph DB, and allows natural language searching later.

Event Reviewer has a different concept. When a CV pipeline (object detection model) triggers a "something detected" event, the VLM reviews a short clip of footage to determine "is that really the case?" In other words, it's a mechanism where the VLM double-checks the CV detection results.

Source: VSS Blueprint Architecture — NVIDIA Documentation

Looking at the official architecture diagram, you can see the flow from left to right: CV Pipeline Manager UI → CV Pipeline (GroundingDINO, etc.) → Alert Bridge → VLM → Alert Inspector UI. Video Storage Toolkit (VST) handles clip storage, and components are connected via REST API and Redis Streams.

Imagining a manufacturing site, the distinction in use cases is as follows.

Standard VSS is a post-hoc analysis type. It is suited for use cases like searching a week's worth of manufacturing line footage for "scenes where a product fell" to analyze the cause. It requires a full stack of VLM plus LLM and RAG, resulting in a larger number of containers.

Event Reviewer is a real-time monitoring type. When a cardboard box on a conveyor belt is detected, the VLM reviews the footage to determine "is there damage?" It can also be used for checking workers' safety equipment. RAG is not needed and it runs on VLM alone, making it lightweight.

Component Configuration

Event Reviewer is composed of 2 Docker Composes.

The Event Reviewer main body (deploy/docker/event_reviewer/) has 6 services. The core components are via-server (VLM inference), Alert Bridge (event ingestion and distribution to VLM), and Alert Inspector UI (review screen). The remaining storage-ms (Video Storage Toolkit) handles clip storage, Redis serves as the event bus, and api-gateway serves as the Nginx reverse proxy.

The CV pipeline (examples/cv-event-detector/) has 2 services: nv-cv-event-detector handles object detection with GroundingDINO and clip generation, and cv-ui provides the operation screen for detection settings.

That's 8 containers total. Compared to the 42 containers in the previous 3.0.0 EA (Warehouse Blueprint), this is quite compact.

The overall data flow looks like the following when diagrammed.

What the Blueprint provides goes up to the green and blue sections. The red external integration is designed to be implemented by reading from Redis Streams or WebSocket.

Deploying Event Reviewer on DGX Spark

Prerequisites

VSS is an NVIDIA AI Blueprint published as open source on GitHub. First, clone the repository.

git clone https://github.com/NVIDIA-AI-Blueprints/video-search-and-summarization.git
cd video-search-and-summarization

Starting Event Reviewer

The deployment path for Event Reviewer is separate from Standard VSS and is located at deploy/docker/event_reviewer/.

cd deploy/docker/event_reviewer

# Start cache cleaner (recommended for DGX Spark ARM environment)
sudo sh ../scripts/sys_cache_cleaner.sh &

# Create Docker network (shared with CV pipeline)
docker network create vss-shared-network

# Clear VST volume
rm -rf vst/vst_volume/*

# Start (IS_SBSA=1 is required for DGX Spark)
IS_SBSA=1 ALERT_REVIEW_MEDIA_BASE_DIR=/tmp/alert-media-dir docker compose up -d

IS_SBSA=1 is the same flag used in the previous and the one before, which switches the container image suffix to -sbsa for DGX Spark (ARM64 / SBSA). ALERT_REVIEW_MEDIA_BASE_DIR is the storage destination for clips generated by the CV pipeline, a shared directory mounted by both Event Reviewer and the CV pipeline.

One note of caution here: via-server takes time to download Cosmos-Reason2-8B (approximately 17GB) and load vLLM, so on the first run it takes several minutes until the healthcheck passes. Since alert-bridge and alert-inspector-ui depend on via-server's health, if you run docker compose up -d while via-server is unhealthy, it may stall at Created.

# Wait for via-server to start
docker compose logs -f via-server | grep -i "health\|ready"

# Once healthy, run up again (alert-bridge and UI will start)
IS_SBSA=1 ALERT_REVIEW_MEDIA_BASE_DIR=/tmp/alert-media-dir docker compose up -d

From the second run onward, the model is cached in the Docker volume (event_reviewer_via-hf-cache), so it takes approximately 80 seconds until vLLM loading is complete.

Once all services have started, let's verify them.

docker compose ps

It's OK if all 6 services show running (healthy).

Accessing the Alert Inspector UI

Open http://<DGX Spark IP>:7860 in your browser to access the Alert Inspector UI.

It's a Gradio-based UI with an integrated alert table list, video preview, and chat functionality with the VLM. At this point, the CV pipeline has not been started yet, so alerts are in an empty state.

Enabling Object Detection with the CV Pipeline

What is GroundingDINO

The Event Reviewer main body has the CV pipeline disabled by default (DISABLE_CV_PIPELINE=true). The CV pipeline is started independently in a separate directory, examples/cv-event-detector/.

This sample pipeline uses GroundingDINO (swin_tiny) as an open-vocabulary object detection model. "Open vocabulary" means it's not bound to a predefined class list (person, car, dog...) and can detect arbitrary objects using text prompts. Write "cardboard box ." to detect cardboard boxes, or "Person . Hard hat ." to detect people and helmets.

Starting the CV Pipeline

cd ~/video-search-and-summarization/examples/cv-event-detector

IS_SBSA=1 ALERT_REVIEW_MEDIA_BASE_DIR=/tmp/alert-media-dir docker compose up -d

On first startup, the nv-cv-event-detector container converts the GroundingDINO ONNX model to a TensorRT FP16 engine. In ARM SBSA environments it falls back to strongly typed mode, but this does not affect operation.

Once startup is complete, access the CV UI.

Processing Video in the CV UI

Open http://<DGX Spark IP>:7862 to see the Computer Vision Pipeline Manager (CV UI).

This time, instead of the warehouse footage used in V1/V2, I'll use the conveyor belt inspection footage included in the samples (conveyor_belt_inspection_sdg_1080p.mp4). This is a 1080p 30fps video created with NVIDIA's Synthetic Data Generation (SDG) tool, showing cardboard boxes flowing along a blue-framed belt conveyor.

I configured the CV UI as follows.

In Detection Parameters, specify cardboard box as the detection class. GroundingDINO detects cardboard boxes on the belt conveyor, and when the detection count exceeds the Object Detection Threshold, an event clip is generated.

In VSS Alert Parameters, turn Enable Yes/No Verification ON and set the inspection prompt in Alert Prompts.

You are a warehouse conveyor belt inspection system. You must inspect the
cardboard box on the conveyor belt to look for signs of physical damage.
Physical damage includes Crumpling, Tearing, Dents, Creases, Open boxes.
Does the cardboard box clearly show signs of physical damage?

Pressing "Process Video" causes GroundingDINO to analyze the footage and generate event clips. From the 82-second conveyor belt footage, 38 event clips were generated (processing time was approximately 28 minutes). The generated clips are automatically sent to Alert Bridge, and the VLM (Cosmos-Reason2-8B) judges each one in turn for "does the cardboard box have damage?"

Checking Verification Results in the Alert Inspector UI

Returning to the Alert Inspector UI, the VLM verification results are displayed in the table.

Looking at the results, the VLM is distinguishing between damaged and undamaged boxes. If the VLM Response is "Yes," the cardboard box has physical damage (Alert Result: True); if "No," there is no damage (Alert Result: False). The intended operation is to notify administrators only of True alerts.

Asking Questions About the Video Using the Chat Feature

The Alert Inspector UI also has a built-in chat feature. With a video selected, entering a question causes Cosmos-Reason2-8B to analyze the video content and respond.

It also supports questions in Japanese. When I entered "日本語で状況を教えてください" (Please describe the situation in Japanese), it explained the video situation chronologically: "A brown paper bag is placed at the starting point of a curved conveyor belt. Next, the paper bag begins to move along the belt." The description of the cardboard box as a "paper bag" may be due to the appearance of the synthetic footage, but it accurately captures the movement of the object on the belt. Alert verification is a Yes/No judgment in English, but questions in Japanese are answered in the chat.

Switching to an RTSP Live Stream

Setting Up an RTSP Server with MediaMTX

Up to this point we used file processing of sample footage, but let's switch to an RTSP live stream assuming real-world operation.

This time, instead of a camera, I'll use MediaMTX and ffmpeg to stream the sample footage as an RTSP stream.

# Start MediaMTX RTSP server
docker run --rm -d --name mediamtx -p 8554:8554 bluenviron/mediamtx:latest

# Stream conveyor belt footage in a loop via RTSP
ffmpeg -re -stream_loop -1 -i conveyor_belt_inspection_sdg_1080p.mp4 \
  -c copy -f rtsp rtsp://localhost:8554/conveyor

-stream_loop -1 for infinite loop, -re for real-time rate streaming. This continuously streams an RTSP stream at rtsp://<host-ip>:8554/conveyor.

Real-Time Detection on Live Video

Specifying the RTSP URL in the CV UI starts real-time processing of live video. It fetches video at the default 10-second interval, and the full flow of GroundingDINO detection → clip generation → Alert Bridge submission → VLM verification runs.

Unlike file processing, live streams generate detection events continuously. Reloading the Alert Inspector UI lets you see new alerts being added one after another.

Checking Resource Usage

I checked DGX Spark's resource usage while Event Reviewer + CV pipeline was running.

In the previous 3.0.0 EA, 42 containers consumed 84GB out of 128GB, leaving DGX Spark in a fairly tight state. The current Event Reviewer runs with 8 containers and low GPU usage, with plenty of headroom.

This is because Event Reviewer doesn't use the RAG stack (LLM, Embedding, Reranker, Milvus, Neo4j, etc.). With only one VLM and one CV model, resource consumption is dramatically lower. Chat response times also felt comfortable at a few seconds.

Alert Bridge API Details

Up to this point we used the flow through the CV UI, but Alert Bridge also provides a REST API. This is an API designed for cases where alerts are sent from custom detection systems or external IoT sensors.

Alert Submission API

Send alerts as JSON to POST http://localhost:9080/api/v1/alerts.

{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "@timestamp": "2026-03-08T19:50:00Z",
  "sensor_id": "conveyor-cam-1",
  "video_path": "/tmp/alert-media-dir/clip.mp4",
  "alert": {
    "type": "package_damage",
    "description": "Cardboard box with potential damage detected",
    "severity": "medium",
    "status": "REVIEW_PENDING"
  },
  "event": {
    "type": "object_detection",
    "description": "Cardboard box detected on conveyor belt"
  },
  "vss_params": {
    "num_frames_per_chunk": 8,
    "vlm_params": {
      "prompt": "Does the cardboard box clearly show signs of physical damage such as crumpling, tearing, dents, creases, or being open? Answer Yes or No.",
      "system_prompt": "You are a warehouse conveyor belt inspection system.",
      "max_tokens": 200,
      "temperature": 0.3
    }
  }
}

API Pitfalls

When actually calling the API, there were several validation rules not explicitly stated in the documentation. I'll summarize them for those who might fall into the same traps.

The last one about prompt nesting was particularly confusing. Writing prompt directly under vss_params treats it as null and falls back to the default prompt (defined in alert_request_defaults.yaml). To use a custom prompt, specify it in vlm_params.prompt.

Prompt Management API

Alert Bridge also has an API for pre-registering and managing prompts.

# Register a prompt for each alert type
curl -X POST http://localhost:9080/api/v1/prompts \
  -H "Content-Type: application/json" \
  -d '{
    "alert_type": "package_damage",
    "prompt": "Does the cardboard box clearly show signs of physical damage? Answer Yes or No.",
    "system_prompt": "You are a warehouse conveyor belt inspection system."
  }'

The priority order for prompts is "in-request > registered prompt > default settings." For an inspection line, it would be practical to pre-register verification prompts for each alert type, such as cardboard box damage, missing labels, and orientation anomalies.

Verification Result Output and External Integration

What you might wonder here is "how do you notify external systems of the VLM verification results?"

Looking at Alert Bridge's config.yaml, the output destination for VLM verification results is Redis Streams.

redis_sink:
  streams:
    enhanced_anomaly_stream: 'alert-bridge-enhanced-stream'
    incidents_stream: 'alert-bridge-incidents-stream'

When the VLM finishes its judgment, the results are written to alert-bridge-enhanced-stream and alert-bridge-incidents-stream. WebSocket (ws://localhost:9080/ws/alerts) can also be used if you want to receive results in real time. The Alert Inspector UI internally uses this WebSocket to update the screen.

On the other hand, "notifications to external services" such as Slack notifications, email alerts, and PagerDuty integration are not included in the Blueprint. You'll need to implement it yourself by reading from Redis Streams, or switch sinkType in config.yaml to kafka and connect to various SaaS services via Kafka Connect.

The Standard VSS side has a callback endpoint mechanism called notification_tool, but it's not used in Event Reviewer. The Blueprint only provides "detection → VLM verification → result stream output," and leaves actions beyond that (notifications, ticket creation, automatic line stops, etc.) to the user. Conversely, since it outputs through standard interfaces like Redis Streams and WebSocket, I think there's a high degree of freedom to incorporate it into existing systems.

Summary

I deployed Event Reviewer from VSS 2.4.1 GA on DGX Spark and ran a real-time monitoring pipeline from object detection with GroundingDINO to VLM verification.

If Standard VSS is a tool for "searching archived footage after the fact," Event Reviewer is a tool for "VLM verifying CV detection events in real time." Being lightweight without needing the RAG stack, it runs comfortably on a single DGX Spark with 8 containers and GPU usage of 1-37%. Compared to the 42-container configuration of 3.0.0 EA, this lightness is quietly appreciated.

GroundingDINO's open-vocabulary detection is also quite useful, allowing you to flexibly switch detection targets just by changing the text prompt. Unlike models with fixed classes, being able to respond to requests like "today I want to look at the appearance of this product" without retraining is a big advantage at the PoC stage.

What I personally liked was the Alert Bridge API design. You can submit alerts from the outside via REST API, and customize verification content for each alert type with the prompt management API. The Blueprint is designed not as a "finished product to use as-is" but as a "starting point for customization," with a structure that makes it easy to integrate into custom use cases.

Next time, I'd like to dig a little deeper into manufacturing use cases based on this Event Reviewer. Things like separating the CV pipeline to a Jetson Orin Nano Super to create an edge-server configuration, or testing how far inspection accuracy can be improved with domain-specific prompt design. It'll be verification that takes this Blueprint as a "starting point for customization" and moves closer to real-world operation.

Reference Links

• VSS (Video Search and Summarization) Official Documentation
• VSS GitHub Repository
• GroundingDINO on NGC
• Cosmos-Reason2-8B
• Running a Video Search AI Agent on DGX Spark (VSS Agent)
• Trying the VSS 3.0.0 EA Warehouse Blueprint on DGX Spark