Access VIF logs in Wowza Streaming Engine

Prerequisite

VIF file logging requires the LogFiles event listener to be enabled. If this listener is not enabled, the wowzastreamingengine_vi_[date].log file described below will not be written.

VIF logs are written to the Wowza Streaming Engine logs directory alongside the standard engine log files. By default, log files are written to:

[install-dir]/logs/wowzastreamingengine_vi_[date].log

Each line in the log file is a self-contained JSON object. This format makes VIF logs directly ingestible by platforms such as Splunk, Elastic, Datadog, and other log aggregation tools without additional parsing or transformation.

VIF generates logs from two sources:

• VIC logs (inside WSE) - These are written to the standard WSE log files: wowzastreamingengine_access.log, wowzastreamingengine_error.log, and wowzastreamingengine_vi.log (if LogFileEvent is enabled). These are available in ./wse/logs/ when volume mounts are enabled.
• VIS logs - The Video Intelligence Service container writes these. To view these logs, run: docker compose --profile vi-service logs -f

---

Log structure

Every VIF log entry is a JSON object with two top-level properties:

• time_stamp - the server-local timestamp when the entry was written to disk.
• vif_data - an object containing all detection results, performance metrics, and metadata for the analyzed frame.

All fields documented in the tables below are properties within the vif_data object unless otherwise noted.

---

Logging Fields

Root-level fields

Field name	Description
time_stamp	Date and time the log entry was written to disk by Wowza Streaming Engine. Format: YYYY-MM-DD HH:mm:ss (server local time).
type	Log event category. Currently the only value is detections, indicating a detection result from the Video Intelligence Service.
detector_type	The type of detection model that produced the result. Values are object, scene, vlm, or synthetic.
stream_name	Name of the Wowza Streaming Engine application stream being analyzed (e.g., security-cam-1, lobby-east).
request_id	Unique UUID v4 identifier for the inference request sent to the Video Intelligence Service. Use this to correlate log entries with webhook payloads and VIS diagnostics.
created_at	ISO 8601 UTC timestamp indicating when the Video Intelligence Service produced the detection result.
detection_window	Object containing frame-range metadata for the analyzed sample. See Detection window fields.
preprocess_time_ms	Time in milliseconds the VIS spent preparing the frame for inference (resizing, normalization). Typical range: 0–2 ms.
inference_time_ms	Time in milliseconds the VIS spent running the detection model on the frame. Typical range: 6–20 ms with GPU acceleration.
postprocess_time_ms	Time in milliseconds the VIS spent on post-inference processing (non-maximum suppression, tracking). Typical range: 0–5 ms.
total_processing_time_ms	End-to-end processing time in milliseconds for the entire VIS pipeline (preprocess + inference + postprocess + overhead). Typical range: 10–40 ms.
detections_type	Classification of the detection results in this entry. Currently the only value is object.
sequence_id	Monotonically increasing integer that orders detection results per stream. Starts at 0 when the stream begins and increments with each analyzed frame.
detections	Array of detection objects found in the analyzed frame. Each object includes class, confidence, bounding box, and tracking data. Omitted when no objects are detected in the frame.

---

Detection window fields

The detection_window object describes the frame range that was analyzed. Currently, VIF performs single-frame analysis, so from_frame_id and to_frame_id will be equal and frame_count will be 1.

Field name	Description
from_frame_id	Integer identifier of the first frame in the detection window.
to_frame_id	Integer identifier of the last frame in the detection window. Equal to from_frame_id for single-frame analysis.
frame_count	Number of frames included in this detection window. Currently 1.
from_frame	Presentation timestamp of the first frame in the window. Format: YYYY-MM-DD HH:mm:ss.SSS.
to_frame	Presentation timestamp of the last frame in the window. Equal to from_frame for single-frame analysis.

---

Detection object fields

Each element in the detections array represents a single object detected in the analyzed frame. The following fields are present on every detection object:

Field name	Description
class_name	COCO class label for the detected object (e.g., person, car, truck).
confidence	Detection confidence score from 0.0 to 1.0 representing the model’s certainty that the classification is correct.
track_id	Unique integer identifier assigned to a specific object instance for cross-frame tracking.
frame_id	Integer identifier of the video frame in which the detection occurred.
bbox	Bounding box object defining the rectangular region containing the detected object.

---

Bounding box fields

The bbox object defines the rectangular region of the video frame that contains the detected object. Coordinates are measured in pixels from the top-left corner of the frame.

Field name	Unit	Description
x	Pixels	X-coordinate of the top-left corner.
y	Pixels	Y-coordinate of the top-left corner.
x2	Pixels	X-coordinate of the bottom-right corner.
y2	Pixels	Y-coordinate of the bottom-right corner.
w	Pixels	Width of the bounding box.
h	Pixels	Height of the bounding box.

