Media Servers
A media server connection lets QUBIQ display live video on operator screens. QUBIQ does not talk to cameras directly — it proxies a streaming server (an NVR, an RTSP-to-HLS gateway, a media service) that already publishes browser-playable streams.
Why a proxy
Browsers cannot play RTSP. Something must transcode or repackage it into HLS or a similar
browser-native format. QUBIQ sits in front of whatever does that, and adds three things a direct
<video src> cannot:
- Credentials stay server-side. Upstream username and password are stored encrypted and never reach the browser.
- One access rule. Video is subject to the same authentication as everything else on the screen.
- No camera exposure. Operator browsers need reach to QUBIQ only, not to the camera network.
Configuration
| Field | Description |
|---|---|
| Name | Connection identifier. |
| Playlist URL | The stream URL template, which may contain a {stream} placeholder. |
| Sub-stream suffix | Naming convention for low-resolution variants, e.g. _sub. |
| Probe stream | A stream name the connection test exercises. |
| Credentials | Upstream username/password, if the media server requires them. Presence is shown as has_credentials; values never leave the server. |
The URL template
http://nvr.plant.local:8888/{stream}/index.m3u8
A widget supplies the stream name, and QUBIQ substitutes it. One connection therefore serves every camera on that server — you do not create a connection per camera.
Sub-streams
Most cameras publish a full-resolution main stream and a lower-resolution sub-stream. With a sub-stream suffix configured, a widget can ask for the low-resolution variant by convention:
stream "line1-cam1" + suffix "_sub" → line1-cam1_sub
Use sub-streams for multi-camera tile walls and main streams for a single focused view. A screen with nine full-resolution feeds will saturate an operator panel PC.
Displaying video
Use the VideoPlayer widget. Set its connection and stream name — both bindable, so a camera can follow the selected equipment, a tag value or a navigation parameter.
How streaming is served
Streams are proxied through the gateway rather than fetched by the browser. Any authenticated platform user may view a feed: the connection is administrator-managed and the widget was placed by an author, so viewing is a read like any other. The equivalent route exists inside the project runtime tree for LiveView operators, subject to the project's access policy.
Security
- Keep cameras on their own VLAN; only QUBIQ needs to reach them.
- Give the media server a dedicated QUBIQ account with view-only rights.
- Use TLS between QUBIQ and the media server if they are on different segments.
- Cameras overlooking people are usually subject to privacy law. Access to those views should be restricted by project and runtime role, and the access itself is recorded in the audit journal.
Performance
| Consideration | Guidance |
|---|---|
| Streams per screen | Prefer sub-streams beyond 2–4 tiles. |
| Bandwidth | Every viewer is a separate stream through QUBIQ. Ten operators watching one camera is ten streams unless the media server multicasts. |
| Latency | HLS is inherently a few seconds behind. Do not use video as a control feedback loop. |
| Recording | QUBIQ displays; it does not record. Recording and retention belong to the NVR. |
Troubleshooting
| Symptom | Check |
|---|---|
| Test fails | The probe stream name must exist on the media server exactly as written. |
| Black player, no error | The stream exists but is not being published — check the camera is online at the NVR. |
| Works in the Platform, not in LiveView | The project's access policy does not permit media for that runtime role. |
| Stutters with several tiles | Switch those widgets to sub-streams. |
| Authentication loop | Upstream credentials rejected; re-enter them (blank keeps the existing value). |