Live Video - Streams and Metrics

Live Ingest Operations

Live Video (Streams and Processing Metrics)

Choose one ingest method first, confirm live views and payload health second, and open debug pages only when the main ingest lane is already visible here.

Main action

Pick the active ingest method, confirm cam1 and cam2 output, then use the lower health panels to verify payload freshness and system pressure.

Open video debug Open Exercise Open Video Test

Choose an ingest method

Pick one method or show all methods for comparison

RTSP / HTTP / HTTPS Browser Capture WebRTC (Browser) Show All

RTSP/HTTP: network source -> FrameBus. Browser Capture: getUserMedia -> /api/ingest_frame. WebRTC: stream -> /api/webrtc/offer.

View: MJPEG cam1/cam2Debug: payload + debugScaling: 2 cameras -> N

Multi-Cam view (cam1 / cam2) + HUD

Enable MJPEG views (cam1/cam2) HUD (status and measurements on the video) Mode: MJPEG viewers: 0Estimated throughput: 0.00 Mbps

Display fit (HUD)

Open full MJPEG stream (new tab)

RTSP/HTTP ingest streams network sources into FrameBus. After ingest starts, the cam1/cam2 channels appear here.

RTSP / HTTP Ingest

Camera #1 (cam1)

RTSP/HTTP address

cam_id Resolution (preset)

Camera #2 (cam2)

RTSP/HTTP address

cam_id Resolution (preset)

MJPEG views (cam1 / cam2)

Camera #1 (cam_id = cam1)

cam1 | Payload age: ms | view_id: | stream.id:

Waiting for cam1...

Camera #2 (cam_id = cam2)

cam2 | Payload age: ms | view_id: | stream.id:

Waiting for cam2...

You can also open /video/stream_cam.mjpg?cam_id=... directly.

Browser Capture #1 (cam_id=cam1)

Browser ingest uses getUserMedia and sends JPEG frames to /api/ingest_frame.

Camera Resolution (preset) Target FPS Background FPS JPEG quality (40-95) Mirror Token (optional) Show preview

Transmitted FPS: 0.0

Latency (ms):

Actual resolution:

Frames sent: 0

Payload age (ms): | view_id from payload: | stream.id from payload: | frame_id from payload:

Debug (camera #1)

Incoming JSON

Camera #1 | Waiting

Browser ingest sends JPEG frames to /api/ingest_frame?cam_id=cam1.

Browser Capture #2 (cam_id=cam2)

A second browser ingest surface that can be used for cam2 in parallel.

Camera Resolution (preset) Target FPS Background FPS JPEG quality (40-95) Mirror Token (optional) Show preview

Transmitted FPS: 0.0

Latency (ms):

Actual resolution:

Frames sent: 0

Payload age (ms): | view_id from payload: | stream.id from payload: | frame_id from payload:

Debug (camera #2)

Incoming JSON

Camera #2 | Waiting

Browser ingest sends JPEG frames to /api/ingest_frame?cam_id=cam2.

WebRTC (Browser Sender)

Signaling via /api/webrtc/offer

WebRTC sends live video to /api/webrtc/offer. The output appears in the MJPEG cam1/cam2 views.

Camera Target cam_id Resolution (preset) FPS JPEG quality (40-95) ICE URLs (optional) Send metadata over the DataChannel Metadata label

WebRTC Health

Auto refresh (2 sec)

Enabled:

Available:

State:

Peer state:

Receiving frames:

FPS:

Input FPS:

Requested:

Actual:

Ingest gap:

Gap %:

Ingest latency: ms

Last frame age: ms

cam_id:

provider_id:

Reason:

Last error:

Association success:

Unassociated rate:

WebRTC status JSON (diagnostic)

WebRTC status updates on each refresh. Video output appears only in the MJPEG cam1/cam2 views.

Local browser preview

Video Status

Mode:
Running:
Estimated FPS:
Resolution:
Payload age (ms):
MJPEG rate (Hz):
Viewers:
Current Mbps:

These values reflect the active MJPEG stream.

System Health

/healthz:
Version:
Local time:
Uptime (sec):

Payload Summary

Choose payload by cam_id:

Version:
Timestamp:
objdet.objects:
objdet.tracks:
mp.landmarks:
meta.fps:

Full JSON

This JSON comes from the latest payload generated by MPR / the bridge.

Live Mode / Learn

Unknown

Mode:
Exercise:
Stage:
Cue:
Gate:
Audio proof:

Waiting for Learn state...

Shows whether the live runtime is in normal Live mode or an active Learn lesson, without changing runtime behavior.

Performance

CPU stable

CPU usage (proc):
RSS memory:
Top component:
Pressure:
Cause:

raw_fps (source):

Frame age (ms):

Queue depth:

Drops per minute:

Fused frame age (ms):

Total fused so far:

Multi-Cam Status

raw FPS by camera:
Last frame age (ms):
MPR active:
MPR queue:
MPR drops:

Fast Status Indicators

HealthStream runningFresh payloadFPSViewersPoseMeasurementsObject detectionPayload bridgeTokenMPRWebRTC

Fresh payload: red if age > 3s, yellow if 1.5-3s. FPS: red if <4Hz, yellow if 4-8Hz.

WebRTC: green when peer_state=connected and frames are arriving, yellow while waiting or connecting, red on error.

Advanced video debugging is available in the debug pages. Use it for Multi-Cam and MPR checks in real time.

Open video debug /debug/video/multicam

Advanced: ingest and sync summary (Multi-Cam)

This section is mainly useful for multi-camera synchronization monitoring. In a single-camera setup, it can usually be ignored.

Mode:
Active views:
Canonical source:
Health:
Fused frame age (ms):
p95 delta (ms):
Paired FPS:
Payload age (ms):

Multi-Cam Debug System Debug

System load (local/cloud)

Source: local

CPU -- PROC -- GPU --If cloud data is unavailable or an error occurs, local data is shown instead.

Help and Method Guide

WebRTC

Live browser streaming to /api/webrtc/offer. Output appears in MJPEG views and status panels.

Browser Capture

getUserMedia sends JPEG frames to /api/ingest_frame. Useful for quick local checks.

RTSP / HTTP

Ingest from network sources (RTSP/HTTP). Feeds FrameBus and appears in MJPEG.

MJPEG Views

Shows cam1/cam2 through /video/stream_cam.mjpg. Useful for quick ingest verification.

Ingest and Sync Summary

Advanced summary for multi-camera synchronization. Mainly useful in Multi-Cam mode.

Status Indicators

Shows system health, payload, FPS, MPR, and WebRTC at a glance.