---

Supported object classes

The default RT-DETR model included with VIF is pre-trained on the COCO dataset and can detect the following 80 object classes. The class_name field in each detection entry will contain one of these values:

People & Vehicles	Animals & Accessories	Sports & Kitchen	Appliances & Objects
person	elephant	wine glass	dining table
bicycle	bear	cup	toilet
car	zebra	fork	tv
motorcycle	giraffe	knife	laptop
airplane	backpack	spoon	mouse
bus	umbrella	bowl	remote
train	handbag	banana	keyboard
truck	tie	apple	cell phone
boat	suitcase	sandwich	microwave
traffic light	frisbee	orange	oven
fire hydrant	skis	broccoli	toaster
stop sign	snowboard	carrot	sink
parking meter	sports ball	hot dog	refrigerator
bench	kite	pizza	book
bird	baseball bat	donut	clock
cat	baseball glove	cake	vase
dog	skateboard	chair	scissors
horse	surfboard	couch	teddy bear
sheep	tennis racket	potted plant	hair drier
cow	bottle	bed	toothbrush

Note: Custom and BYOM models may produce different class labels depending on the training data used. When using a custom model, class_name values will reflect the labels defined in that model’s training configuration.

---

Processing performance metrics

Every log entry includes four timing fields that measure how long the Video Intelligence Service took to process the frame. These metrics are useful for monitoring GPU performance, identifying bottlenecks, and capacity planning.

Metric	Typical range	Description
preprocess_time_ms	0–2 ms	Frame preparation: decoding, resizing, normalization.
inference_time_ms	6–20 ms	Model execution on GPU.
postprocess_time_ms	0–5 ms	Suppression, thresholding, and object tracking.
total_processing_time_ms	10–40 ms	Total VIS pipeline time.

Note: Processing times may increase with the number of objects in the frame, model complexity (especially with custom BYOM models), or when the GPU is under heavy load from multiple concurrent streams.

---

Sample log entries

Frame with no detections

When VIF analyzes a frame and no objects are detected, the detections array is omitted from the log entry:

{"time_stamp":"2026-02-28 00:39:08",
  "vif_data":{
    "type":"detections",
    "detector_type":"object",
    "stream_name":"lobby-east",
    "request_id":"1e33e303-77ee-40ca-8708-56d4b69bcde8",
    "created_at":"2026-02-28T00:39:07Z",
    "detection_window":{
      "from_frame_id":0, "to_frame_id":0,
      "frame_count":1,
      "from_frame":"1970-01-01 00:00:00.000",
      "to_frame":"1970-01-01 00:00:00.000"
    },
    "preprocess_time_ms":1,
    "inference_time_ms":8,
    "postprocess_time_ms":1,
    "total_processing_time_ms":20,
    "detections_type":"object",
    "sequence_id":0
  }
}

Frame with multiple detections

When objects are detected, the detections array contains one entry per object with class, confidence, tracking, and bounding box data:

{"time_stamp":"2026-02-28 04:40:24",
  "vif_data":{
    "type":"detections",
    "detector_type":"object",
    "stream_name":"parking-lot",
    "request_id":"cdb46f9f-b2e6-497e-8104-d3e132b50bb0",
    "created_at":"2026-02-28T04:40:22Z",
    "detection_window":{...},
    "preprocess_time_ms":0,
    "inference_time_ms":6,
    "postprocess_time_ms":1,
    "total_processing_time_ms":13,
    "detections_type":"object",
    "sequence_id":1446,
    "detections":[
      {"class_name":"person","confidence":0.94,
       "track_id":72,"frame_id":2788,
       "bbox":{"x":366,"y":85,"x2":456,
              "y2":292,"w":90,"h":207}},
      {"class_name":"tv","confidence":0.87,
       "track_id":71,"frame_id":2788,
       "bbox":{"x":153,"y":176,"x2":233,
              "y2":225,"w":80,"h":49}}
    ]
  }
}

---

Log output channels

VIF detection data is routed simultaneously to five independent output channels. The filesystem log documented in this article is one of these channels. The full set of output channels includes:

Output channel	Description
Filesystem logs	Structured JSON logs written locally for ingestion by Splunk, Elastic, Datadog, and similar tools.
Enriched HLS stream	ID3 metadata is injected into HLS streams containing detection JSON.
Visual overlays	Bounding boxes and labels burned directly into the video frame.
Webhook dispatch	HTTP POST requests are sent to configured endpoints for each detection event.
Custom Java listeners	Streaming Engine listener interface for custom processing logic.